Code reviews are often thought of as anti-agile, cumbersome, and disruptive. However, done correctly, they enable agile teams to become more collaborative and effective, and ultimately to produce higher quality software faster. Mark Hammer describes how lightweight code review practices succeed where more cumbersome methods fail. Mark offers tips on the mechanics of lightweight code reviews and compares five common styles of review. He looks at real-world examples and reveals impressive results. Gain new insights into how much time to spend in review, how much code to review in one session, and how author preparation practices can increase the efficiency of a review. Learn how peer code review can improve the performance of individual developers, their teams, and the software they produce. Mark shares the specific benefits of peer code review, including ROI and the ultimate goal of producing higher quality software faster.
<ul><li> 1. W10 Concurrent Class 10/2/2013 1:45:00 PM "Agile Code Reviews for Better SoftwareSooner" Presented by: Mark Hammer SmartBear Software Brought to you by: 340 Corporate Way, Suite 300, Orange Park, FL 32073 888-268-8770 904-278-0524 firstname.lastname@example.org www.sqe.com </li> <li> 2. Mark Hammer SmartBear Software Senior product director at SmartBear Software Mark Hammer speaks and writes about the software development process with a special emphasis on code review. Mark has more than twenty years of experience in software product management, previously at global-education leader Houghton Mifflin Harcourt. He has a strong track record in developing customer-focused business solutions in both business-to-business and business-to-consumer markets. Mark was VP of marketing for CompassLearning, an educational software developer. </li> <li> 3. 9/20/2013 Want Higher Quality Software from Your Agile Team? Peer Review Works Mark Hammer 1 2 1 </li> <li> 4. 9/20/2013 3 Product Mgmt Development QA 4 2 </li> <li> 5. 9/20/2013 Product Mgmt Development QA User stories Code Test Plans 5 Professional Writers Have Editors 6 3 </li> <li> 6. 9/20/2013 7 Industry Metrics 8 4 </li> <li> 7. 9/20/2013 Measure Industry Average High Performance Teams Net Promoter Score 20% > 70% % defects of total injected found by customer 15% < 2% % effort spent in finding and fixing defects 50% < 10% % effort for post-release support 30% < 5% Unit test code coverage Varies > 80% Post release defect density 7.5 defects/KLOC < 0.5 defects/KLOC 9 Measure Industry Average High Performance Teams Net Promoter Score 20% > 70% % defects of total injected found by customer 15% < 2% % effort spent in finding and fixing defects 50% < 10% % effort for post-release support 30% < 5% Unit test code coverage Varies > 80% Post release defect density 7.5 defects/KLOC < 0.5 defects/KLOC Bugs found in development are 8-12X less expensive to fix than those found in QA phase And 30-100X less expensive than bugs that reach customers 10 5 </li> <li> 8. 9/20/2013 The Curious Case of Missing Code Reviews 11 Requirements Discussion Design Review Architecture Review 12 6 </li> <li> 9. 9/20/2013 Requirements Discussion Design Review Architecture Review Code N/A 13 Product Mgmt Development QA Review Requirements Architecture Code Test Plans 14 7 </li> <li> 10. 9/20/2013 If You Need More Convincing Geographically-distributed teams (main vs. offshore teams, apprentice mentor) CMMI code review is mandated FDA code review is mandated Embedded systems very high cost of change PCI code review is mandated Agile teams fast, convenient way to collaborate, provides less time-intensive pair programming opportunity 15 Code Review Options Over-the-Shoulder Email Pair Programming Formal Inspection Meetings?! Tool 16 8 </li> <li> 11. 9/20/2013 Over-the-Shoulder 17 Over-the-Shoulder Easy / Free Interruption No Info Recorded 18 9 </li> <li> 12. 9/20/2013 Email 19 Email Easy / Free No Interruption / Remote Conversation Tracking Info. Hard to Retrieve No End? 20 10 </li> <li> 13. 9/20/2013 Pair Programming 21 Pair Programming No Tools or Workflow Deep Thought Big Time Commitment No Info. Recorded Too Close 22 11 </li> <li> 14. 9/20/2013 Why Dont More Teams Do It? Its hard to do, with no clear perceived benefits Expensive, tedious and time consuming to do it manually Difficult to track threads of communication Code review isnt integrated with source code management (SCM) tool Hard to collaborate with remote members 23 Hapless Developer Reviewers Version Control 24 12 </li> <li> 15. 9/20/2013 Largest Peer Code Review Study Ever Objectives: lightweight vs. formal inspections What constitutes an effective review? 10-month case study at Cisco Cisco MeetingPlace product, teleconferencing solution 3.2 million lines of code 2500 reviews 50 developers 25 Recommendations (Best Practices) LOC under review < 200, Not to exceed 400 Inspection rate < 300 LOC/hour Author preparation with annotations - Self review checklist Total review time < 60 min. Not to exceed 90 26 13 </li> <li> 16. 9/20/2013 Product Mgmt User stories QA Code Test Plans 27 Product Mgmt Development QA Review Requirements Architecture Code Test Plans 28 14 </li> <li> 17. 9/20/2013 Case Study 2011: 70 floating licenses: ~350 developers 2013: 130 floating licenses: ~650 team members User stories are shared in Word format with entire team Design documents are shared in Powerpoint with entire team Code is shared with entire team Test cases are shared in Excel format with entire team 29 Benefits of Cross-Functional Peer Review Every member of the extended development team knows whats happening Problems with user stories, code, and test plans are found faster It forces developers to write readable code (code that can be read without explanation!) Optimization methods/tricks/productive programs spread faster Programmer as a specialist "evolve" faster Teams can iterate from story to code to test plan It's fun 30 15 </li> <li> 18. 9/20/2013 The simple fact of knowing your work will be reviewed by others means youll do it better. 31 16 </li> </ul>