Modern Code Review

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

description

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

Transcript of Modern Code Review

Page 1: Modern Code Review

……………

……………

“This Ain’t Your Granddaddy’s Code Review…”

Building Better Code Reviews

Page 2: Modern Code Review

……………

……………

Overview

» What is Code Review and Why Do I Care?

» Why Is Our Traditional Process Broken?

» How Do We Make Code Review Better?

Page 3: Modern Code Review

……………

……………

Why Do I Care?

» Cost of Fixing Defects

Page 4: Modern Code Review

……………

……………

Where Does Code Review Fit In?

• 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

Page 5: Modern Code Review

……………

……………

Why Do I Care?

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!!!

Page 6: Modern Code Review

……………

……………

Case Study

Source: Best Kept Secrets In Code Review

Code Review At CISCO Systems

Page 7: Modern Code Review

……………

……………

What Is Code Review?

» Types of Code Review• Informal

• Over-the-Shoulder• Email Pass-around• Pair Programming

• Formal• Formal Inspection• Tool Assisted

Page 8: Modern Code Review

……………

……………

Formal Inspection

Plan a Review

• Determine files to review

• Book meeting room, projector, send invites

Review Meeting

• Reviewers inspect files

• Identify defects

• Log issues

Fix Defects

• Author reviews defects

• Makes changes as needed

Repeat Weekly

Page 9: Modern Code Review

……………

……………

Best Practices

» 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

* Super wrong is a technical term. This will not work at all!

Page 10: Modern Code Review

……………

……………

Best Practices

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

Page 11: Modern Code Review

……………

……………

How Can We Do This Better???

Page 12: Modern Code Review

……………

……………

Roadblocks to Better Code Review

» 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

Page 13: Modern Code Review

……………

……………

Better Code Review

» 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!

Page 14: Modern Code Review

……………

……………

Better Code Review

Hurray!

Ugh!

*

* This is harder if you’re using ClearCase, but other VCS this should be easy

Page 15: Modern Code Review

……………

……………

Demo Time

Page 16: Modern Code Review

……………

……………

What do Developers See: Action Items

From the Web UI

What do I need to Review?

Page 17: Modern Code Review

……………

……………

What do Developers See: Action Items

From Email

Page 18: Modern Code Review

……………

……………

Reviews

Page 19: Modern Code Review

……………

……………

Reviews

Page 20: Modern Code Review

……………

……………

Page 21: Modern Code Review

……………

……………

Page 22: Modern Code Review

……………

……………

Page 23: Modern Code Review

……………

……………

Recap: Why Is This Better?

» 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

Page 24: Modern Code Review

……………

……………

The Catch

» 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

Page 25: Modern Code Review

……………

……………

Questions?

Page 26: Modern Code Review

……………

……………

Material That Didn’t Make it Into The Presentation

Page 27: Modern Code Review

……………

……………

Pre-Commit vs. Post-Commit

» 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

Page 28: Modern Code Review

……………

……………

Pre-Commit vs. Post-Commit

» 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

Page 29: Modern Code Review

……………

……………

Pre-Commit vs. Post-Commit

» GIT: Post-Commit, Pre-Push Model• Use local branch to commit, but review must be completed

before push to “gold repository”

Page 30: Modern Code Review

……………

……………

Benefits of Code Review

» Identify and Fix Bugs Earlier• Difficult to diagnose issues

» Mentoring / Career Development

» Knowledge Transfer

» More Maintainable Code

» Shorter Development / Test Cycles

Page 31: Modern Code Review

……………

……………

Other Thoughts On Formal Inspection

» 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