The Single Responsibility Principle of source control

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”. From http://mauriziostorani.wordpress.com/

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:

  • When a bug is found – it’s hard to discover what change created it
  • Your code is not run part of the project until you commit it
  • You’re more likely to need to merge your changes on commit
  • Code reviews take longer… much longer
  • And last but not least – if your machine dies your changes dies with it

When a bug is found – it’s hard to discover what change created it

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.

Your code is not run part of the project until you commit it

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.

You’re more likely to need to merge your changes on commit

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 reviews take longer… much longer

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.

If your machine dies your changes dies with it

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.

Conclusion

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.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s