![Why do we review code?
• Find bugs
• Transfer knowledge
• Lower project cost
• [ Hiring a candidate ]](https://image.slidesharecdn.com/20160513codereviewsquatico-160518070159/85/Code-Reviews-Quatico-3-320.jpg)
Uploaded byJan Wloka
Code Reviews @ Quatico
The document outlines best practices for conducting code reviews, emphasizing their importance in finding bugs, transferring knowledge, and lowering project costs. It provides guidelines for both authors and reviewers on how to effectively conduct reviews, including the need for structured feedback, maintaining clear communication, and fostering a strong review culture. The document also addresses the recommended limits on lines of code for review and encourages authors to provide context for their changes.
Code Reviews @ Quatico
- 1. Code Reviews @ Quatico JanWloka Quatico Solutions AG
- 2.
- 3. Why do wereview code? • Find bugs • Transfer knowledge • Lower project cost • [ Hiring a candidate ]
- 4. How would youreview? • Branch —> Code —> Assign Pull Request! • Create a feature branch • Implement the feature • Create a pull request • Assign a reviewer • Discuss (and add changes to) pull request • Approve and merge pull request
- 5. PR, really? Youalso could… • Code —> Push —> Assign Ticket! • Implement the feature • Commit with message • Push changes • Assign ticket w/ commits to review
- 6. Sure, but howdo I review? • Read the issue ticket: “the why” • Checkout the code/branch • Run the tests w/ coverage • Check the console • Review the change
- 7. What should Ibe reviewing? •Change • Complexity: Shape of change = complex • Test Coverage •Code • Naming, Functionality, Control Structures, Error Handling • Tricky things (Thread Safety, Resource Leaks, Timezones) • No obvious things: Performance, Security •Design • Single Responsibility Principle (Implicit dependencies) • Data lifecycle (Cache invalidation, Reentrancy) •Everything else: Tests, Builds, Deployment scripts, Configurations
- 8. Whoa. We shouldmake checklist!
- 9. So, what’s hardabout it? • Process is more difficult than the result • Discuss your code with your peers • How to disagree? • Don’t just agree on the issue —> Silent Commitment. • No fear of conflict —> Be curious! • Agree to disagree —> Ask and learn. • Form a strong code review culture!
- 10. Okay, but what canI do?
- 11. Authors: Provide Context! •What problems are we solving? • Pull Request / Commit message: • Add 2 paragraphs of context. • Annotate source code. • Describe changes, defending reasons and methods. • Re-think and explain every change.
- 12. Background: Prepare your code. SmartBearStudy 300 reviews, about 15% random samples
- 13. Guidelines for Authors •The primary reviewer is the author, i.e. YOU. • Review your own code BEFORE commit. • Create a checklist for yourself. • You are not your code. Good code is…
- 14. Reviewers: Ask don’ttell • What have you learned? • Critique the code, instead of people • Ask questions, rather than make statements • “What do you think …” • “Did you consider …” • “Can you clarify …” • Avoid ‘why’ questions, be more specific! • Don’t forget to praise.
- 15. Background: How many LOCsto review? Defect density dramatically decreases when the number of lines of inspection goes above 200, and is almost zero after 400.
- 16. Background: Inspection rate If youdon’t spend enough time, you won't find many defects. Faster than 400-500 LOC/hour results in severe drop-off in effectiveness.
- 17. Guidelines for Reviewers •Review fewer than 400 LOC at a time. • Aim for less than 500 LOC / hour. • Take your time, but quit after 60mins. • Establish quantifiable goals. Capture metrics.
- 18. Goal: Structured feedback • MustHaves: “How to get your approval” • Customer facing incompleteness and inconsistencies • Obvious bugs, and everything on the checklist • Nice To Haves: “How to improve the code base” • New design flaws, or known code smells • Reduced test coverage, performance • Everything you can live with, but don’t want to • Superhero Deeds: “How to show love to your team” • What are your peers working on? Can you help? • Extra test data, mocks, anything done easily that helps.
- 19. We all makemistakes, but… • Verify that defects are actually fixed! • Managers foster good code reviews. • ‘Big Brother Effect’ versus ‘Ego Effect’. • Authors never merge own Pull Requests. • Tech leads aren’t gatekeepers.
- 20. Next Steps • Authors:“Provide more context” • Favour pull requests, over direct commits. • Annotate your change, explain the ‘why’ • Maintain a personal checklist. • Review every modification, before push. • Reviewers: “Provide structured feedback” • Critique the code, not the coder. • Use the checklist. • Be specific, and helpful. • Don’t forget to praise.
- 21. Goal: Strong Review Culture •Better code. • Better developers. • Team ownership > Code ownership. • Healthy debate > No silent agreement.
- 22.
- 23. References • Best Practicesfor Code Reviews http://www.smartbear.com/docs/ BestPracticesForPeerCodeReview.pdf • The Ten Commandments of Egoless Programming http://www.codinghorror.com/blog/2006/05/the- ten-commandments-of-egoless-programming.html • Effective Code Reviews Without the Pain http://www.developer.com/java/other/article.php/ 3579756 Thanks to geek-and-poke.com & commadot.com