four myths about peer code reviews - 7. ebay tech talk
DESCRIPTION
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.pdfTRANSCRIPT
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