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

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

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 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]

What type of reviews you use?

Pair Programming (by peer, instantly) Peer Code Review (by peer, async) Code Walkthroughs (by group, async)

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    

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

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

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

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