Code reviews are an important way for the team to learn and understand the parts of a system they aren’t working on. Code reviews also give developers feedback on their work. They help the team provide consistency in the code they write and help propagate good development practices throughout the team. Here are seven strategies for better code reviews.
1. Do them regularly
Code reviews are such an important practice they should be done regularly, usually at the end of each sprint or whenever there’s new working code to be added to the system. Developers should expect all their code to be reviewed by at least one other developer, and likewise expect that they will be reviewing code from other developers themselves.
2. Invite everyone
Code reviews can be fun and empowering. Invite others to attend. It can be good to get other developers’ constructive feedback. Different people can provide fresh perspectives, which can be helpful.
3. Focus on “why” not “what”
It can be helpful to ask for the kind of information you’re looking for. Usually, going into the reasons choices were made is helpful for getting people to understand your approach. Help others see why you chose a particular approach, not just what you did.
4. Keep things clear
Sometimes, thing that seem clear to us are not clear to others. If people can’t understand what your code is doing without reading your comments, it’s probably time to refactor. Using intention revealing names is every bit as important as designing an algorithm. If an algorithm is complex, break it up across multiple lines with intermediate results. This makes code easier to understand and debug.
5. Discuss design tradeoffs
Help people understand the tradeoffs you made so they can better understand your design. Sometimes you have to pay a price in one area to gain value in several other areas. Local optimization only has value if it also optimizes the whole process. If it only moves a bottleneck somewhere else then it may not be worth doing. Look for ways of making code easier to work with by injecting dependencies and creating well-defined interfaces.
6. Point out what worked
Feedback is an important part of code reviews but many developers have trouble giving or getting feedback. It can be helpful to start with what worked. It’s okay to take different approaches than others as long as they still provide clarity and extensibility. There are many ways to solve the same problems and just because it might not be the way we would solve a problem doesn’t mean it’s wrong.
7. Share aesthetics
Adopting collective code ownership means that the team agrees on common standards and practices for developing software. The coding standards document should be the code itself. It should be impossible to tell who wrote the code just by looking at it. This helps the rest of the team read and understand code that other team members write, and gives code consistency throughout.
Code reviews can be one of the most valuable practices for learning to write better software and for understanding what our teammates are working on. Don’t waste time on minor issues like formatting and instead focus on why a particular design approach was taken. This helps others gain a deeper understanding of the code being reviewed and makes code reviews more valuable and more fun.
Previous Post: « Seven Strategies for Cleaner Code
Next Post: Seven Strategies for Effective Retrospectives »