Why you should integrate peer code reviews in your software company
2 likes485 views
The document discusses the importance of code reviews in software development, highlighting their role in improving code quality, developer knowledge, and teamwork. It outlines the review process, common questions to consider, and practical tips for effective reviews, such as reviewing small amounts of code and integrating reviews with agile practices. The document emphasizes that code reviews facilitate knowledge sharing, reduce reliance on individual developers, and enhance overall project efficiency.
Why you should integrate peer code reviews in your software company
- 1. <CODE REVIEWS/> Why you should do December 2015
- 2. WHO AM I? Ma s Devriendt Developer & entrepreneur @iMa s
- 3. Image source: http://image.shutterstock.com/z/stock-photo-portrait-of-alarmed-man-99912533.jpg CODE REVIEWS ?
- 4. Code review is systematic examination (often known as peer review) of a developer’s source code. CODE REVIEWS ?
- 5. GOAL? Improve the overall quality of the software product and the knowledge of developers CODE REVIEWS ?
- 7. When a developer is finished working on an issue, another developer looks over the code and considers questions like: WHEN & WHAT?
- 8. 1) ERRORS Are there any obvious logic errors in the code? WHEN & WHAT?
- 9. 2) REQUIREMENTS Looking at the requirements, are all cases fully implemented? WHEN & WHAT?
- 10. 3) TESTS A) Are the new automated tests sufficient for the new code? B) Do existing automated tests need to be rewri en to account for changes in the code? WHEN & WHAT?
- 11. 4) STYLE GUIDELINES Does the new code conform to existing style guidelines? WHEN & WHAT?
- 12. Image source: http://image.shutterstock.com/z/stock-photo-switchboard-94006822.jpg WHY DO CODE REVIEWS MATTER? for developers and (project-)managers
- 13. Code is reviewed by another developer WHY DO CR MATTER?
- 14. Code is reviewed by another developer WHY DO CR MATTER? Developers will be more likely to write comments and tests Better code quality & less bugs New employees come up to speed faster ü Knowledge of other developers: possible improvements, new classes/methods/libraries, new insights, be er ways, … ü Because developer knows his/her code will be reviewed
- 15. No one is the only person who knows a specific part of the code base WHY DO CR MATTER?
- 16. No one is the only person who knows a specific part of the code base WHY DO CR MATTER? Teamwork Flexibility: Shared responsibility ü Others can help out if needed (to meet deadlines) They can take work of the backlog and start programming ü Be er control of resources: developers can be interchanged more easily (they will already know about the source code)
- 17. No one is the only person who knows a specific part of the code base WHY DO CR MATTER? Less human resources problems: Peace of mind When only 1 person knows about the source code of a program: What if he/she is not in the office? Or worse: what if he/she left the company… “Hé can you do a small bugfix because Mr. X is not here and things are failing on the production server?” No one is the critical path
- 18. Knowledge sharing WHY DO CR MATTER?
- 19. Knowledge sharing WHY DO CR MATTER? Opportunity to learn about a new languages, libraries and frameworks. Hidden knowledge New SDKs ‘Known issues’
- 20. And many other advantages… WHY DO CR MATTER? Early feedback in development process Extra efforts of developers for well-designed code and passing tests Shared load No code gets in unreviewed (code written at 3am or by inters)
- 22. Review as soon as possible, before merging PRACTICAL TIPS Use git-pull or work with a branch-approach where a feature- branch can only be merged to development if it’s reviewed
- 23. How fast should code be reviewed? PRACTICAL TIPS 200-300 lines of code / hour Background image: Smartbear - Cisco Case Study - Plotting inspection size versus time at Cisco. There is no apparent systematic "inspection rate.”
- 24. Take time for a decent review PRACTICAL TIPS Source: Smartbear - Cisco Case Study Reviewers become less effective at finding defects as their pace through the review accelerates.
- 25. How much lines should be reviewed at a time? PRACTICAL TIPS Reviewers are most effective at reviewing small amounts of code. 200 – 400 lines Source: Smartbear - Cisco Case Study
- 26. Total review time PRACTICAL TIPS Less than 60 minutes, max 90 minutes Source: Smartbear - Cisco Case Study
- 27. Image source: http://image.shutterstock.com/z/stock-photo-parents-visiting-day-93711238.jpg CODE REVIEWS ARE PART OF THE AGILE APPROACH, COMBINE CODE REVIEWS WITH CONTINUOUS INTEGRATION, TESTING, SCRUM, … AND AIM FOR ULTIMATE FLEXIBILITY!
- 28. Image source: http://image.shutterstock.com/z/stock-photo-group-of-photographers-taking-picture-with-cameras-99830894.jpg QUESTIONS? START CODE REVIEWING!
- 29. Sources and references • h#ps://www.atlassian.com/agile/code-‐reviews • h#p://support.smartbear.com/support/media/resources/cc/book/code-‐review-‐cisco-‐case-‐ study.pdf
Editor's Notes
- #8: Geautomatiseerde testen moeten wel eerst slagen! De reviewtijd moet dienen voor zaken die niet onder de tests vallen.
- #15: De code zal niet vervuild raken vanwege slechte programmeerbeslissingen.
- #16: Simply put, code reviews help facilitate knowledge sharing across the code base and across the team.
- #18: Nobody likes to inherit thousands of lines of new code Peace of mind: je weet dat anderen het product kunnen builden, verder werken, … Je mag gerust een dag verlof nemen.
- #24: Reviewers slower than 400 lines per hour were above average in their ability to uncover defects. But when faster than 450 lines/hour the defect density is below average in 87% of the cases.
- #25: Reviewers become less effective at finding defects as their pace through the review accelerates.