Optimizing Code Reviews to Improve Collaboration
Check that the code can be built and deployed. Define the scope and intent of the code you are reviewing. Check that the code fulfills the purpose. Ensure all comments and discussions related to maintainability, performance, or functionality. Spell-check your comments and remove any unnecessary information. Discuss in person or over a call, and only write down the summary. Always check if the code can be built and deployed as is. Let the author know if they can merge the code.
Reviewing is only worthwhile if the build or another part of the deployment process succeeds. What should change for the user of the software? What should change for the person making the software? How much value does this change bring to the company? Check if everything works as expected, and if not, let the author know what is wrong without looking at the code. After you are finished reading and commenting on the code, review your comments. Pause if you need to refresh for a bit. Try to read the comments from the perspective of the person receiving the feedback. Is it easy to understand what you are trying to say? Are the comments relevant?
Everybody hates getting back a code review that is blocking a merge. Please don’t waste your colleagues’ time by making them guess which word you misspelled. Make sure your colleagues read only what they need to know. In cases where a discussion is necessary, this is usually best done in person or through a video call. It speeds up the process, allowing everyone to be on the same page. It will enable everyone to stop the other person and say, “Stop. What do you mean? It should be clear after the review which comments (if any) need to be addressed before merging the code. Only automated controlled processes can provide repeatable metrics. A metrics-driven code review tool gathers data to make your information accurate without human bias.
Authors should annotate code before the review. Annotations guide the reviewer through the changes. They first show which files to look at and defend the reason behind each code modification. Annotations should be directed at other reviewers to ease the process and provide more depth in context. As an added benefit, the author often finds other errors before the peer review begins. More bugs found before peer review will yield lower defect density because fewer bugs exist.
Peer review can put a strain on interpersonal team relationships. Having every piece of work critiqued by peers and having management check and measure defect density in your code is complicated. So, for peer code review to be successful, managers must create a culture of collaboration and learning in peer review.
Regimented peer reviews can stifle productivity, yet lackadaisical methods are often ineffective. It can be tempting to tear through a check, assuming someone else will catch the errors you don’t see. A 200–400 LOC review over 60 to 90 minutes should yield 70–90% defect discovery. If ten defects existed in the code, a conducted study would find between seven and nine.
Code reviews in a reasonable quantity, at a slower pace for a limited amount of time, result in the most effective code review. Studies show that taking breaks from a task over a while can improve the quality of work as you should only review code for a short time in one sitting. Conducting more frequent reviews should reduce the need to review this length.
The knowledge that others will examine their work drives people to produce a better product. This “Ego Effect” incentivizes developers to write cleaner code because their peers will see it. We need to build with equality in mind and improve those together with our teams. This is part of building a culture around continuous learning, a vital sign of safe teams. We can help teammates learn from each other through code reviews, mentoring, or knowledge sharing. We can also use retrospectives to discuss and improve how we work together. Blame post-mortems are a great tool to foster a learning culture to understand problems and drive toward solutions. It’s essential to keep in mind that the way we discuss failure on our teams will shape the culture that we have.
