Development is inherently collaborative. So why aren't you doing code review? This session discusses the importance of collaboration around your source code, the impact code review can have on development teams, and offers guidance on how to get started. Atlassian Speaker: Matt Quail Customer Speaker: Patrick Coleman of Dash Key Takeaways: * Peer code review explained * Benefits and approaches to effective code review

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

2. 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

3. Introduction

4. Fisheye & Crucible
At Dash Navigation
Patrick Coleman

5. 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)

6. 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

7. 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)

8. 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

9. 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

10. 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

11. Review Example

12. 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

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

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