Code Reviews: The #1 Way to Improve Code Quality

Transcript

1. CODE REVIEWS Craig Berntson The #1 Way to Improve Code Quality
2. EGO STUFF AUTHOR Continuous Integration in .NET Manning Publishing MICROSOFT MVP 20+ years, currently for Developer Tools .NET ARCHITECT TECHNICAL SPEAKER 20+ years as international speaker AUTHOR Software Gardening column DNC Magazine COMMUNITY INFLUENCER Grape City
3. TODAY’S AGENDA  What is a code review  Impact of a code review  Types of code reviews  The Reviewer  The Reviewee
4. WHAT IS A CODE REVIEW
5. Recent work by Tom Gilb, one of the more prominent authors dealing with software inspections, and his colleagues continues to support earlier findings that a human being inspecting code is the most effective way to find and eliminate complex problems that originate in requirements, design, and other noncode deliverables. Indeed, to identify deeper problems in source code, formal code inspection outranks testing in terms of defect-removal efficiency levels. - "Do You Inspect?“ - Capers Jones and Olivier Bonsignour 2011
7. Code review is systematic examination (sometimes referred to as peer review) of computer source code. It is intended to find mistakes overlooked in the initial development phase, improving the overall quality of software. Reviews are done in various forms such as pair programming, informal walkthroughs, and formal inspections. DEFINITION - Wikipedia
8. Code review is systematic examination (sometimes referred to as peer review) of computer source code. It is intended to find mistakes overlooked in the initial development phase, improving the overall quality of software. Reviews are done in various forms such as pair programming, informal walkthroughs, and formal inspections. DEFINITION - Wikipedia
9. Code review is systematic examination (sometimes referred to as peer review) of computer source code. It is intended to find mistakes overlooked in the initial development phase, improving the overall quality of software. Reviews are done in various forms such as pair programming, informal walkthroughs, and formal inspections. DEFINITION - Wikipedia
10. WHAT IS A CODE REVIEW  Determine what is being done well and what can be done better  It is not a witch hunt  Sharing findings makes all developers involved better  No one size fits all - Shawn Wildermuth: Pluralsight
11. TYPES OF CODE REVIEWS FORMAL • Reviewers get code and read it before review meeting • All parties meet to go through code INFORMAL • Reviewers get code and email comments to author AUTOMATED • Software flags suspect code that doesn’t follow guidelines • Human reviewers enter additional comments PULL REQUEST • Reviewers look at code changes before merge
12. IMPACT OF A CODE REVIEW
13. Isn’t finding bugs the purpose of QA and testing?
14. … software testing alone has limited effectiveness – the average defect detection rate is only 25 percent for unit testing, 35 percent for function testing, and 45 percent for integration testing. In contrast, the average effectiveness of design and code inspections are 55 and 60 percent. programming, informal walkthroughs, and formal inspections. - Code Complete
15. WHAT DO YOU FEEL IS THE NUMBER ONE THING A COMPANY CAN DO TO IMPROVE CODE QUALITY Code Review 34% Unit Testing 24% Integration Testing 17% Function Testing 12% Other 13% SmartBear
16. WHAT DO YOU THINK ARE THE MOST IMPORTANT BENEFITS OF CODE REVIEW? 84 62 61 56 48 27 26 23 21 16 0 10 20 30 40 50 60 70 80 90 Improved Quality Ability to Mentor Enhanced Maintainability Adhere to Coding Standards Increased Collaboration Reduce Time & Costs Compliance with Regulations Customer Satisfaction Set Expectations Competitive Advantage SmartBear
17. IMPACT OF POOR CODE QUALITY -3.75% =-$2.3 Billion! Parasoft
18. HOURS TO FIX A BUG Stage Introduced Requirements Coding/Unit Testing Integration Beta Testing Production Requirements 1.2 8.8 14.8 15.0 18.7 Coding/Unit Testing NA 3.2 9.7 12.2 14.8 Integration NA NA 6.7 12.0 17.3 Stage Found http://www.nist.gov
19. A BIONIC CULTURAL HAMMER Promotes openness Raises team standards Propels teamwork Keeps security top of mind Shapes the culture http://www.fullstory.com
20. WHEN YOU’RE THE REVIEWER
21. Don’t review for code style; there are much better things on which to spend your time, than arguing over the placement of white spaces. Looking for bugs and performance issues is the primary goal and is where the majority of your time should be spent. Suggestions on maintenance best practices can be brought up after the bugs have been discussed. . WHAT TO LOOK FOR - msdn.com
22. READ THE CODE  Learn by looking at the codebase  Search for patterns and anti-patterns  Look for what they’re doing well  Look for what they’re doing that is causing problems  Quantify the quality of the code  Not exhaustive, spot check - Shawn Wildermuth: Pluralsight
24. WHEN YOU’RE THE REVIEWER  Ask questions rather than make statements  Avoid the “why” questions  Give praise  Have good coding guidelines  Stay focused on the code, not the coder  There is more than one way to approach a solution  Look for patterns rather than individual bugs
25. HOW TO REVIEW CODE  Take your experience to bear  Find things to laud and things to fix  Look for common (repeated problems) not of-off issues  Review 200-400 lines at a time  Reviewing the entire code base is not beneficial  No code is perfect  Maintainable code is a feature - Shawn Wildermuth: Pluralsight
26. WHAT TO LOOK FOR  Does the code do the job is was supposed to do  Does the code follow coding guidelines  Are there just enough comments (none?)  Are there unit tests for this code  Can I understand this code from just reading it  Does this code belong here or in its own method/class (SRP)  Is code being replaced, commented out, or removed
27. WHAT NOT TO DO  Don’t get emotional  Don’t focus on blame  Don’t redesign the code  Don’t judge how you would have done it  Don’t include one-off problems
28. WHEN YOU’RE THE REVIEWEE
29. WHEN YOU’RE THE REVIEWEE • We get attached to our code, but can learn from the reviewers, even when they’re less experienced Remember the code isn’t you • Items the reviewers tend to look for • Do your own review with the checklist before submitting the code for review Have a checklist of review items • Are things missing? • Do things need to be updated? • Do things need to be removed? Help maintain the coding guidelines
30. ODDS AND ENDS
31. HOW OFTEN SHOULD YOU REVIEW CODE  Depends on the team  General rule: no code should be checked in / merged without a code review
32. THE BAD  Developer often feels it’s an attack on her design  It adds time to the schedule  Can become a battle of who is the better coder
33. WALK-THROUGH: THE PULL REQUEST Origin Remote Developer Fork Reviewers Developer
34. REVIEW  What is a code review  Impact of a code review  Types of code reviews  The Reviewer  The Reviewee
35. CONTACT / QUESTIONS craig@craigberntson.com @craigber www.craigberntson.com blogs.msmvps.com/craigber www.dotnetcurry.com www.speakerdeck.com/craigber speakerrate.com/craigber