Some of our customers are telling us that they are using CodeStream to shorten code reviews by as much as 50%. It’s a lightweight approach, and we are trying to learn from their experience and feedback, and improve on the processes and features we offer to make those code reviews even better. CodeStream introduces the concept of a continuous code review, a light-weight, in-editor process that enables the review of any part of your codebase, at any time. Making code review continuous means you can get feedback earlier in the process as you are stubbing out functions and classes, during heavy development while you are building a new feature, immediately prior to merge as you seek feedback from your team, and importantly even for code that was merged some time ago, as you come across technical debt in your codebase.
According to Traci Lum in her article How to Give and Get Better Code Reviews, code reviews are among the most dreaded activities by developers. Developers, who typically spend much time creating, imagining, and inventing (often on their own and without interference), face an uncreative procedural judgment. She writes: “...it’s a time when you, the developer, the craftsman, the artist, present your work before a council of critics and beg them to bless your masterpiece with a thumbs-up emoji and a “LGTM.””.
Code reviews are, of course, necessary to maintain code quality. Why such dread? What can be done to reduce it significantly? What are the benefits of a different approach? Much of what’s wrong with code reviews boils down to three elements:
In this context, let’s discuss some of the suggestions provided by Traci on how to improve the code review process, and suggest improvements to the improvements.
Developers generally live in their IDE. That is the place where code is written, changed, compared, etc. The reason why code reviews are not performed in 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 and the disjointed nature of the process might have been avoided.
Traci Lum’s suggestions are helpful and reasonable and they are centered on improving the PR process. Let’s summarize her recommendation while addressing potential improvements that could be made if the code review was started earlier and originated in your IDE instead of a PR.
If you want to get better code reviews, her suggestions include:
A. Linking to the GitHub issue or JIRA ticket from the body of a PR
B. Writing a quick summary or list of the changes, trade-offs, and remaining todos
C. Tagging pull requests with labels
D. Review your own code before you officially put it up for review
E. Annotate places where you’re especially unsure or want feedback
F. Tag the right people
G. Take a breath and internalize the reviews
If you want to give better code reviews, her suggestions are:
H. Ask questions instead of making statements, that is, fewer WTFs
I. Articulate the problems (if any) and suggest alternatives
J. Try to understand the context and the proposed solution
K. Highlight wins, by which she means, be positive when giving feedback
If the PR is to remain the primary place where a code review takes place, all of the steps suggested by Traci in order to improve the process would be fine. However, if we are prepared to consider beginning the review process earlier, prior to a PR, unencumbered by the PR, the code review becomes continuous, that is, at any time, on any line of code, about any issue.
In Part 2, we will explore other suggestions for improving the code review, and offer ideas on how to make things even easier, more productive, and more pleasant.
Please share your thoughts and feedback @teamcodestream.
CodeStream helps development teams discuss, review and understand code. CodeStream links comments and issues directly to the code blocks they refer to, making them instantly available to everyone on the team.