English | EN 
All software development teams strive to ensure the code they ship performs as designed, free of bugs. One of the cornerstones of pursuing that objective is code reviews, a process often formalized through pull requests to a code repository.
Unfortunately, too often teams become beholden to the rules and rituals of a system intended to boost quality that, paradoxically, leading them to deliver inferior code at a slower pace. In this post, I will examine some of the common pitfalls development teams face reviewing code, as well as ways to surmount them.
Many enterprise development teams adopt a workflow that adheres closely to what source control management tools like Bitbucket and GitLab provide. Developers create feature branches from their git repository, make the code changes needed to satisfy the requirements of their ticket, and then make them available to their peers for review through a pull request. Other developers on the team then look over the code and suggest changes. Once enough are satisfied, the code is merged back into the main branch and the delivery process moves forward.
While this may seem a straightforward approach to ensuring quality, opportunities for confusion, delay, and even maleficence can arise. Perhaps the most significant obstacle to effective code reviews is that the process often does not get the same degree of consideration and care as writing code.
In my experience, development teams often have no guidance about how to conduct code reviews. They do not discuss or agree on standards, such as how they should go about reviewing code, the kinds of issues they should look for and how they can best report their feedback. Implicit is the assumption that if someone knows how to write code, they will also know how to analyze it effectively. However, just as with human languages, just because someone is a good writer does not mean they are also a good editor.
Another factor is teams often do not effectively integrate code reviews into their workflows by allocating adequate time to developers to conduct reviews. To the extent they even consider it, team leaders just assume their developers will find the time, somehow, between attending meetings, responding to messages and writing their own code, to provide feedback to others.
Exacerbating this time crunch is the way projects often evaluate developer effectiveness, i.e. the number of issues or story points they deliver when working in an Agile process. This incentivizes developers to spend more of their time writing code and less reviewing code. As a result, teams can develop a tendency to “code now, review if I ever have time” ethos that results in superficial, cursory reviews. Developers may spot and point out obvious errors but may not think deeply about whether code is written appropriately for a given context, delve into the possibility of unintended side effects, or consider design and implementation decisions that would lead to cleaner, more efficient higher quality code.
Sometimes the code review process can even become toxic, with team members more interested in settling scores that promoting quality. Junior developers can be nervous about critiquing their more experienced counterparts, fearing retribution for speaking out. Other times people have an axe to grind with a colleague and will use pull requests as a means of harassing them. These scenarios can be disastrous for maintaining good team dynamics, especially when a power imbalance already exists among team members. While such teams likely face larger challenges than code reviews, establishing ground rules for conducting them can help prevent such issues from arising in the first place.
Many strategies exist to mitigate the impact of the challenges I have described. Pair and group programming offers an ongoing, de facto review process by its nature. Other teams take a “build fast and break things” approach, allowing developers to implement incremental changes without formal approval required to merge, with a mind to fixing problems quickly when they arise. Still others continue to adhere to a pull request-focused process but develop explicit standards and strategies such that code reviews foster adding value and enhancing quality rather than serving merely as quality theater.
Not all solutions will be a good fit for all teams. The most important thing for leaders of software projects to recognize is that if they want code reviews to positively impact code quality, they must devise thoughtful, deliberate workflows for carrying them out as well as regularly evaluate and revise them. Doing so will go far toward building higher quality code, delivered faster by happier developers.
