Work in Review

Most developers will have been there at some point - the code is written, the tests are passing, and all is right with the world. The final commit is in place, and a pull request opened. That is when the trouble starts. The code is pulled hither and thither, edge cases that should have been obvious are pointed out as being missed, and former confidence gives way to doubt and frustration.

Code review is often the most under-rated and misunderstood part of the development process. All too often it is seen as just another obstacle thrown up between coding and release; another hoop through which to jump. I'd like to offer a view to the contrary - that code review has the potential to be one of the most useful parts of the process and, when approached properly, needn't be as frustrating as it sometimes is.

A code review has three purposes

1. Learning
2. Code improvement
3. Safety

Learning

The most individually beneficial aspect of a code review is that of ongoing education. Feedback provided by those with additional and different experience is a great way to add to the toolbox of methods and techniques available to a developer. There is also an another aspect of a code review learning that is often overlooked - the fact that the reviewer can gain from the process every bit as much as the developer whose work is being reviewed. One thing that every developer could benefit from is reviewing the work of those with greater experience, as well as having their own code reviewed.

Perhaps the most important thing a developer can do to get the most from the process of code review is to consistently remember that corrections and suggestions are not personal. If the reaction to a comment or suggestion is to get defensive, then learning from it becomes almost impossible. This is, of course, easy to say but much harder to do. A successful strategy that I have found in my own experience involves the developer consistently reminding themselves of the objectives listed above whilst reading the comment, but also the reviewer being aware that the person reading the review will [hopefully] have invested a significant amount of time and effort in writing the code and that common courtesy goes a long way. A comment framed as a question or as helpful instructive feedback is generally far better received than a comment written in a highly critical manner.

Code Improvement

The feedback provided by colleagues allows a developer to gain insights into different ways of thinking that they would not otherwise have considered. It is important to say that this is not usually a sign of a deficiency in the abilities of that particular developer. The reason different developers think of different things in different ways is that they are different people. A code review is the most efficient way of infusing multiple ways of thinking into one particular piece of work.

Safety

This last purpose is almost self explanatory. Every developer is susceptible to the problems inherent to spending a long time working on a piece of code - they're looking at the entire problem in one particular way. The data-flows are moving in a small set of patterns, and the edge cases are hard to see. The trouble is that these edge cases are often capable of making considerable mischief. Code review by a developer with a "fresh set of eyes" can make a dramatic difference in the number of these potential problem-cases that are handled and tested for.

What now?

The first way to respond to the above is by simply increasing the quantity of code that we review, particularly from other teams within the same organisation. Doing this increases each developer's knowledge of the code base, and grants a more intimate understanding of how new changes and modifications work, which means that not only do developers get exposed to a wider cross section of the code base, but their knowledge of those sections is kept incrementally up to date. This is a fairly simple step that produces very real and fairly quick benefits.

The benefit of embracing better review practices yields rewards well beyond the realm of development.

In the longer term, it is important to note that the culture of a development team is in cyclical influence with its attitude toward code review. If team members perceive code review more in terms of opportunity and creativity than of obstacle and criticism, this will have positive impact on the mindset of the team as a whole. If people are more willing to listen to each other's constructive feedback within a team, then they are likely to be more willing to engage with other teams and accept inputs to their work from other points of view. In short, the benefit of embracing better review practices yields rewards well beyond the realm of development.