Here are some do’s and don’ts when it comes to reviewing peer code.
- Find things which are GOOD!
- Do NOT just look for things that are bad
- Look for common repeated issues
- Do not review a lot of code at once
- Remember no code is perfect – so implementations can be subjective
- Do NOT get emotional!
- Do not focus on BLAME
- Do not focus on how YOU would have done it
- Do not attempt to redesign the solution
- Try to avoid looking for one-off minor issues
When reviewing code we want to ensure the code is maintainable, considers good design practices and of course is fit for purpose. Where possible it is important to find repeated issues that can be converted to a ‘teachable moment’. The result of the code review should not only be better code but also help make better developers – improve code quality and the quality of the team.
Developers should not fear the code review process if it is managed correctly. It is important for both the reviewer and writer to try and not be emotional. It is easy to become attached to code – just as easy it is to criticise fellow developers because you may have a god complex, balance is key.
Personally I like to review portions of code and then make my own notes, then afterwards arrange for a quick 1-2-1 with a developer for them to walk me through what they have done. I feel it can be helpful to discuss, gain an insight into another developers thought process (at times) when reviewing code – especially larger pieces of work. Some code review tools are great especially when working with remote employees, but at times I find them somewhat cold and detached – having a good relationship with fellow developers is also just as important in my opinion.