19
2.7 Implicit Advantages of Code Review to Development Practices
Integrating code review into a company’s development processes can have many benets which will depend
upon the processes and tools used to perform code reviews, how well that data is backed up, and how those
tools are used. The days of bringing developers into a room and displaying code on a projector, whilst record-
ing the review results on a printed copy are long gone, today many tools exist to make code review more
ecient and to track the review records and decisions. When the code review process is structured correctly,
the act of reviewing code can be ecient and provide educational, auditable and historical benets to any
organization. This section provides a list of benets that a code review procedure can add to development
organization.
Provides an historical record
If any developer has joined a company, or moved teams within a company, and had to maintain or enhance a
piece of code written years ago, one of the biggest frustrations can be the lack of context the new developer
has on the old code. Various schools of opinion exist on code documentation, both within the code (com-
ments) and external to the code (design and functional documents, wikis, etc.). Opinions range from zero-doc-
umentation tolerance through to near-NASA level documentation, where the size of the documentation far
exceeds the size of the code module.
Many of the discussions that occur during a code review, if recorded, would provide valuable information
(context) to module maintainers and new programmers. From the writer describing the module along with
some of their design decisions, to each reviewers comments, stating why they think one SQL query should be
restructured, or an algorithm changed, there is a development story unfolding in front of the reviewers eyes
which can be used by future coders on the module, who are not involved in the review meetings.
Capturing those review discussions in a review tool automatically and storing them for future reference will
provide the development organization with a history of the changes on the module which can be queried at a
later time by new developers. These discussions can also contain links to any architectural/functional/design/
test specications, bug or enhancement numbers.
Verication that the change has been tested
When a developer is about to submit code into the repository, how does the company know they have su-
ciently tested it? Adding a description of the tests they have run (manually or automated) against the changed
code can give reviewers (and management) condence that the change will work and not cause any regres-
sions. Also by declaring the tests the writer has ran against their change, the author is allowing reviewers to
review the tests and suggest further testing that may have been missed by the author.
In a development scenario where automated unit or component testing exists, the coding guidelines can
require that the developer include those unit/component tests in the code review. This again allows reviewers
within this environment to ensure the correct unit/component tests are going to be included in the environ-
ment, keeping the quality of the continuous integration cycles.
Coding education for junior developers
After an employee learns the basics of a language and read a few of the best practices book, how can they get
good on-the-job skills to learn more? Besides buddy coding (which rarely happens and is never cost eective)
and training sessions (brown bag sessions on coding, tech talks, etc.) the design and code decisions discussed
during a code review can be a learning experience for junior developers. Many experienced developers admit
to this being a two way street, where new developers can come in with new ideas or tricks that the older de-
velopers can learn from. Altogether this cross pollination of experience and ideas can only be benecial to a
development organization.
Secure Code Review