Code reviews help improve code quality and help share knowledge. Yet, posts about the dread and hatred of code reviews are plentiful. One of the most authoritative surveys tells us that only 45% of respondents are either satisfied or very satisfied with their process. With almost 80% of respondents participating in code reviews either daily or bi-weekly, it’s time to streamline code reviews to help everyone move from dread to alignment. This is what we suggest:
1. Learn from market leaders
Google and Microsoft use different code review tools, each developed in-house. They consider them essential to code quality, learning and knowledge sharing. What can we learn from them?
Dr. Michaela Greiler has published a paper that includes a survey of 900 Microsoft developers. For motivation, code quality tops the list, followed by knowledge transfer. The selection of reviewers is important, facilitated by their tool called CodeFlow. Turnaround time is expected under 24 hours. They do not have a standardized process company-wide.
RELATED CONTENT:
Testing all the time
5 ways static code analysis can save you
Don’t become a statistic: How to save your failing software development initiatives
At Google, code reviews have been standardized since the beginning. In terms of motivation, C. Sadowski et al. state that “the main impetus behind the introduction of code review was to force developers to write code that other developers could understand.” The focus was knowledge retention by ensuring that more than one developer understood the code. Their tool, called Critique, is widely used. Every change is reviewed and the process is optimized for speed. Reviews are small and frequent, and turnaround is under 4 hours.
2. Discuss more, review less
Most reviews happen too late. If you put a lot of effort into your work before you have alignment with your reviewer, you are likely to be upset if she doesn’t agree. For a better process, don’t wait. Front-load by sharing concepts before you flesh them out. You will be better aligned and happier.
Some have suggested that initiating a pre-commit review with a Git branch is good enough. Moving away from your editor at the pre-commit stage limits rather than enhances the discussion. We prefer a methodology we refer to as continuous. You need a good in-editor discussion tool to facilitate the process.
Making code review continuous means you get feedback earlier, as you are stubbing out functions and classes, during heavy lifts while building new features, immediately prior to merge, and even for code that was already merged, as you encounter technical debt.
3. Don’t let pull requests limit the discussion
Surveys indicate that 69% of teams do reviews through Pull Request and Commit comments. A majority of developers prefer lightweight reviews. Simultaneously, developers consider knowledge sharing to be their greatest challenge. We believe there is an opportunity to turn a code discussion into persistent documentation that becomes institutional knowledge, while making code reviews more productive. But the PR is holding us back due to the following limitations:.
- turnaround time is often too long,
- context switching away from the editor hinders discussion
- a typical review looks at code only once – premerge – and does not facilitate improvements later. And finally,
- the wasted institutional knowledge sharing opportunity.
The solution to all four of these limitations lies in avoiding context switching and front-loading the code review back into the IDE.
4. Stay in your IDE
If we begin the review process earlier, prior to a PR, the code review becomes continuous, that is, on any line of code, about any issue. As Google has shown, reducing the number of lines of code so that reviews can happen in 4 hours optimizes the flow. What would be the right approach to make the turnaround even faster?
Developers generally live in their IDE. That is the place where code is written and changed. The reason why code reviews are performed outside your IDE is an accident of timing. Had IDEs been more extensible earlier, we would have seen all the benefits of performing code reviews in context, faster, and with less friction.
5. Discuss first, review second
Jonathan Maltz of Yelp provides these key messages to improve reviews in his Code Review Guidelines.
- Communication is key
- Smaller is better
- Code reviews are a discussion, not a dictation
- Time is of the essence
If communication is key, how are you communicating? Within the PR, away from the code context? Why not avoid context switching altogether and stay in your editor to discuss code?
Smaller is better means that small chunks are easier to understand, process and learn from, just like Google suggests. Why not make it as small as possible? What if you could just request a review of any line of code without a PR?
Code reviews are a discussion means that you need a continuous conversation to get the best results. A PR comment is not designed to enhance the quality of the discussion.
Time is of the essence refers to turning around the review as soon as possible. In a continuous code review context, reviewer and author work through small chunks quickly so as to find resolution and maintain momentum. Issues can sometimes be resolved in minutes.
6. Start a continuous code review
What happens to the code review process when you embed it in your coding flow rather than wait until the code is “ready” to review?
- Developers can get and give feedback on any part of your codebase, without the overhead of creating a PR.
- They can ask for feedback on a WIP, or flag tech debt on already merged code with in-editor tools that don’t require a context switch.
- The code review shrinks and becomes a validation of decisions that were made collaboratively earlier.
The continuous code review represents an order-of-magnitude reduction of friction for code discussion. By allowing a review to happen on any line of code without a PR, and without leaving your editor, you have the opportunity to radically improve developer satisfaction and code quality.
