In the past I had terrible experience with code reviews. Proposed changes never got integrated. The same people were always doing the code review. Some reviews were almost useless – very little comments except for “this getter is not documented and that’s our coding standard”.
That changed recently and I now appreciate being on both sides of code reviews. Everyone participates and the reviews I received improved my code. Hopefully the reviews I gave did the same. Since we started I think the quality of our application is higher.
Having your code reviewed has great advantages:
- It forces more rigor. Comments help to clean up and be more consistent.
- It helps to make code clearer. If code is not understood by your peer, there’s a good chance you won’t be able to understand it in a month.
- Reviews often simplify code. Your colleagues might have code to solve the same problem or they may know a better way.
That’s only one side of the story though. Reviewing code offers other perks:
- It spreads knowledge and helps to break silos.
- The reviewer sees other designs. Some of your colleague’s ideas might be worth stealing.
- It helps to get better and faster at reading code and understanding algorithms.
Maybe it’s just me, but I believe code reviews make me achieve higher coding standards. What I would like to improve in my team is to get a shorter feedback loop. I try to commit early to get initial comments on my feature. Unfortunately everyone is busy and code review is not always the priority of the day so I often have time to finish the feature before it gets reviewed. Nobody’s perfect – I’m the first to be guilty of prioritizing the feature I’m working on over a review. I’m committed to change my priority from now on.
What should be reviewed to make your application better? Functionality. Compliance to requirements. Code. Naming conventions. Tests. Design. Clarity. Documentation. Usability. Performance. Everything that matters to your team.
Perfection lies in details. Code reviews is one way to make your app shine.
I agree with the benefits of code reviews you listed above. However, this kind of code review is, in my opinion, too late in the development process. Indeed, remarks may lead to big changes while we though the development was done (disappointing). When possible, I would encourage pair-programming as it gives immediate feedback on code quality.
Great post!
Any plans to move from code reviews to pair programming, or at least a balance between the two?
Cheers!
Thanks to both Eric and Luc for pointing out pair programming. We considered it at the beginning of the project and came up with a few (lame) excuses for not doing it… the main point being that we had a very tight deadline for a trade show and we were ready (with our PO) to accumulate some debt to pump out more features.
I think though that it really comes down to a matter of habits. I don’t have an extensive pair programming experience so it’s not a reflex yet. Under pressure, revert to your old (bad?) habits. As I said in the post, I’d appreciate a shorter feedback loop and pair programming might be the perfect answer.
It’s definitely a point i’d like to improve.
I strongly believe that code reviews should be incorporated into the software development process and count as work just like coding.
Given the chance, I would love to try and put a trigger for every commit that would force a review before it gets added to the code base. This would ensure good quality code and 100% reviewed code.
It’s one of those idea that takes a lot of time but is worth it in the long run. Remember a KLOC is not cheap.
Luc, I look forward to working with you again one day
Since you’re talking about the cost of a LOC, have you seen Uncle Bob’s article Software on the Cheap?