When I started working as a developer 5 something years ago, I was under the impression that code reviews were an unnecessary overhead from a developers time. I thought that the 'star' developers would only write code and everyone else would do the boring stuff such as reviewing! Boy, was I wrong! I realized fairly early the importance of code reviews. Hopefully this post will help you with your code reviews. Here goes -
Establish a review language with the team
I have seen that different teams have different strategies that work for them. There are teams that like to have very strict reviewing protocols while others like to keep the review conversational. One of the first things we can do as developers is establish that review language with the team. For my team, a conversational approach to the review works. We add comments on a piece that we have concerns about. The owner of the PR will then add clarifications or make the suggested changes. I have seen some teams have a formal review process. The reviewer adds comments and the comments are then converted into tasks that the owner of the PR works on/addresses. Find what works for you guys and stick to it!
Give suggestions not solutions
Code reviews are a nice way to foster technical thinking. Often times I have seen senior developers give the solutions to the problems that the find in the review. Although this might be beneficial in the short term as it is faster, it is problematic in the long term. By giving the solution you are revoking the owner's opportunity to stretch their technical muscle.
Ex - Say 'Hey! I think we are iterating over more records than we should. Is there a more efficient way to do it?' instead of 'Hey! I think we can make this more efficient by using the filter function provided in the utility package.'
Do collaborative reviews
We sometimes underestimate the value a collaboration session can have! For most complicated changes, one of the most efficient way to review is to set up a joint session with the whole team (owners and reviewers). In this session the owner of the PR can go over the change and explain the thought process that led to the change. That added context reduces review times by a huge margin. Our team usually has regular sessions in the week where we discuss new PRs. This is a fun way to add collaboration to the seemingly solo process of code review.
Top comments (0)