How hard do you think it is to write a tool to draw dependencies map for a specific language?
May be there're built-in code analyzing tools in compilers for popular languages that I'm not aware of?
http://lonnie.io/gostd/dagvis/
If you write your project that even has no circular deps among files and all files are small (like me in https://github.com/h8liu/e8vm), you can draw the similar graph but at a much finer granularity, like this:
Here are my hand-made tools to generate those stuff: https://github.com/h8liu/e8tools
Javascript version (I actually wrote this first for go std lib): https://github.com/h8liu/dagvis
the graphs can have cycles, multiple references to the same dependency, multiple distinct versions of the same dependency, et cetera. it's also all very, very language-specific. in many languages, the order of the require or import statements matter; in others, they don't. you can also have something like Clojure, with several different ways of bringing in a dependency, which makes the whole issue much more fine-grained.
prior to writing these scripts, I tried to do something more ambitious with auto-refactoring tools. these exist in Eclipse and can even be graceful in Smalltalk but my own results were not so amazing. I got somewhere with regular expressions, code generation, and shell scripting. but I also built a thing in Ruby which could auto-refactor a tiny, TINY subset of the most obvious refactorings in JavaScript. it took me months, maybe harmed my sanity, and was definitely not the best code I ever wrote.
TLDR: compilers, zomg.
edit: forgot to say you're welcome. :-)
It might be nice to surface files that are frequently edited together as well.
It was a 3D pong game, along with the game engine. Pretty neat to see this visualized.
edit: took like 4 minutes, worked well!
Caveat: Running this code against extremely large projects with very long histories (e.g. Rails) might be very slow.
https://github.com/gilesbowkett/rewind
it's for assessing a project on day one, when you join, especially for "rescue mission" consulting. it's most useful for large projects.
the idea is, you need to know as much as possible right away. so you run these scripts and you get a map which immediately identifies which files are most significant. if it's edited frequently, it was edited yesterday, it was edited on the day the project began, and it's a much bigger file than any other, that's obviously the file to look at first.
we tend to view files in a list, but in reality, some files are very central, some files are out on the periphery and only interact with a few other files. you could actually draw that map, by analyzing "require" and "import" statements, but I didn't go that far with this. those vary tremendously on a language-by-language basis and would require much cleverer code. this is just a good way to hit the ground running with a basic understanding which you will very probably revise, re-evaluate, or throw away completely once you have more context.
but to answer your actual question, you do some analysis like this every time you go into an unfamiliar code base. you also need to get an idea of the basic paradigms involved, the coding style, etc. -- stuff which would be much harder to capture in a format as simple as bash scripts.
one of the best places to start is of course writing tests. Michael Feather wrote a great book about this called "Working Effectively with Legacy Code." brudgers's comment on this is good too but I have some small disagreements with it.