10 Ways to Make Your Peer Code Reviews More Effective

Photo by ThisisEngineering RAEng on Unsplash

As a developer, you have a give-and-take relationship with code reviews. You’re measured by what you ship, not what you review. Yet, you also recognize that code reviews can make you and your work better. Striking the right balance between code review efficiency and utility is tough.

We’ve been refining Revelry’s code review process for years and we’ve found good ways to harmonize the need to ship with the need to review. The following code review tips make our development work a lot easier and we think they’ll help you, too.

Tip 1: Prepare your code for review

Make sure your code is ready for review before making a git pull request. All the obvious problems should be handled by you before the reviewer sees it. Static code analysis tools can help here because they identify the overt issues without expending reviewer time. 

Tip 2: Keep git pull requests short

Review size is one of the top challenges reviewers face, so as a code author you should respect your reviewers’ time by creating manageable git pull requests. Aim for 200-400 lines of changes per request

Tip 3: Ask questions to get better feedback

It helps to ask your reviewer questions and call out particular focus areas in the code. Pose questions like “What do you think about this function?” and “Is there a more efficient way to handle this?” 

Tip 4: Mix up your code reviewers

Be mindful when you’re picking code reviewers. Look for people who know the most about a particular area or language, and resist the urge to select reviewers who go easy on your code. A diversity of perspectives and experiences will lead to better results. 

Tip 5: Get and give timely feedback

Research studies have found that the median time for code approval can run from a few hours to a full day, depending on the organization. There are a number of ways to reduce these review delays, or at least make reviews more efficient. You can cover outstanding pull request reviews in daily standup meetings—this helps because the whole team is together and people are not yet immersed in their own code. You can also manage review feedback with a notification system, like Pull Reminders, and through the assigned tool built into GitHub.

Tip 6: When reviewing code, be kind and constructive

Remember that the code you’re reviewing could be the byproduct of a messy process, and the code author might feel vulnerable. The point of a review is to improve the code, not undermine morale, so you should watch what you say and how you say it. Strive to be collaborative and conversational in your feedback. Call out the good as well as the bad. Look for ways to offer context and solutions.

Tip 7: Avoid the LGTM rut

Don’t be one of those reviewers who tosses off  a “looks good to me” (LGTM) comment without reviewing the code. You’re not doing your colleagues, your organization, or yourself any favors by mailing in feedback. As a reviewer, push yourself to leave at least one substantive comment. This gets you over the hump of reading the code, and it’s much easier to add questions and comments once you’ve kickstarted the process. 

Tip 8: Tackle complex code in a meeting

As much as you might hate meetings, they’re a useful option when you’re reviewing risky or complicated projects. In a code review meeting–held remotely or in the same room–the reviewer gets immediate answers to questions and the code author can explain things without drafting crisply written replies. Another upside to code review meetings: research has found they can increase the detection of defects by more than 30%.

Tip 9: Get peers on board with code reviews

What do you do if you want to see better and more code reviews, but your teammates don’t prioritize them? The easiest time to promote the benefits of reviews is when an oversight contributes to a customer-facing bug. Be sure to take a thoughtful approach with your advocacy:

  • Wait until the bug is fixed and people calm down, but not so long that no one cares anymore. 
  • Start with what everyone can see: the bug, its root cause, and the impact on customers. 
  • State your belief: “I believe we would have caught this bug if someone with fresh eyes had read this code and asked questions about how it worked.” 
  • Finally, ask for buy-in: “Can you help us catch more bugs before they ship by doing a few code reviews each week?”

Tip 10: Make your code reviews rewarding

Code reviews offer a clear view into how people think, so take note of the ways your colleagues solve problems and handle feedback. You’ll undoubtedly pick up a new technique or a better approach. Code reviews also give you a chance to understand and influence your organization’s output at its most granular level. Small and consistent improvements have a lasting impact if you put care into the work. 

A new tool for smoother code reviews

We’ve run into all of these code review issues at Revelry, and finding solutions has required a mix of trial and error and custom tool development.

One of those tools is Lintron, the static code analyzer we built to automatically catch mistakes. Lintron helps our developers in a bunch of ways:

  • It works with Python, JavaScript, Ruby, and a number of other languages. 
  • You can add Lintron to your project in just a couple of minutes and receive a code review on your next pull request. No changes to your code are required.
  • Lintron leaves code review feedback in your pull request, right along with all of your other reviews.
  • If you already lint your code locally, Lintron will use the same configuration so you have one consistent style guide. You can also customize your settings per repo or even per branch.

Lintron has been a labor of love for us, but now we’re opening it up to everyone because we think the benefits we’ve seen can give developers a lift. We hope Lintron helps you as much as it’s helped us.

Lintron. Automate your code reviews. Powered by /Revelry.

Sign up to install Lintron

More Posts by Robert Prehn: