Code Reviews
What and How
Copyright © 2016 Curt Hill
Introduction
• A code review is a systematic
examination of code to eliminate
defect
– AKA a peer review
• Typically carried out with
developers in addition to the author
• Several variations of this exist and
all have been shown to find bugs
• Performs the same function as static
analysis tools
– Which are sometimes called automated
code reviewCopyright © 2016 Curt Hill
History
• Gerald Weinberg promoted egoless
programming and code reviews in
and 1971 book
– These are informal
• In 1976 when Michael Fagan
publishes a paper concerning what
is now known as a Fagan inspection
– Fagan formalizes the process
• This inspection may be applied to
code, specifications and other
documents
Copyright © 2016 Curt Hill
Common Sense
• Your typical book has an
acknowledgment section
– It may be titled that or be part of the
preface
• In it those people who contributed to
the book are listed
– Some of these proofread or made other
readability suggestions
• If we do this for a book, how much
more should we do it for code that
may seriously impact someone’s
life?
Copyright © 2016 Curt Hill
Types
• Code reviews can be roughly
categorized as heavyweight and
lightweight
– Corresponds to formal and informal
• Fagan inspection, among others, is
heavyweight and formal
• There are also many lightweight and
informal approaches
– We should do one of these in class
Copyright © 2016 Curt Hill
Fagan Inspection
• We will consider several aspects of
this process
– The roles involved
– The process steps
Copyright © 2016 Curt Hill
• Moderator
Roles
– Responsible for the inspection session,
functions as a coach
• Developer
– The person who wrote the code
• Reviewers
– Reviews the code
– These should also be developers that
are proficient in the language of the
code
– From same team
Copyright © 2016 Curt Hill
Process
• The process is six steps
– The first five are a loop
•
•
•
•
•
•
Planning
Overview
Preparation
Meeting
Rework
Follow-up
Copyright © 2016 Curt Hill
Planning
• The moderator is contacted when
the developer believes code is right
• Preparation of materials
– Typically hardcopy of the code and
specifications
• Selection and notification of
participants
– Reviewers and developer
• Arranging of meeting place and time
Copyright © 2016 Curt Hill
Overview
• Group education of participants on
the materials under review
• Assignment of roles
• This is the ground rules of the
process so that everyone
understands how the task will be
accomplished
Copyright © 2016 Curt Hill
Preparation
• The participants prepare their roles
• The participants review the code to
be inspected
– This includes the specifications and
any supporting material
• They prepare for the meeting by
looking for possible defects and any
questions as to the code
Copyright © 2016 Curt Hill
Inspection meeting
• Moderator facilitates a face to face
meeting
• The reviewers and developer
discuss what was found and how to
correct
• The developer will take the results of
the meeting for the next step
• If there are no defects we proceed
to follow-up
Copyright © 2016 Curt Hill
Rework
• The defects found during the
inspection meeting are now
resolved by the developer
• The list of defects is used to correct
the code until the requirements in
the high-level document are met
• When this is completed we go back
to the planning step
Copyright © 2016 Curt Hill
Follow-up
• The moderator is responsible for
verifying that the defects have been
corrected and no new ones
introduced
• The change is completed after this
Copyright © 2016 Curt Hill
Costs and Benefits
• As you can see, the process has
some serious costs
• It has shown itself to be effective as
well
• It may be applied to a variety of
products, not just code
Copyright © 2016 Curt Hill
Lightweight reviews
• There are a number of variations of
the lightweight review
• Not all of these involve a face to face
meeting
• One of these that you have already
seen is pair programming of XP
– There are always two sets of eyes on
each line of code entered
• Another are those static analyzers
previously considered
Copyright © 2016 Curt Hill
Over the shoulder
• When code is ready have one or two
colleagues examine it with the
developer at a workstation
• This is the oldest form of peer
review and least formal
Copyright © 2016 Curt Hill
The email inspection
• When a change is “complete” the
developer or a supervisor mails it
and the specification or bug report
to each member of the team
• When time permits each person
checks the code and returns
comments to the sender
• Typically there is a time limit
required for response
Copyright © 2016 Curt Hill
Informal Meeting
• Similar to the Fagan Inspection
meeting except:
– Only preparation is printing code and
calling meeting
– Reviewers come in without preparation
Copyright © 2016 Curt Hill
Reviewer questions
• Are there any obvious logic errors in
the code?
• Looking at the requirements, are all
cases fully implemented?
• Are the new automated tests
sufficient for the new code?
– Do existing automated tests need to be
rewritten to account for changes in the
code?
• Does the new code conform to
existing style guidelines?
Copyright © 2016 Curt Hill
Guidelines
• LOC to review should be much less
than 400
– Smaller codes produce better results
• Inspection rates of less than 300
LOC/hour result in the best defect
detection
– Larger rates will miss some errors
• Developers who prepare the review
with explanations generally have far
fewer defects
– Due to being forced to self-review their
Copyright © 2016 Curt Hill
code
More Guidelines
• Total review time should be less
than 90 minutes
– Less that 60 minutes is better
– Attention span issues tend to reduce
detection
• Expect error detections rates of
about 15 per hour
– Rate can only be higher with less than
175 LOC under review
Copyright © 2016 Curt Hill
Culture Guidelines
• Code reviews may be challenging to
developers
• They equate criticism of the code
with criticism of themselves
• Thus it is important for a culture of
collaboration to be established
• Code review should be a learning
experience for the developer as well
as the reviewer
• Using defect density metrics in
evaluation can chill the whole
Copyright © 2016 Curt Hill
process
Heavy or Light?
• It seems that most prefer lightweight
code reviews
• The place where the heavyweights
are preferred is those areas where
no defect may be tolerated
– Code where a lives depend on it
– Code that is extremely important for
corporate survival
Copyright © 2016 Curt Hill
Opposition
• Every technique has those in favor
and those opposed
• One of the problems in management
is confusing knowledge work with
physical labor
• The model of physical labor is
common in everyone
– Two ditch diggers produce twice as
much ditch
• This model does not translate well
into almost any thinking profession
Copyright © 2016 Curt Hill
Consider Pair Programming
• Inexperienced managers might
consider this paying two people to
do one task
– Two people on one shovel
• This approach is misleading
because both are considering the
code
– Number of characters typed per hour is
an absurd measure of programmer
productivity
Copyright © 2016 Curt Hill
Advantages
• To win over the opposition we need
to consider some of the advantages
of code review
• The most obvious one is better
quality at a lower price
• There are others as well
• Consider the following case study
Copyright © 2016 Curt Hill
Case Study
• A study cited at SmartBear.com is
summarized in two graphs on
subsequent slides
• 10 developers and 10,000 LOC
• The problem is that the later the bug
is found the more expensive it is
– QA finds for $200 per bug
– Customer reports cost $1000 per bug
and perhaps more if customer is lost
• Finding a bug in a code review costs
$25
Copyright © 2016 Curt Hill
Before
Copyright © 2016 Curt Hill
After
Copyright © 2016 Curt Hill
The Bus Factor
• A measurement of the concentration
of information in individual team
members
• It comes from the morbid but very
valid question: If Bill were hit by a
bus, how would that affect us?
– AKA the truck or lottery question
• Generally having vital information
concentrated in one or few
individuals is a bad for the company
– Especially when they leave
Copyright © 2016 Curt Hill
Reviews
and
the
Bus
Factor
• One of the pleasant side-effects of
code reviews is collective code
ownership
– Developers now have the opportunity
to see and understand a piece of code
– Very handy if they someday have to
maintain it
• This also gives Bill the opportunity to
share his knowledge with others
– Have the senior developers mentor the
junior ones
Copyright © 2016 Curt Hill
Collective Code Ownership
• Prevents Bill’s vacation from
blowing deadlines
• Makes it easier to bring the new
members up to speed
• Makes it easier to move tasks from
the senior to junior developers
Copyright © 2016 Curt Hill
Habits
• Egoless programming tends to
remove bad habits and promote
good habits
• When everyone sees the result of
the bad habit, it motivates one to
improve
– In a way that the QA team cannot
Copyright © 2016 Curt Hill
Finally
• Code reviews are a mechanism to
reduce errors
• There is opposition to its use, but
the advantages are clear
• The earlier a bug is found the
cheaper the fix
• We should try one
Copyright © 2016 Curt Hill