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/NeV1tP1IfoM

1. Code Quality:
Code Review
{ By Avi Etzioni; }
Available on Youtube: http://youtu.be/NeV1tP1IfoM

2. Code Quality = #WTF/Min

3. Review – not only for code
Students
Politicians
Books

4. If only someone reviewed…

5. 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

6. Part 1
Code Review – Who needs it?

8. Feedback is all around us
Design
Problem
IDE
Automatic
Tests
Build/Integrati
on
Symptom
Monitor
Take in

9. Some numbers…

10. Type of defects found in review

Functional

Non-functional / Maintainability issues

False positive

11. Distribution of defects
7%
21%
Maintainability
Functional
71%
False positive

12. Maintainability Distribution
10%
Documentation
35%
Structure
55%
Visual
Representation

13. 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%

14. 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

15. 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

16. What about the organization
• More capable employees
• Knowledge sharing
• Training for new team members
• Better quality of the product
• DISCUSSION

17. Ok, but…

18. 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

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

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

21. 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)

22. Ok, but… It’s a minor-change

23. Ok, but… I’m a Rockstar
7%
21%
Maintainability
Functional
71%
False positive
Remember This??

24. Part 2
General Guide Lines

25. 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

26. 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

27. 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: …

28. And if you have nothing to say…
• Ship it!
• A good word never hurt anyone 

29. What to look for???

30. Start with searching for the obvious and easy wins
• Typos
• Commented code
• Wrong/missing description
• Trivial exceptions – NPE, OutOfBounds…
• Coding conventions

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

32. How to start?

33. Thank you!
aetzioni@outbrain.com
Twitter: @AviEtzioni