November 17th, 2014 by Gareth Wilson
I knew the theory. Code reviews help to:
- Catch bugs
- Ensure code is readable and maintainable
- Spread knowledge of the code base throughout the team
- Get new people up to speed with the ways of working
- Expose everyone to different approaches
Or, they’re just a giant waste of time. At least, that was my first impression of code reviews.
I was the new guy, a recent grad, developing plugins for a software company in London.
Over time I had to submit blocks of identical or similar code. They would get reviewed by the same poor, put upon guy (“he’s the best at it” my manager told me. No good deed…). Yet each review would come back picking at something different. It seemed needlessly picky and arbitrary.
Worse still, reviews would take days, if not weeks. By the time I got my code back I could hardly remember writing it. It wasn’t the guy’s fault. He’d asked for a senior dev, but had gotten me. He was sick of dealing with the issues every inexperienced developer makes, and code reviews were his way of exorcising that frustration.
Add to this the time lost in syncing the different branches, the context-switching… I was not a fan, nor were the rest of the team and it showed.
Skip forward a few years though and I find myself nodding along whilst reading a tweet quoting Jeff Atwood:
“Peer code reviews are the single biggest thing you can do to improve your code.”
What I had come to appreciate in the intervening years is that it wasn’t that code reviews were bad. Code reviews done badly were. And boy, had we been doing them badly.
I had learned this the hard way. And it certainly didn’t happen over night. Although on reflection, code reviews have saved me from more than a few embarrassing, build-breaking code changes! But after I had worked elsewhere, I gained experience of different and better ways of working. This gave me opportunity to see first-hand the benefits of code reviews that I had dismissed before. So now I consider myself a converted skeptic.
So that you can avoid such pains, check out our video and then read on for tips that will skip you straight to effective code reviews.
9 Code Review Tips
Review the right things, let tools to do the rest
You don’t need to argue over code style and formatting issues. There are plenty of tools which can consistently highlight those things. Ensuring that the code is correct, understandable and maintainable is what’s important. Sure, style and formatting form part of that, but you should let the tool be the one to point out those things.
Everyone should code review
Some people are better at it than others. The more experienced may well spot more bugs, and that’s important. But more important is maintaining a positive attitude to code review in general and that means avoiding any ‘Us vs. Them’ attitude, or making reviewing code burdensome for someone.
Review all code
No code is too short or too simple. If you review everything then nothing gets missed. What’s more, it makes it part of the process, a habit and not an after thought.
Adopt a positive attitude
This is just as important for reviewers as well as submitters. Code reviews are not the time to get all alpha and exert your coding prowess. Nor do you need to get defensive. Go in to it with a positive attitude of constructive criticism and you can build trust around the process.
Code review often and for short sessions
The effectiveness of your reviews decreases after around an hour. So putting off reviews and doing them in one almighty session doesn’t help anybody. Set aside time throughout your day to coincide with breaks, so as not to disrupt your own flow and help form a habit. Your colleagues will thank you for it. Waiting can be frustrating and they can resolve issues quicker whilst the code is still fresh in their heads.
It’s OK to say “It’s all good”
Don’t get picky, you don’t have to find an issue in every review.
Use a checklist
Checklists ensure consistency – they make sure everyone is covering what’s important and common mistakes.
Keep the code short
Beyond 200 lines and the effectiveness of a review drops significantly. By the time you’re at more than 400 they become almost pointless.
Link to any related tickets, or the spec. There are code review tools like Kiln that can help with that. Provide short, but useful commit messages and plenty of comments throughout your code. It’ll help the reviewer and you’ll get fewer issues coming back.
Register Now for ‘Code Reviews in Kiln’ Webinar
Join us for our next live ‘Code Reviews in Kiln’ webinar. This webinar will help first time or novice users learn the basics of Code Reviews in Kiln.
- What are Code Reviews
- Why use Code Reviews
- When use Code Reviews
- What to look for during Code Reviews
- Creating a Code Review
- Commenting and Replying on a Code Review
- Working with Existing Code Reviews
- Code Review Workflow
Secure your spot, register now.