Code Reviews: The #1 Way to Improve Code Quality

Code Reviews: The #1 Way to Improve Code Quality

008c45c68ff49184796deda5faca4126?s=128

Craig Berntson

October 01, 2016
Tweet

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
  6. None
  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
  23. None
  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

  36. None