Peer Code Review:
In a Nutshell
Matt Quail, Atlassian
Patrick Coleman, Dash Navigation

Agenda
Introduction (Matt)
o Code Review, Crucible and Atlassian
Code Review at Dash (Patrick)
o Introduction of Crucible to SW Engineering
o Addition of Fisheye for Code Reviews
Q&A

Introduction

Fisheye & Crucible
At Dash Navigation
Patrick Coleman

Tools Used By Dash Prior to Adding
Crucible
Source Control – Perforce
Issue Tracking – JIRA
Wiki – Confluence
Repository Viewer – Fisheye
Continuous Build – Pulse
Static Code Analysis – Coverity
Code Coverage - Clover
Code Review – Manual (i.e. no SW Tool)

Objectives for Adding Crucible to
Dash
Increase Code Quality
o Catch Defects in the source versus QA filing
bugs
o Facilitate non-defect code improvements by
engaging more than one SW Engineer on a
piece of SW
Minimize Impact to SW Engineers
o Reviews take place when Engineers want
o Remote Engineers are not penalized

Step 1 – Crucible Evaluation
Installed a 30 day evaluation of Crucible
Recruited a handful of Senior Engineers to
use Crucible
Performed real reviews on current projects
Discussed with trial users what they liked/
disliked
o From this feedback we identified points of
confusion that needed documentation on our Wiki
o Found task of creating a pre-commit review to be
too time consuming (i.e. engineers wouldn’t do it)

Step 2 – Prepare for Team Wide
Rollout
Created Wiki Page with basic
instructions on how to create and
participate in a Crucible Review
Created a script to simplify the task of
creating a diff file for pre-commit reviews

Step 3 – Crucible Rollout
Announced to Entire SW Team the Addition of
Crucible
Intentionally did not have SW Managers
create reviews
Senior Engineers who participated in
evaluation created reviews against their own
submissions (this was not planned it just
occurred organically)
Most of the time an engineer was introduced
to Crucible as a reviewer rather than having
their own code reviewed

Crucible – 12+ Months Later
Crucible is broadly viewed as an effective way
to review both code changes and new code
Majority of reviews are created by the author
Release Managers selectively create reviews
for changes made near to release points
Marking reviews as complete has never fully
taken hold but does not appear to detract from
the value of conducting reviews in Crucible

Review Example

Fisheye - Continuous Code Review
via Email Notifications
Hyperlink to Changelist in Fisheye
Hyperlink to Issue in JIRA
Submission Comment
Magnitude of Change
Hyperlink to File by File Diffs
Superior to SCM Notifications for above reasons

Fisheye - Release Management Code
Review
Use Fisheye to approve each code
submission into weekly QA Build

Fisheye – Build to Build Reviews
Use Fisheye to bracket changes from build to
build
Identify likely sources of defects by inspecting
code changes