Uploaded byMikalai Alimenkou
Code Review
The document outlines strategies for improving product quality through effective code review practices. It discusses the benefits and common challenges of code reviews, as well as tips for selecting reviewers, organizing reviews, and utilizing metrics. Additionally, it provides solutions to common issues that arise during the code review process, such as handling feedback and ensuring timely reviews.
More Related Content
More from Mikalai Alimenkou
![Hexagonal architecture with Spring Boot [EPAM Java online conference]](https://cdn.slidesharecdn.com/ss_thumbnails/hexagonalarchitecturewithspringboot-180925151506-thumbnail.jpg?width=640&height=640&fit=bounds)
![Bro, manage test data like a pro! [QA Fest 2018]](https://cdn.slidesharecdn.com/ss_thumbnails/bromanagetestdatalikeapro-180922193659-thumbnail.jpg?width=640&height=640&fit=bounds)
Code Review
- 1. How to improvequality of the product using “code review”Mikalai alimenkouAleksey solntsev
- 2. Mikalai AlimenkouJava TechnicalLead/Scrum Master at Zoral Labs
- 3. 6+ years insoftware development
- 4. 4+ years ofworking by Agile methodologies
- 5. Expert in Agileengineering practices
- 6. Agile coach at XPInjectionAleksey SolntsevProcess Architect at Infopulse Ukraine
- 7.
- 8.
- 9. Coordinator of translationof the book "Scrum and XP from the Trenches" and “Kanban and Scrum – making the most of both” into Russian
- 10. Agile coach at XPInjectionAgendaIntroduction and common principles
- 11.
- 12.
- 13. How to findreviewer?
- 14. Practices, metrics, tipsand tricksWhere is quality better?
- 15. Goals of codereviewImprove quality of code
- 16.
- 17. Improve collective codeownership
- 18.
- 19.
- 20.
- 21.
- 22. Try other approachesClassificationLessformalMost formal
- 23. Common principles: rolesThirdpersonsA reviewerAn author
- 24. 3main reasons whycode review works
- 25. Two pair ofeyes are better then one
- 26.
- 27.
- 28. reasons why codereview couldn’t work3
- 29.
- 30.
- 31.
- 32. 7strategies how tochoose a reviewer
- 33. 1. «Daddy athome»
- 34.
- 35.
- 36.
- 37.
- 38.
- 39.
- 40. 2ways to drivecodereview
- 41. 1. ATR (Authordriver review)Yep, yepI’ve added a couple of new interfaces. There are the implementation.A reviewerAn author
- 42. 2. RTR (Reviewerdriven review)Hmm… I don’t understand what you try to verify using this test.Actually, I’m also a little bit confused …A reviewerAn author
- 43.
- 44. What should westart with?A reviewer
- 45. What to review?Lookat code changes/differencesReview whole solutionIdentify methods/functions and classes
- 46. How to organizecode review?Use changes package (email, patch)Use separate branch in VCSUse distributed VCSCode exchange tools built in IDESpecialized instruments
- 47.
- 48. Should we usemetrics?
- 49.
- 50.
- 51. Big or smallcommits?400
- 52. How to start?Makecommon decisionStart slowlySelect only the most problematic modulesInspect and adapt
- 53.
- 54. Before or aftercheck-in?
- 55.
- 56. Easy to findperson who also knows the code
- 57. More responsibility forreviewerChecklist – make your live easierHas error handling code been tested?Are objects accessed by multiple threads thread-safe?Are variables initialized before they are used?
- 58. Comfortable conditions forreviewers
- 59. All rules shouldbe on WIKI
- 60. Use pen andpaper
- 61. Use static codeanalysis
- 62.
- 64. And what if…There are a lot of remarks after reviewConvert remarks in real task
- 65. And what if…All notices are primitive Fix them immediately
- 66. And what if…Code didn’t pass a review the second timeThis code is dangerous and should be verified by one more reviewer
- 67. And what if…Code didn’t pass a review the second time and there are couple of serious remarksUse Pair Programming practice for solving all problems
- 68. And what if…I need a reviewer ASAPCode review task should wait till the end of reviewer’s current task
- 69. And what if…Code review task is hangingReview has lifetime till the next Daily Scrum
- 70.
- 71.