Code reviews are one of the most valuable engineering practices.
- Code reviews improve the quality of the code through the suggestions from the code reviewer.
- Code reviews are a great tool to indirectly teach other developers parts of the system they may have to maintain in the future.
- Code reviews encourage people to learn best practices from other developers.
- Code reviews can be used as a validation of the clarity and simplicity of the system.
You may have noticed that I have omitted from the list that code reviews help finding bugs and enforce coding standards and that’s because:
- Code reviews SHOULD’T be performed to find errors in the code.
- Code reviews SHOULD’T be performed to enforce coding standards.
10 years ago these previous two points would have made sense in your code reviews, but not anymore, this should be covered by your automated tests and by some tool which should enforce your coding standards. All this said, it doesn’t mean that is bad to raise a bug or a coding standard defect in a code review, it means that to found them is not the purpose of the code review.
From this perspective then, these are my five tips to make good code reviews.
1.- Make your code reviews often.
I have suffered in my own experience from late code reviews, I used to work in a company where a huge code review of the application was supposed to be the last stage of the development, and they were simply useless, having late code reviews have the following disadvantages.
- The more code to review, the more likely that the developer won’t accept a suggestion of refactoring.
- The longer since the developer coded, the more likely that the developer is personally attached to the code. I would like to remind here one of the biggest problems of software developers, their ego, if a developer designs something and makes it work, no matter how crappy it is, there are a lot of chances that his ego will interfere with any suggestion to improve the design.
- The closer to release date, the less importance is given to enhancements to the code.
My own approach is to make code reviews every time I have just finished coding something non trivial, and that usually means several times a day.
2.- Make your code reviews informal and short.
Forget about checklist, turn around and ask for 5 minutes of attention to any colleague you have beside, if you have a checklist, either one of this 2 things will happen.
- Only what is in the checklist will be reviewed during the code review.
- Code reviews will become formalities, the people will sit together for as short time as possible and will just pretend that they care about the code.
Having short and informal reviews will help you to engage in open conversations where no one will feel as if they were reviewed, but advised.
3.- Make your code reviews with different reviewers.
Is a good idea, if possible, to not use always the same person as code reviewer, there are three main reasons to look for different reviewers every time you want to review your code.
- Is good to get different perspectives
- More people will be able to maintain your code in the future.
- It is a team building activity.
4.- Keep a positive attitude.
Again, remember one of the worst problems of the developers, their ego, having a positive attitude will help to make the code review much more pleasant, and all participants will be more likely to accept the suggestions, and remember: you are not the code!
5.- Learn to enjoy the code reviews.
This is the most important tip, if you are in a team where people enjoy code reviews, you will enter in a dynamic where everyone will be committed to deliver quality code that not only looks good to them, but to the whole team.