Effective code reviews
- 1. Effective Code Reviews William Deurwaarder 30th of May, 2015 NextBuild
- 2. Think profit-based, not cost-based. TomTom devices 2
- 3. Think profit-based, not cost-based. TomTom products Maps Navigation Traffic Fleet-management Fitness 3
- 4. Think profit-based, not cost-based. Introduction • Theory • Creates awareness, explains philosophy • Defines “defect” and explains its impact • Practice • How to improve the efficiency of reviews? • What is role and mindset of author and reviewer? • How to execute reviews?
- 5. Think profit-based, not cost-based. Perfect code What is perfect code? • Working • Readable • Maintainable • Extendable • Elegant • Simple and clear • Well documented • … Easy to recognize, hard to describe
- 6. Think profit-based, not cost-based. Not so perfect code Why is real code not so perfect? • Time-boxed • Lack of experience • Change on change • Edge cases • Built on legacy • Mindset author (problem solving, result oriented, pragmatic, …) • Multiple authors (own mind, no machines) Easy to describe, hard to fight
- 7. Think profit-based, not cost-based. Definition of defect What is a defect? • Highly unlikely defects • Race conditions • Timing issues • Extreme load • Trivial defects • Subjective term • Hard to predict impact of a defect Defect: anything that may cause any additional cost later on
- 8. Think profit-based, not cost-based. Cost of defects Cost to fix defect grows exponentially Consider 4 stages: design develop test production Every stage adds additional cost factor of 10 • code review instead of test: 10x cost savings • code review in stead of production: 100x cost savings Finding/fixing defects early is always faster and cheaper than not finding or not fixing them
- 9. Think profit-based, not cost-based. Cost of defects 1 single defect will pay for 100 99 defects never ever causes a problem 1 single defect causes a problem in production Question is: which one? No significant additional cost fixing 5 or 50 defects Building, Reviewing, Testing, Deploying Fix ALL defects that you can find (no priorities)
- 10. Think profit-based, not cost-based. Fix ALL defects What happens next? • No trivial defects any more • No discussion on minor and major, just defect • No subjective reasoning Cleaner and more useful statistics as well • Code gets higher quality and is easier to review Increased developer pride, reduced ‘broken window’ effect
- 11. Think profit-based, not cost-based. Change your thinking! The cost of fixing everything is small, and the profit is much higher than the cost Fix all defects that are found • Ensure defects that cause issues are fixed • Ensure defect that pays for all other defects is fixed Think profit-based, not cost-based
- 12. Think profit-based, not cost-based. Statistics This is about applied statistics Good engineers respect statistics You are an engineer… respect and obey statistics! Know: Many defects will never cause an issue if left unfixed So: Fixing an individual defect does not necessarily reduce cost And: Some (unlikely) defects will lead to great cost if left unfixed But: You cannot tell which defect will cause an issue Not about individual defects or reviews, about applying this practice continuously -> benefits
- 13. Think profit-based, not cost-based. Theory summary Defects enter our code for a lot of reasons Defect is anything that cause additional costs Cost to fix defect grows exponentially Fix ALL defects Think profit-based It is all about statistics
- 14. Effective Code Reviews (Practice) William Deurwaarder 30th of May, 2015
- 15. Think profit-based, not cost-based. Introduction • Theory (previous session) • Creates awareness, explains philosophy • Defines “defect” and explains its impact • Practice • How to improve the efficiency of reviews? • What is role and mindset of author and reviewer? • How to execute reviews?
- 16. Think profit-based, not cost-based. Improve quality How can reviews address mentioned issues? • Reviewer has different goal so different mindset • Author solves the problem • Reviewer checks code quality (guardian) • Solution fits context • Solution adheres to good practices • Reviewer is not bothered by time (dead-line) • Reviewer looks at code from different angle Code review is an easy tool to increase quality
- 17. Think profit-based, not cost-based. Increase efficiency of reviews What can be changed to become effective? • A: Ensure changes are ready (static code analysis, annotate) • A: Limit number of reviewers (default is 2) • R: Find as many defects as possible (time-boxed) • R: Be thorough (address everything that catches the eye) • Sharing knowledge • Establish team-culture (abbreviations, code duplication) • A: Fix ALL defects (no priorities) • R+A: work together, same goal (peers) • No need to defend yourself: “finding more defects is better”
- 18. Think profit-based, not cost-based. Role and mindset author Problem solver – solution driven – time aware • Prepare review (static code analysis, review yourself, annotate) • Remarks aim to increase quality of code • not to discuss author’s ability to code (no defense) • Normally answer questions with comment in code • Review will almost never be read again, code will • Address ALL found defects (no priorities) • minor defects take very little time to fix (no discussion required) • Handle clearly incorrect remarks respectfully • Discuss off-line; comment in code? • Author is end responsible for changes and quality
- 19. Think profit-based, not cost-based. Role and mindset reviewer Guardian – quality driven – time-boxed • Execute review promptly (do not become a bottleneck) • Make only remarks to improve quality of code • Do not offer solutions or “better alternatives” • Do not “educate” the author (off-line, coaching) • Thorough, relentless AND respectful • Can never find too many defects (slow pace) • Avoid religious wars, no personal flavors, only technical • Explain why something needs improvement • Ignore amount of rework to fix defect • Always re-review after author updated code (prompt)
- 20. Think profit-based, not cost-based. Tone of review • Be neutral, explain your interpretation • Be aware of different mindset • Be respectful (no SHOUTING!, no telling, no lecture, use keywords) • Explain with reasoning in case technical solution needs improvement • Single problem may have multiple solutions • Search for reasons of unclarity (do not ask why to quickly) Remember goal • author is responsible for code quality • reviewer helps author to establish level of quality • working together as peers to improve quality
- 21. Think profit-based, not cost-based. Examples - What is this about? + The context is unclear, can you explain… - This sucks… + This causes issues like x, y, z… - Did you read the documentation at all? + The documentation specifies x rather than doing y… - You should implement this completely different! + Doing x causes issues y and z in… - NO, NO, NO… + This causes issues x, y, z in…
- 22. Think profit-based, not cost-based. Defect remark strategy • Gather context information (design, user-story, JIRA-issue) • Focus on changes, keep eye on context • Search for patterns and inconsistencies • Check complexity (bang-for-buck, keep-it-simple-stupid) • Let unconscious mind help (bell ringing -> investigate) • Act like logical compiler (do not interpret code -> read code) • Ask if something is unclear (comment should be added) • Mark all style defects (diminishes quickly, static code analysis) • Code removal – check correct and complete • Use checklists
- 23. Think profit-based, not cost-based. Practice summary Author is responsible for code quality Reviewer helps author to establish level of quality Author and reviewer work together as peers Reviewer is thorough, relentless and prompt Author fixes all found defects Reviewer review all changesBe polite
- 24. Think profit-based, not cost-based. Code review rules Time-boxed period to polish the code
- 25. Thank you Any questions? William Deurwaarder Head of Developer Relations, TomTom E-mail: william.deurwaarder@tomtom.com Website: http://developer.tomtom.com
- 26. Think profit-based, not cost-based. Code-review figures Indication of important figures • Minimum review time per session 5 minutes • Maximum review time per session 60 – 90 minutes • Maximum review size per session 200 – 400 LOC • Default number of reviewers 2 • Maximum inspection rate 300 – 500 LOC / hour
- 27. Think profit-based, not cost-based. Checklist for code-review (1/4) Check consistency with design (see change in bigger scope) • Verify edge-cases Check consistency interface changes • Scope changed (private to public; why?) • Order of parameters (same in all methods) • Symmetrical methods • Use of default parameters • Implementation details leak through in interface Check level of containment (increasingly risky, increase scope) • Within method • Within private methods • Within public class methods • Within public interface of system (NavKit)
- 28. Think profit-based, not cost-based. Checklist for code-review (2/4) Check complexity • Keep algorithms clean (no exceptional cases) • Verify edge-cases… throw exception in stead? • Try what-if scenarios Check exception handling • Is exception caught? • Adheres to exception handling policy • Exception handling aligned with surrounding code Check readability, clarity (decrease time to understand code) • Remove code duplication (extract method) • Check functionality of method (reduce size of method) • Add comments to increase readability
- 29. Think profit-based, not cost-based. Checklist for code-review (3/4) Check includes/imports (needed? correct?) Check NULL-pointer behavior (can reference be used?) Check const-behavior (consistent, no const_cast) Check algorithms for one-off errors Check resource leakage (memory, file handles, …) Check multi-threading behavior • Race-conditions • Dead-lock situations Check usage of members and local variables • No state duplication (only for measured performance improvement) • Superfluous • No re-use of variables with different meaning
- 30. Think profit-based, not cost-based. Checklist for code-review (4/4) Check type-casts (discourage them) Check surrounding comments Check correct usage of libraries (STL, OSAL, …) Check “early” optimization • Is measurement in place? • Is there comment with explanation? Check use of deprecated code • NavKit-examples: NavKitEnvironment, Tdes, CString Check use of discouraged patterns • Singleton Check if tests exists