Elrich suggested a peer review technology combined with version control and release build systems.
I undertook to write a list of criteria for evaluating such systems. Here are some links I found useful to form a concept of code peer review as a professional practice in my mind.
A key Agile Principle is: “The best architectures, requirements, and design emerge from self-organising teams.”
If peer code review is mandated by someone outside the team, its chance of success decreases. If team members do not want code review to succeed, it will fail.
Even when suggested by a team member, code review can still face resistance. A key to success is to start slowly. Do not attempt something like: “Starting today 100% of all code written must be peer reviewed.”
Types of Lightweight Code Review
Lightweight code review provides the right mix of code review process with agile practice, allowing
effective and efficient code reviews without overwhelming burden. There are four different
approaches to doing lightweight code review in an agile environment. Each has its strengths and
weaknesses and they are not mutually exclusive, so there is no single right or wrong approach. As
with so much in the agile world, each team needs to decide for itself which approach is correct.
1. Over the shoulder. This is the easiest technique of all: when it is time for a code review, find a
developer and sit down with him or her in front of the code. Face to face communication is an
easy, high-bandwidth medium for the author’s explanation of the code.
An obvious drawback is that not all teams have all members in one location. An additional
issue is that the reviewer is being interrupted – after the review it will take time for that
developer to get back to the same level of productivity.
The biggest risk with this sort of approach, though, is that it can end up being a walk through
instead of a review. If the reviewer has no prior access to the materials then typically the
author does most of the talking, which can result in a passive reviewer who spends more time
nodding than asking questions about the code.
2. Email pass-around. When the code is ready, send it out over email. One of the advantages of
this approach is that reviewers and authors can be in different locations. Another advantage
is that the reviewers can do the review at their convenience.
One obvious downside is that as the review proceeds and the emails get nested in multiple
replies, it becomes more difficult to follow the conversation. And if files are reworked and line
numbers change, it can be challenging to determine which version of a file – or even which
line – is being referenced by a particular comment. But perhaps the biggest drawback is that
it can be difficult to answer a simple question: When is the review finished?
3. Pair programming. One of the Extreme Programming world’s key contributions has been pair
programming, which in some ways is a continuous code review. The advantages are that no
workflow or tools or interruptions get in the way. Further, the review is at a deep level since
the developer who is reviewing has the same level of experience with the code.
One obvious downside is that the time commitment is non-trivial. A less obvious downside is
that the reviewer is “too close” to the code to give it a good review. After all, a key benefit of
code review is to get outside opinions. If two developers are pairing to the extent that they
have the exact same view of the code then the code review will likely not be as effective.
4. Tool-assisted review. Code review tools exist to help
overcome the shortcomings of the approaches listed
above. They can package up source files, send
notifications to reviewers, facilitate communication,
ensure defects are fixed, and more. The obvious
downside is that they require at the very least time for
installation and configuration, and in the case of
commercial products, money for license purchases.