A look at current code review best practices and some proposed ways to improve the overall process at your client site.

1. ……………
“This Ain’t Your Granddaddy’s Code Review…”
Building Better Code Reviews

2. ……………
» What is Code Review and Why Do I Care?
» Why Is Our Traditional Process Broken?
» How Do We Make Code Review Better?

3. ……………
» Cost of Fixing Defects

4. ……………
• Common Mistakes
• Coding Style /
Standards
• ???
• UI functionality
• Application
Behavior (high-
level)
• User Experience
• Tests the modular
function
• Individual Pieces
• Can be automated
Unit
Testing
QA /
UAT
Static Code
Analysis
(e.g. SONAR)
Code
Reviews
Tools for Finding Defects

5. ……………
Code
Review
Logic / Runtime Errors
Learning Opportunities
/ Redesign
“Tribal Knowledge”
Stupid Mistakes
String zero = "" + 0;
We’re going to
keep you up at
night and waste
your weekends!!!

6. ……………
Source: Best Kept Secrets In Code Review
Code Review At CISCO Systems

7. ……………
» Types of Code Review
• Informal
• Over-the-Shoulder
• Email Pass-around
• Pair Programming
• Formal
• Formal Inspection
• Tool Assisted

8. ……………
Plan a Review
• Determine
files to
review
• Book
meeting
room, project
or, send
invites
Review Meeting
• Reviewers
inspect files
• Identify
defects
• Log issues
Fix Defects
• Author
reviews
defects
• Makes
changes as
needed
Repeat Weekly

9. ……………
» How Much?
• 200 – 400 lines of code per session
» How Fast?
• 300 – 500 LoC / hour
» How Long?
• 60-90 minutes
function expireUserSession(){
var userResponse = window.confirm("You will be
logged out unless you click OK");
if(userResponse === true){
setTimeout('expireUserSession', 30*60*1000);
} else {
window.location = 'logout.action';
}
}
dojo.addOnLoad(function(){
setTimeout('expireUserSession', 30*60*1000);
});
OMG, Super Wrong*!!!
Slow Down…72 seconds
* Superwrong is a technical term. This will not work at all!

10. ……………
» Foster a good code review culture
• Finding defects is a good thing!
• Learning opportunity for developers
• Managers must understand metrics
» Use Anti-pattern Checklists
• Code Review Bingo
• Example: Avoid “Tableception”!
Your HTML Page
Best Practice:
Avoid “Tableception” (Tables
within Tables)

11. ……………
How Can We Do This Better???

12. ……………
» Time Commitment
• 60 - 90 minutes?
• Different Schedules
• Remote Workers
» Accountability / Enforcement
• Ensuring that defects get fixed
» Reporting
• Can we ship this feature to production?
» Automation
• Every step is manual, requires a lot of effort

13. ……………
» Time Commitment
• Asynchronous reviews
» Accountability
• Associate Features with Reviews
» Reporting
• Transparency to Managers
• Out of the box functionality from Collaborator!
» Automation
• Remove manual steps, make the CI Server work for us!

14. ……………
Hurray!
Ugh!
*
* This is harder if you’re using ClearCase, but other VCS this should be easy

15. ……………
Demo Time

16. ……………
From the Web UI
What do I need to Review?

17. ……………
From Email

18. ……………

19. ……………

20. ……………

21. ……………

22. ……………

23. ……………
» Reviews Automatically Created
» Clear Action Items for Developers
» Notification System
» Fast Comparison Tool
• Support for your favorite external tool too!
» Real-time Chats / Comments
» Easy to Identify “Reworked” Files
» Generate Reports

24. ……………
» Collaborator Costs
• $499 / named license
» No support for IntelliJ
» Alternatives
• Crucible
• Good price
• No support for rework
• No Automation Support / Metrics
• Review Board
• Great options for cloud hosting!
• Only supports pre-commit model
• Setup a bit of a pain

25. ……………
Questions?

26. ……………
Material That Didn’t Make it Into The
Presentation

27. ……………
» Post-Commit Model
• Reviews Created After Check-in to VCS
• Advantages
• Can Utilize CI Server for Automation
• Easier to Adopt
• Disadvantages
• No way to ensure all code is reviewed before production

28. ……………
» Pre-Commit Model
• Only check in code after completing a review
• Advantages
• Code doesn’t “pollute” VCS
• Enforcement
• Disadvantages
• Against best practice: “Commit Early and Often”
• Requires manual work from developers to create reviews

29. ……………
» GIT: Post-Commit, Pre-Push Model
• Use local branch to commit, but review must be completed
before push to “gold repository”

30. ……………
» Identify and Fix Bugs Earlier
• Difficult to diagnose issues
» Mentoring / Career Development
» Knowledge Transfer
» More Maintainable Code
» Shorter Development / Test Cycles

31. ……………
» Team Size: 3 – 6 people
» Roles
• Author: Wrote the code
• Reviewer: Developers, appraise the code
• Moderator: Facilitates discussion, settles ties. Usually the lead
developer
• Observer: BA or other non-technical, provides SME
• “Reader”: Looks at code purely for readability