avi etzioni on code review @outbrain
DESCRIPTION
Avi Etzioni talks about the importance of code-review when writing quality code. This tech-talk was given at Outbrain Israel - 31/10/2013. You're also welcome to visit my blog: http://avietzioni.blogspot.co.il/ This is the slides for the presentation on Youtube: http://youtu.be/NeV1tP1IfoMTRANSCRIPT
{
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?