The first design principle in SOLID is the single responsibility principle (SRP) that states that each object should have only one responsibility. Today I’ve found another place in which SRP is just as important – source control commits (check-ins).
Just like the programming principle the SRP of source control means that each commit should have only one reason. I’ve seen developers accumulate changes for various reasons. Some think that each commit should add considerable value to the project while others prefer to keep the code until “all of the loose ends are tied”.
I think that hording changes doesn’t help the project or its quality instead it can only lead to opposite result.
When keeping changes on the development machine instead of the source control one of the following will happen:
How many times have you received a bug report claiming that a feature that used to work until version x has stopped working? One way to try and understand why the bug occurs is to find out when the bug was introduced to the code. Doing a quick “binary search” to find the exact commit that caused the code to misbehave should be strait forward but once the offending revision is found wouldn’t it be great if it contained less than half of your project’s files?
Nothing is more frustrating from going over several hundred lines of diff’ed code to try and understand what change is responsible for the new issue.
If the project has a bunch of tests that are being run each commit (I hope for your sake it does) you definitely want your code and your tests to run as part of the build process. Even if no automatic build process exists you definitely want other developers to have your code as soon as possible, because otherwise they might write code that will cause your unchecked changes to stop working and won’t even realize it.
This scenario depends on the source control you’re using: Developer X and developer Y both developers change the same class. Because developer X commits his changes first developer Y needs to perform a merge of the new changes and his code. Sometimes it’s easy sometimes it’s frustrating and almost always annoying.
The longer you’re going to keep the code on your machine and the more lines of code that a commit updates the more likely it is that you’ll need to merge your code with code that was not there when you’ve started working on it.
Code review is an excellent practice that helps the team grow together and share knowledge. The math is simple a code review takes an amount of time proportional to the amount of code being reviewed. A review of a specific change would take less time then a review of several non related changes.
Nothing is more discouraging when reviewing some else's code than to start a review on one feature only to jump to another and then to a bug fixed done on the way. Instead change only specific feature, review the change, commit it and than fix an unrelated bug.
I’ve once lost days of work because my development machine hard drive has stopped working and I didn’t commit the changes to the source control. Remember that the source control is a backup of your code and if you don’t backup your work you might loose it. I try not to have more then one day’s work between my commits to the source control mostly because I’m confident that I can remember what I did yesterday. When I get to the end of the day and I didn’t commit any code I look for the closest point in my current work I can commit so I would not face the risk of loosing my work.
There is no cost of committing your code whenever needed, my rule of the thumb is to check-in my code whenever I’ve finished writing code that improves the project and doesn’t break existing functionality (no failing tests).
There is no point of accumulating changes until some sort of “critical mass” is achieved. If you can put it back in the source control – you probably should.
Labels: Thoughts