1

Establishing Code Review Processes for your Team Phil Denoncourt IIILead ConsultantPJ Denoncourt & Associates, LLC

Track: Enterprise Architecture

2

Wireless Access

1. Connect to the “Cambridge” network

2. Open a Browser

3. In Logon page use the code:

af609

“Software testing alone has limited effectiveness -- the average defect detection rate is only 25 percent for unit testing, 35 percent for function testing, and 45 percent for integration testing. In contrast, the average effectiveness of design and code inspections are 55 and 60 percent. Case studies of review results have been impressive:In a software-maintenance organization, 55 percent of one-line maintenance changes were in error before code reviews were introduced. After reviews were introduced, only 2 percent of the changes were in error. When all changes were considered, 95 percent were correct the first time after reviews were introduced. Before reviews were introduced, under 20 percent were correct the first time.

In a group of 11 programs developed by the same group of people, the first 5 were developed without reviews. The remaining 6 were developed with reviews. After all the programs were released to production, the first 5 had an average of 4.5 errors per 100 lines of code. The 6 that had been inspected had an average of only 0.82 errors per 100. Reviews cut the errors by over 80 percent.

The Aetna Insurance Company found 82 percent of the errors in a program by using inspections and was able to decrease its development resources by 20 percent.

IBM's 500,000 line Orbit project used 11 levels of inspections. It was delivered early and had only about 1 percent of the errors that would normally be expected.

A study of an organization at AT&T with more than 200 people reported a 14 percent increase in productivity and a 90 percent decrease in defects after the organization introduced reviews.

Jet Propulsion Laboratories estimates that it saves about $25,000 per inspection by finding and fixing defects at an early stage.”

Steve McConnell, Code Complete

Code Reviews

• Bugs should be spotted earlier

• Bugs are cheaper to fixFewer Defects

• More eyes on sustainable factoring

• Proves the code is understandable

More Maintainabl

e

Benefits - Quality

Junior

•Learn practiced techniques from experienced developers

Senior

•Gather more breadth of system architecture

Architect

•Opportunity to promote principles

•Gives you more visibility to suspect areas of code.Benefits - Coaching

•Understand code, not developer is being reviewed

Collaborative Group

•Done independently or in group?

•How do you to notate results?

•How to you verify corrections were made?

Process

•Set expectations by having coding standards documented

•Code Review Checklist

Standards

Prequisites

Code is written

Compiles

Static Code Analysis

Automated Tests Succeed

Developer reviews code

Code Review

Corrections are made

Code is committed to

central repository

When to do reviews

•Promotes better learning

•People likely to come unprepared

Code Review Meeting

•Not interrupting developer’s schedules

•Easy to defer

Offline / Async

•Suggestions are emailed to a moderator before the review

•Moderator goes through the list

High Impact

Inspection

Methodology

•More bugs were not found in groups larger than 5

Small Group

•Keep review to 200-400 lines of code

Small Review Scope

•After 60 minutes, fewer bugs were found

Timeboxed effort

Suggestions

•Shouldn’t be forced to have code reviewed that isn’t ready.

Developer submits

code

•Managers don’t have much to contribute.

•Encourages unnecessary defensiveness

Non Technical Attendees

•Encourages a through review

•Sets expectations for developers

Checklists

Suggestions

•Need to encourage egoless reviews

•Continue to reinforce that code is being reviewed

Tone•Encoura

ge atmosphere of proposing solutions. Not just pointing out problems.

Fix it

•Make sure non-traditional assets are reviewed•Databa

se Schemas

•Supporting Documentation

•Installers

Broad

Suggestions

•Consider having one person responsible for a single area•Security•Memory Usage

•Performance

Subject Matter Experts

•If bug was not found in code review, determine root cause

Feedback

•Code Reviews are generally not the place to design the solution.

•Keep changes focused on code.

Revision

Suggestions

•Code is re-reviewed until it passes

•If it continues to need work, address the underlying issue

Repeat

•Best if testing staff can read code

•A way of communicating how system is put together.

Involve Testing Staff

•Best to have a system that integrates with build system

Automate

Suggestions

Immediate code reviews• Albeit reviewing isn’t the focus

Reviews tend to be non-objective

Metrics are hard to gather

Pair Programming

ThreadingStatic variables are protectedAppropriate objects are

threadsafeLocks are released in the correct

orderCritical Resources

Handles are freed at the earliest point

Handles are validated before usage

InstrumentationCode logs important eventsLogging is not excessive

SecurityAuthorization checks are doneFunction Parameters are

validated

Convention Adequately Documented Appropriate Headers

Error Handling Assumptions in functions are asserted Exceptions are documented Resources are properly freed in

exception situations It is possible for the exception to

occur

Loops It will always be finite Ending conditions are accurate

Tests Coverage is sufficient Purpose of test is understandable

Review Checklist

•Issues found per review

•Expect a spike initially•As

your team gets better at finding defects

•Expect this to go downward

Code Review Failure Rate

•Number of big issues found in QA

•Expect this to go down rapidly

Severe QA Bugs

•Number of lines committed as a result of code review

•Expect this to be high initially, and have a downwards trend.

Number of lines

changed per review

Measuring

•Best if integrates with defect system

•As well as SCC

Integrate

•Tracks concerns in code

•Resolution of the concerns

Features

•Wide variety of vendors

•Open Source

Research

Software

•Team won’t learn from each other

Minimal Learning

•You won’t be present, so you don’t have insight

•Seed code with known issues to measure

Questionable Detail

•Won’t be taking up team’s time

•Project headcount is minimized

Lower Commitmen

t

Outsourcing

•Takes time to review existing code

•Costs ½ person day to review 300 lines

Commitment

•Big shift from committing any code, to only reviewed code

•Some devs are sensitive to feedback

Culture

•Many developers have had bad experiences

•Some research suggests reviews aren’t worthwhile

Reputation

Struggles

Code Reviews improve quality

Code Reviews improve team

Reviews require planning and resources

Wrapping up

Q & A

22

Thank You Sponsors !

{CodeRight}

Help make a better event - Complete a Survey!

http://ArchitectFactory.com/Survey.aspx