5 ms·
I wrote some simple bash scripts around git which allow me to very quickly identify the most frequently-edited files, the most recently-edited files, the larges
by tessierashpool 11y ago
I wrote some simple bash scripts around git which allow me to very quickly identify the most frequently-edited files, the most recently-edited files, the largest files, etc.
https://github.com/gilesbowkett/rewind 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.
- thameera 11y agoAnybody knows a similar analysis tool for an SVN project? One option would be to convert the SVN to git for analysis purposes, but I'd be interested in a better solution.
- r41nbowcrash 11y agonever tried it myself, but you can take a look at the accompanying code "Your Code as a Crime Scene" https://github.com/adamtornhill/code-maat https://github.com/adamtornhill/code-maat
- thameera 11y agoThanks! Gonna give this a try.
- rch 11y agoGreat answer. I can't begin to estimate how many times I've considered writing something along these lines. It might be nice to surface files that are frequently edited together as well.
- rpcope1 11y agoVery cool! Thanks for sharing your scripts.
- fokz 11y agoThanks for sharing. I often get lost in large projects. Blindly jumping around is quite inefficient and frustrating. 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?
- roflc0ptic 11y agoI am reminded of this: http://steve-yegge.blogspot.ca/2007/06/rich-programmer-food.html http://steve-yegge.blogspot.ca/2007/06/rich-programmer-food....
- tessierashpool 11y agodependency graphs and code analysis are huge topics. this is probably the hard part with libraries like npm or Bundler. 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. :-)
- h8liu 11y agoFor golang std lib, since packages have no circular deps, it can be automatically drawn out like this: http://lonnie.io/gostd/dagvis/ 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 https://github.com/h8liu/e8vm), you can draw the similar graph but at a much finer granularity, like this: http://8k.lonnie.io/ http://8k.lonnie.io/
- nmb 11y agothanks for making this and sharing!
- rajathagasthya 11y agoThanks for sharing. For someone in their early career like me, this is very useful.
- baby 11y agoIs it normal that it takes a while > 2minutes to run your program on some big java repo? edit: took like 4 minutes, worked well!
- davelnewton 11y agoThat doesn't seem very long at all.
- davelnewton 11y agoWell, it doesn't; wth.
- tessierashpool 11y agoquoting from the readme: Caveat: Running this code against extremely large projects with very long histories (e.g. Rails) might be very slow.
- lsiebert 11y agoHmm... this is an interesting project. No License info though.
- lsiebert 11y agoAdded a pull request to use git ls-tree for filenames so you only check stuff in the repo, instead of find. Hopefully it will end up on an open source license of some sort.
- azeirah 11y agoI made a crappy visualization of the commits of our University project, http://codepen.io/Azeirah/pen/bdawBm http://codepen.io/Azeirah/pen/bdawBm It was a 3D pong game, along with the game engine. Pretty neat to see this visualized.
- zodvik 11y agoVery simple & quite effective. Thanks for sharing.