7. ebay Tech Talk Berlin 

Demystifying Code Reviews with Gerrit

Mateusz Szczap
Holger Hammel
•  Part of the ebay family
•  located ebay Campus Dreilinden
•  Germany’s biggest online marketplace for vehicles
•  7.44 ...
why this presentation?
some ideas for starting and proceeding with
code reviews easier
Ok nice, but why reviewing at all?
Get feedback for better code
“I believe that peer code reviews are the
single biggest t...
What type of reviews you use?

Pair Programming (by peer, instantly)
Peer Code Review (by peer, async)
Code Walkthroughs (...
Myth 1: come on, reviews are too
expensive and slow!
less errors -> more productivity
no debugging, retesting, finding the ...
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 ...
Myth 3: reviews are blocking
You may not want another column on your
board and wait for someone to review

Reviews make se...
Myth 4: tools are horrible
yeah, not always a myth

make it as simple, convenient and fast as
possible to create and finish...
Sources
•  [smc] Steve McConnell: Code Complete, Second Edition; Microsoft
Press; 2004; chapters: 20.3. Relative Effective...
Upcoming SlideShare
Loading in …5
×

Four myths about peer code reviews - 7. ebay tech talk

1,657 views

Published on

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

  • Be the first to comment

Four myths about peer code reviews - 7. ebay tech talk

  1. 1. 7. ebay Tech Talk Berlin Demystifying Code Reviews with Gerrit Mateusz Szczap Holger Hammel
  2. 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. 3. why this presentation? some ideas for starting and proceeding with code reviews easier
  4. 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. 5. What type of reviews you use? Pair Programming (by peer, instantly) Peer Code Review (by peer, async) Code Walkthroughs (by group, async)
  6. 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. 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. 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. 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. 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

×