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