Hacker News Reader

Comment by mmatants | Hacker News Reader

Funny you mention monolithic code. The post expressed a very important thought:

> we’re trying keep the parts that change frequently, away from the parts that are relatively static

Modularization and good code contracts help "sequester" code parts with different rates of change.

And this is my guiding hunch when I am splitting up code and deciding on module surfaces: how confident are we in the subject matter that given code describes? This does not replace actual proper concept modeling, but it is an intuitive feel for helping future iterations go smoothly.

View on HN

Intuition is great but we often forget that we can use churn stats too.

find . -name "*.rb" |xargs -n1 -I file sh -c 'echo `git log --oneline file | wc -l`: file'|sort -nr

Applying a time period window is good too as some parts of code churn for a while and them reach stability.

What does that command do?

By my read, it prints a list of all Ruby files in your project sorted by number of commits against them. It may take a long time to complete depending on number of files and number of commits.

YMMV, I am not a BASH shell.

http://explainshell.com/explain?cmd=find+.+-name+%22*.rb%22+... doesn't quite get it either, but I think you're right. I'm not near a machine with Bash to check.

Actually, it finds all Ruby .rb files, then prints out that file every time a change was made to the file. It then does a count of each of the times the file is output, and then sorts the list with those files that were modified the most frequently being at the top, and those modified least frequently being at the bottom.

In other words, it shows (as the poster says) file churn in a Ruby codebase.

We put a variation of the script to music also. Seriously. It's on iTunes and Bandcamp:

https://itunes.apple.com/us/album/snippets-programming-episo...

https://fowlerandfeathers.bandcamp.com/releases

It finds all of the files with the .rb extension in a directory, then feeds that in to git log --oneline. wc -l then counts how many lines resulted from git log, which basically tells you how many times each file has been modified. Lastly these numbers are sorted from largest number to lowest.

The gist of it is that you figure out which files get modified the most. This lets you know where your most frequently changed code is.

Reply on news.ycombinator.com