Code review shouldn’t be approached as an arduous task, but rather embraced as part of your team’s culture. It’s a vital part of the software development process that promotes knowledge transfer and best practices across the entire team. It’s meant to be a discussion where potential alternatives should be considered while providing deeper understanding for the reviewer. Shared knowledge also empowers a team and distributes the critical path.
At RailsConf 2015, Derek Prior from Thoughtbot gave a talk about how they approach code reviews. He summed it up quite: “Code reviews are not about catching bugs. Modern code reviews are about socialization, learning and teaching.”
Code review takes time. It’s supposed to.
The time and effort spent during review will almost always result in better code with fewer bugs. That being said, the goal isn’t to replace your quality assurance team, but rather augment them. Additionally, code reviews provide an opportunity for developers to bring their own expertise and domain knowledge into the conversation, which will further ensure the highest quality output.
Ask questions. Have a conversation.
It’s commonplace that the same feedback given in person is received more positively than when given in written form. This poses an inherent challenge for a reviewer to be able to provide relevant feedback in a positive way. The simplest way to avoid a negative perception is to ask questions. By asking “What do you think about…?” or “Could you explain…?” the reviewer is engaging the author in a conversation where both will benefit.
There will be occasions when the author and reviewer don’t agree. As long as the proposed solution meets the teams’s standards and best practices, consideration should be made that more often than not there is more than one way to solve a problem. A reviewer shouldn’t reject a solution solely on the basis that it’s not the way they would have done it.
When submitting code for review it’s imperative for the author provide adequate context for the given solution. Not everyone shares the same knowledge of the code base and context is required for an effective review. This becomes even more important as a team scales. If a reviewer requires more context, pairing up with the author can provide the opportunity to ask questions and gain more understanding.
As mentioned earlier, the reviewer should focus on asking questions. Does the code meet our standards and style? Are there syntax errors, typos, or dead code? Is there appropriate test coverage and account for all potential edge-cases? Is this solution properly using our frameworks and libraries? Also, when an author does something well, recognize them for it. A little positive feedback can go a long way.
As a Team
There’s an African proverb that says : “If you want to go fast, go alone. If you want to go far, go together.” This sentiment almost seems like commonsense after thinking about it for a moment but it still resonates with me. The take away here is, a team that trusts each other and grows together will be capable of achieving excellence.