Software engineer Dan Goslen recently published an article on how he’s going to change his approach to code reviews.
The most widely used organizational pattern for conducting code reviews probably is the pull request, also called merge request. This particular pattern and the tools source code management systems provides us with to support this pattern lend themselves to a review strategy that focuses on commenting on code and minute details rather than the big picture and collaboration and knowledge sharing.
The goal of code reviews isn’t to find bugs or to track down formatting and code style issues. Its first and foremost purpose is to foster collaboration and enable knowledge sharing.
Formatting and a consistent code style can be enforced using automated tools such as a linter. Nowadays, IDEs even make style suggestions while you’re writing code. Focusing on ways of improving code which can be automated by and delegated to machines not only wastes valuable developer time but a lot of potential as well.
Dan suggests a more high-level approach to code reviews that regards the reviewer as more of a navigator rather than a backseat driver. While the latter will generally point out how a particular line or segment of code could be changed the former will focus on the desired outcome and why a change is need. This might seem like a subtle difference but it’s a significant one because it changes the dynamics of how a code review is carried out.
This approach turns the attention to what the code in question is trying to achieve. Describing the intended outcome of a code change now becomes the primary objective. Actually running the changed code to see what it does is key to understanding the whole rather than the sum of its parts.
These activities in turn promote knowledge sharing and prevent silo scenarios where only the original creator knows what a code change does as a whole.