Code review
Code review
informal formal
ad h
oc r
evie
w
pair
prog
ram
min
g
wal
k th
roug
h
insp
ectio
n/re
view
Characteristic Walkthrough Review
Leader author moderator
Granularity at author’s discretion small chunks
Recorder maybe yes
Documented procedure
maybe yes
Specific participant roles
no yes
Defect checklist no yes
Data analyzed no yes
Appraisal made no yes
Effectiveness
• Studies:– formal review found 16-20 defects per KLOC
vs. 3 per KLOG for walkthrough– formal review found 50% defects than
walkthrough
Preparation
prepare work products
examine workproducts
prepare reviewpackage
ready forreview?
read package
study workproducts
prepare comments
schedule reviewsend out packages
Author Moderator Reviewers
YN
Work products
• Materials to be reviewed– use cases– class and sequence diagrams– code– test results– complexity risk analysis
• A proposed structure for the review– table of contents of work products– what will be reviewed and the order– what types of issues will be covered
roadmap to code
Preparation
prepare work products
examine workproducts
prepare reviewpackage
ready forreview?
read package
study workproducts
prepare comments
schedule reviewsend out packages
Author Moderator Reviewers
YN
Preparation
prepare work products
examine workproducts
prepare reviewpackage
ready forreview?
read package
study workproducts
prepare comments
schedule reviewsend out packages
Author Moderator Reviewers
YN
Review package
• Intro
• Agenda
• Criteria
Review package - Intro
• Background– What project are we discussing– What do reviewers need to know about it
• history, key problems, important decisions, etc.
– Where can reviewers find more info• requirements, designs, analysis
• Goals for review– specific work products to be reviewed– scope (what is in/out of bounds)– what approval means
Review package - agenda
The order materials will be reviewed.
Review - criteria
These need to be determined by the author and moderator depending on the situation. For a code review you might consider:
• Does the UML realize the use cases?• Does the code realize the UML?• Does the code reflect good and consistent style?• Is the code easy to understand? Is it simple but not
“clever”? Is it documented as needed?• Is the code efficient?• Is error handling adequate?• Are the underlying algorithm correct and correctly
implemented?• Do common errors occur? missing cases, off-by-one, etc.
Style
• Code appearance: indentation, alignment, whitespace, tabs
• Naming: appropriate choice of names
• Consistency: same style throughout
Preparation
prepare work products
examine workproducts
prepare reviewpackage
ready forreview?
read package
study workproducts
prepare comments
schedule reviewsend out packages
Author Moderator Reviewers
YN
Reviewer responsibility
• Each reviewer should have specific responsibility
• Review materials relevant to those responsibility
• Test executable
Review process
• Moderator– keeps review moving– ensures all voices are heard and key points covered– ensures decisions are made: accepted, major/minor
revisions, further review
• Recorder– takes notes, records all issues raised and decisions
reached, all questions, suggestions, and action items– publishes a report of the review
Review process cont.
• Reviewers– Each member leads on their portion of the
code– When not leading, follow along, raise
questions, concerns, point out problems
• Author– Answers questions but is otherwise silent
Review cont.
• Stick to specified level
• Avoid re-specifying/designing system
• Avoid getting sidetracked
Top Related