“.. software testing alone has limited effectiveness -- the average defect detection rate is only 25 percent for unit

testing, 35 percent for function testing, and 45 percent for integration testing. In contrast, the average effectiveness of

design and code inspections are 55 and 60 percent. “

Code Complete Steve McConnell

Benefits

Finding bugs early – cheap to fix

Coding standards compliance

Consistent coding style across the company

Teaching and sharing knowledge

Consistent design and implementation

Higher software security

Team cohesion

Types of Code Review

Formal inspections

Over-the-shoulder reviews

E-mail pass-around reviews

Tool-Assisted reviews

Pair-Programming

4

http://www.ccs.neu.edu/home/lieber/courses/cs4500/f07/lectures/code-review-types.pdf

Code Review Types: Formal inspections •  Formal inspections

•  “formal” review refers to a heavy-process review with three to six participants meeting together in one room with print-outs and/or a projector.

5

Planning

•  Verify materials meet entry criteria.

•  Schedule introductory meeting

Introductory Meeting

•  Code is presented by author

Inspection Meeting

•  Code is reviewed

•  Defect logged

Rework

•  Author fixes defects

Verification Meeting

•  Verify defect fixed

Complete

Code Review Types: Formal inspections

Pros •  a lot of defects can

be identified

Cons •  Needs preparation •  Time consuming •  No time to dig in

and be thorough •  Difficult to get the

right people

Code Review Types: Over-the-shoulder reviews • Over-the-shoulder reviews

•  a developer standing over the author’s workstation while the author walks the reviewer through a set of code changes.

•  With modern desktop-sharing software a so-called “over-the- shoulder” review can be made to work over long distances

7

Preparation

• Developer finds available reviewer in person or through shared-desktop meeting.

Inspection Meeting

• Developer walks reviewer through the code.

• Reviewer interrupts with questions.

• Developer writes down defects

Rework

• Developer fixes defects

Complete

• When developer deems himself finished, he checks code into version control

Code Review Types: Over-the-shoulder reviews

Pros

•  simplicity in execution Cons • you need schedule these sharing meetings

• this is not an enforceable process – there’s nothing that lets a manager know whether all code changes are being reviewed

• there are no metrics, reports, or tools that measure anything at all about the process

• it’s easy for the author to unintentionally miss a change

• Defects fixes are not verified • The author is controlling the pace of the review, defects can be missed

8

Code Review Types: E-mail pass-around reviews 1.  whole files or changes are packaged up by the author

and sent to reviewers via e-mail 2.  The version control system can also assist by sending

the e- mails out automatically

9

Code Check-In

•  Developer checks code into SCM.

•  SCM server sends emails to reviewers based on authors (group leads) and files (file owners)

Inspections

•  Recipients examine code diffs on their own recognizance.

•  Debate until resolved or ignored

Rework

•  Developer responds to defects by making changes and checking the code in.

•  Nothing special to do because code is already checked into version control.

Complete

•  Nothing special to do because code is already checked into version control

•  Don’t really know when in this phase because there’s no physical “review” that can complete.

Code Review Types: E-mail pass-around reviews

Pros •  easy to implement •  Good for cross-location teams •  the ease in which other people can

be brought into the review •  they don’t knock reviewers out of

“the zone”

Cons • finding and collecting the files under review

• the author has to figure out how to gather the files together

• reviewers have to extract those files from the e-mail and generate differences between each

• it can rapidly become difficult to track the various threads of conversation and code changes

• Review takes more time • Lack of process: it’s not clear whether anybody is reviewing the code

10

Code Review Types: Pair-Programming

•  a development process that incorporates continuous code review.

11

Pros •  this gives the reviewer lots

of inspection time and a deep insight into the problem at hand, so perhaps this means the review is more effective

Cons •  this closeness is exactly

what you don’t want in a reviewer; just as no author can see all typos in his own writing, a reviewer too close to the code cannot step back and critique it from a fresh and unbiased position

•  it takes too much time

Code Review Types: Tool-Assisted reviews • Automated File

Gathering • Combined Display:

Differences, Comments, Defects

• Automated Metrics Collection

• Review Enforcement • Clients and

Integrations (integration with IDE, vision control, admin web clients)

12

Pros • Easy to organize • Transparent process • Configurable workflows • No meetings to be set u:

reviewers can review the code at any time

• Works for cross-location teams

Cons • Usually these tools are not

free

Tools Criteria Crucible by Atlassian

Gerrit Collaborator by SmartBear

Review Board

Configurable Workflow

pre- and post-commit

Pre-commit

Pre-commit Post-commit

Pre-commit Post-commit

Integration with Jira + (ootb) JIRA provides plugin

- -

IDE plugins IDE Connector (ootb, free) for

Eclipse and IntelliJ

Eclipse plugin, IntelliJ

Eclipse plugin -

supports GIT / Stash

git/stash (ootb) git git git

supports Java, CSS, Javascript, XML, property files

+ + + +

Email notifications + + + +

Reporting + - + -

Hosting In house / cloud In house In house In house

License cost Apache v2 Proprietary Proprietary MIT

13

Recommended Tool

14

Crucible & Fisheye Flexible

code reviews

pre-commit or post-commit code

reviews

Workflow-based reviews

One-click reviews from changesets or

issues

Threaded comments

inline discussions

Turn any review into a threaded

discussion

JIRA integration and more

View source code associated with code reviews.

View and create code reviews from

JIRA.

Turn Crucible code review comments

into actionable JIRA issues

Distributed teams

Instant feedback on review activity via email and RSS

Audit trail of all review activity

Activity streams including source code and code

reviews

15

Customer List

Review Process

Create Review

• Author creates review (can be pre-commit or post-commit)

• Author invites reviewers

Inspections

• Reviewers comment on the code

Rework

• Author responds to the comments

• Update the implementation is required

Verification

• Reviewers verify changes and complete their reviews

Complete

• Author summarizes and closes the review

Crucible Price (server host)

https://www.atlassian.com/software/crucible/pricing

Next Steps

Assign Moderators

Create checklist for authors and reviewers

Define standards

Define workflow

Installation and Configuration

Purchase License

Thank you!

Resources •  Five Types of Review

http://www.ccs.neu.edu/home/lieber/courses/cs4500/f07/lectures/code-review-types.pdf

•  Cricible https://www.atlassian.com/software/crucible/overview •  Collaborator - http://smartbear.com/product/collaborator/overview/ •  Wikipedia: https://en.wikipedia.org/wiki/List_of_tools_for_code_review