avi etzioni on code review @outbrain

{

Code Quality: Code Review

By Avi Etzioni; }Available on Youtube: http://youtu.be/NeV1tP1IfoM

Code Quality = #WTF/Min

Review – not only for code

Students

Politicians

Books

If only someone reviewed…

Agenda Part 1 – Code Review – Who needs

it? Feedback Some numbers Why should I seek this feedback? Why should I review others work? Ok, but…

Part 2 – Guidelines for creating and reviewing

Part 1

Code Review – Who needs it?

Design

IDE

Automatic Tests

Build/Integration

Monitor

Take in

Au

toFeed

back

Feedback is all around us

Symptom

Problem

Some numbers…

Type of defects found in review

Functional

Non-functional / Maintainability

issues

False positive

Distribution of defects

71%

21%

7%

MaintainabilityFunctionalFalse positive

Maintainability Distribution

35%

55%

10%

DocumentationStructureVisual Represen-tation

Defect Reduction

• Pair Programming: 15%-50%• Unit-Tests: 30%-60%:• Increase in development time: 20%-30%• Does not take into consideration bugs found during the writing of the tests

• Code review meeting: 45%-50%• Asynchronous code-review: 60-65%

Why should I seek this feedback?

• Enforces better code inspection• Unbiased set of eyes• Find your problems sooner than later• Learn new stuff• Teach the others

Why should I give this feedback?

• Improve code reading skills• Learn new stuff• Better understanding of the code• Common goal• Let your voice be heard

What about the organization?

• More capable employees

• Knowledge sharing

• Training for new team

members

• Better quality of the

product

• DISCUSSION

Ok, but…

Ok, but… It takes too much time

• What about Design? Graphitus? Take in?• Unit-tests• Who checks them?

• It’s better to favor small reviews• Maintainability issues can make

adding new functionality 28% slower and fixing errors 36% slower *

*Bandi, Vaishnavi, Turk: Predicting Maintenance Performance Using OO Design Complexity metrics

Ok, but… I’m not familiar with the code

Ok, but… I’m not familiar with the code

Ok, but… It’s too subjective

• That’s true, but…• Research shows 82% agreement• Add more reviewers• You don’t have to agree (just be nice about it)

Ok, but… It’s a minor-change

Ok, but… I’m a Rockstar

71%

21%

7%

MaintainabilityFunctionalFalse positive

Remember This??

Part 2

General Guide Lines

Favor small reviews

• Reviewing a lot of code is a lot to process

• Might intimidate people from starting the review

• Those who start, will probably not finish

• Think of logical ways to split the reviews

Explain yourself

• What have you done?• High-level explanation• Detailed explanation about non-trivial

changes• Testing Done:• mvn [install ; test ; test –P integration]?• Started the service?• Ran APT?• Simulated tests?

• Next Steps

Tie your ego to quality… Not to your code

• Comply with standards

… But remember that style is a matter

of taste

• Don’t criticize - advise

• Choose your battles

• Be polite:

• Maybe I don’t understand everything,

but…

• I would prefer...

• Nitpicking: …

And if you have nothing to say…

• Ship it!

• A good word never hurt anyone

What to look for???

Start with searching for the obvious and easy wins

• Typos

• Commented code

• Wrong/missing description

• Trivial exceptions – NPE, OutOfBounds…

• Coding conventions

And continue with the not so obvious

• Similar (but not exactly duplicated) code

• Project structure

• Affected components / Tests that might

break

• Hidden pitfalls / Bugs

• Security

• ADVANCED LEVEL: patch the code and run

it!

How to start?

Thank you!

aetzioni@outbrain.com

Twitter: @AviEtzioni