Matt Quail, Atlassian Patrick Coleman, Dash Navigation

Peer Code Review: In a Nutshell

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

Patrick Coleman

Fisheye & Crucible At Dash Navigation

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