This is the first part of a presentation at the 7th ebay tech talk in Berlin, 25th July 2013. There are some myths, fears about peer code reviews, that usually keeps people from doing reviews and not all are feasible. The second part was about peer code reviews with gerrit and how to do reviews effectively, author is Mateusz Szczap from mobile.de see: https://dl.dropboxusercontent.com/u/19526512/talks/mateuszszczap-codereview-techtalk-pub.pdf

1. 7. ebay Tech Talk Berlin
Demystifying Code Reviews with Gerrit
Mateusz Szczap
Holger Hammel

2. • Part of the ebay family
• located ebay Campus Dreilinden
• Germany’s biggest online marketplace for vehicles
• 7.44 million unique users (AGOF 2013-04)
• 150 people, 60 within technology
• High traffic web, android and iOS applications
• Agile cross functional teams
Mateusz Szczap
- Software Engineer
Holger Hammel - Team Lead mobile

3. why this presentation?
some ideas for starting and proceeding with
code reviews easier

4. Ok nice, but why reviewing at all?
Get feedback for better code
“I believe that peer code reviews are the
single biggest thing you can do to improve
your code.” [jat]
“Code reviews aren't the ultimate solution
to a broken design process, but they are
an incredibly useful tool.” [mwe]

5. What type of reviews you use?
Pair Programming (by peer, instantly)
Peer Code Review (by peer, async)
Code Walkthroughs (by group, async)

6. Myth 1: come on, reviews are too
expensive and slow!
less errors -> more productivity
no debugging, retesting, finding the right person, building tech debt
up to 95% defect detection w/ XP
(just <60% w/ only automated testing)
Sources:
[smc]
references
various
studies

7. Myth 2: you have to understand the
whole context of what you review
No you haven’t
Mentioning a typo or a SOLID or clean code
violation or a formatting issue or a missing
test or I didn’t find anything or ….. helps

8. Myth 3: reviews are blocking
You may not want another column on your
board and wait for someone to review
Reviews make sense even non-blocking
and after a release
the faster the better, though

9. Myth 4: tools are horrible
yeah, not always a myth
make it as simple, convenient and fast as
possible to create and finish reviews
=> for example with gerrit

10. Sources
• [smc] Steve McConnell: Code Complete, Second Edition; Microsoft
Press; 2004; chapters: 20.3. Relative Effectiveness of Quality
Techniques; 20.5. The General Principle of Software Quality;
http://www.ebay.de/sch/i.html?_nkw=McConnell%2C+Steve%3A
+Code+Complete
• http://scientopia.org/blogs/goodmath/2011/07/06/things-everyone-
should-do-code-review/
• [jat] Jeff Atwood:
http://www.codinghorror.com/blog/2006/01/code-reviews-just-do-
it.html
• [mwe] Matt Welsh:
http://matt-welsh.blogspot.de/2012_02_01_archive.html
• [rbo] Robert Bogue - “Code Reviews w/o the pain”, best practices
http://www.developer.com/tech/article.php/3579756/Effective-
Code-Reviews-Without-the-Pain.htm
• [jco] Jason Cohen, Smartbear: “11 proven practices for more
effective, efficient peer code review”
http://www.ibm.com/developerworks/rational/library/11-proven-
practices-for-peer-review/index.html