You might wonder if code review is necessary if your team practices pair programming. (Assuming that your team does either code review or pairing.)
Pair programming was originally one of the practices pushed by Extreme Programming (XP). The reasoning was pretty straight-forward, if we assume code review produces better outcomes, more frequent code review should be better. Turning code review up to eleven would be some form of continuous review, which is a reasonable first approximation to pairing. Anyone who has pair programmed recently is probably aware of many more benefits than just continuous review that come from pairing.
The question becomes if pairing is code review turned to 11, what would be the point of a separate code review?
Benefits of Pairing
Part of the benefit of a code review is having someone else look at code with fresh eyes (different viewpoint or assumptions). Pairing does this to some extent because each member of the pair approaches a problem with different history, knowledge, and mindset. Many of the obvious benefits of pairing are:
- improve an approach by seeing it from two viewpoints
- reduce the mistakes we all make when tired, distracted, or just working on the same problem for too long
- reduce shortcuts, at least the ones that you can’t justify to your pair
- reduce typos and simple logic bugs simply from two sets of eyes on the code
It’s not surprising that the longer two programmers pair on the same change, the more their understanding of the problem comes to align. Starting with two viewpoints means this understanding is more likely to be pointed in the right direction, but that’s not guaranteed. If one member of the pair is more senior and the other has a tendency to defer to experience, you still have one viewpoint. If one of the pair is disengaged for some reason. If the two have paired quite a bit, they are more likely to recognize how the other approaches problems. None of these is bad or guaranteed to result in a bad result, they just have the tendency to reduce the critical eye you are applying to your pair’s decisions.
Code Review
In a code review, you are approaching the code without the benefit/handicap of having seen it grow. This allows the possibility of being slightly more likely to question an approach or assumption, or just notice an edge case that the pair missed. A reviewer might look for potential maintenance issues that result from a change. They will think about interactions that might not have been obvious to the pair that is deep in implementation. They would also question whether design decisions are well-understood and explained.
One other benefit of a code review is the ability to bring in a specialized viewpoint without needing the same skills for every pair. Your team might have one person who is especially knowledgeable about databases, or someone who is an expert on security, or the domain expert for your business. The team could not afford to put all of these experts in every pair, but they can lend their expertise by reviewing code.
Conclusion
A code review won’t catch every mistake, and it doesn’t replace pair programming. Much like automated testing and code review cannot replace each other, pairing and code review serve overlapping, but different, purposes. From this argument, you should see that code review is still useful, even when practicing pairing.