Crafting Better Code Reviews

© geek & poke, http://geek-and-poke.com

Why even bother with review?

The original intent behind code reviews was that they would help us take collective ownership in the creation of our software. In other words, we’d each be stakeholders in our development process by having a hand in controlling the quality of our products.

1. Inspections

2. Walkthroughs

3. Short code reviews

What do developers think of code reviews?

The quantitative data

The qualitative data

Ultimately, what seemed to make or break a code review experience depended upon two things: how much energy was spent during the review process, and how much substance the review itself had.

Energy

  1. No one feels good about a code review process that’s just a formality & doesn’t carry any weight.
  2. It’s not fun to review a long PR with code that you’re unfamiliar with, or have no context for.
  3. To err is human, and we’re all human. We should all be reviewed, and review others fairly.

Substance

  1. Comments nitpicking purely at syntax lead to a negative experience. Style and semantics are not the same thing. (Interestingly, 5% of respondents used the word nitpick to describe code review comments in a negative context.)
  2. The words we use to review one another’s code really do matter. An unkind review can break someone’s self-confidence.

How do we do better?

Instead, it is the act of introspection, reflection, and reevaluation of our collective code review culture that will allow us to build upon any kind of formalized review process we might have.

Easy ways to improve your code review process

  • Implement linters or a code analyzer (if available) in order to eliminate the need for syntactical comments on a pull request.
  • Use Github templates for every pull request, complete with a checklist to make it easy for the author of the code and the reviewer to know what to add, and what to check for.
  • Add screenshots and detailed explanations to help provide context to teammates who might not be familiar with the codebase.
  • Aim for small, concise commits, and encapsulated pull requests that aren’t massive in size, and thus much easier and quicker to review.
  • Assign specific reviewers to a PR — more than one, if possible. Make sure that the role of reviewing is equally distributed amongst engineers of each and every level.

The harder things — but the most important

  • Develop a sense of empathy on your team. The greatest burden of making this happen falls on the shoulders of senior, more experienced engineers. Build empathy with people who are newer to the team or the industry.
  • Push for a culture that values vulnerability — both in actions and in words. This means reevaluating the language used in pull request comments, identifying when a review is on track to turn into a downward spiral, and determining when to take conversations offline, rather than questioning the author of the code publicly.
  • Have a conversation. Sit your team down, start a Slack channel, create an anonymized survey — whichever fits your group’s culture best. Have the conversation that will make everyone comfortable enough to share whether they are each happy with the current code review process, and what they wish the team did differently.

I love code reviews in theory. In practice, they are only as good as the group that’s responsible for conducting them in the right manner.

Resources

Acknowledgements

--

--

--

Writing words, writing code. Sometimes doing both at once.

Love podcasts or audiobooks? Learn on the go with our new app.

Recommended from Medium

CSGO team analysis with Python and Pandas part 01

How to use ZFS + zfs-auto-snapshot package + Samba to support Windows Shadow Copy on Ubuntu 18.04

Lab 3: Sensing Potentiometer

Learn how to Refund retail customers through Check in Microsoft Dynamics D365

Supernova’s Code Generation Journey

Connect Azure Point-to-Site VPN to Android Device

Design Data Structure (Part II: LFU Cache)

Odoo tips of the Month : May 2020

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Vaidehi Joshi

Vaidehi Joshi

Writing words, writing code. Sometimes doing both at once.

More from Medium

The Software Engineering Interview — The Tech Screen

Why are message queues so important in software engineering (and pizza shops)?

Queue

Explaining System Design to Grandma

How Doing Queries In Views Can Degrade The Performance Of Your Application