Code review
4 likes6,417 views
This document discusses how to improve software quality through code reviews. It begins by stating the goals of code review, such as improving code quality, sharing knowledge, and educating developers. It then discusses classification of code reviews from less to more formal. The document outlines some best practices for code reviews, including having a reviewer and author, choosing reviewers strategically, and driving the review in different ways. It provides answers to common questions about organizing effective code reviews and leaves with tips, such as tracking reviewers, using checklists, and ensuring comfortable conditions for all.
Code review
- 1. How to improve quality of the product using “code review”Mikalai alimenkouAleksey solntsev
- 2. Alimenkou MikalaiJava Technical Lead/Scrum Master at Zoral Labs6+ years in software development4+ years of working by Agile methodologiesExpert in Agile engineering practicesAgile coach at XP InjectionSolntsev AlekseyProcess Architect at Infopulse Ukraine
- 5. Initiator and coordinator of translation of the cult book "Scrum and XP from the Trenches" into Russian
- 6. Agile coach at XP InjectionAgendaIntroduction and common principlesWhyCode Review works?WhyCode Reviewcouldn’t work?How to find reviewer?Practices, metrics, tips and tricks
- 7. Where is quality better?
- 8. Goals of code reviewImprove quality of code
- 10. Improve collective code ownership
- 13. Educate
- 15. Try other approachesClassificationLess formalMost formal
- 16. Common principles: rolesThird personsA reviewerAn author
- 17. 3main reasons why code review works
- 18. Two pair of eyes are better then one
- 21. reasons why code review couldn’t work3
- 23. “Ego” effect
- 25. 7strategies how to choose a reviewer
- 26. 1. «Daddy at home»
- 30. 5. «SWAT»
- 33. 2ways to drivecode review
- 34. 1. ATR (Author driver review)Yep, yepI’ve added a couple of new interfaces. There are the implementation.A reviewerAn author
- 35. 2. RTR (Reviewer driven 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
- 37. What should we start with?A reviewer
- 38. What to review?Look at code changes/differencesReview whole solutionIdentify methods/functions and classes
- 39. How to organize code review?Use changes package (email, patch, etc.)Use separate branch in VCSUse distributed VCSCode exchange tools built in IDESpecialized instruments
- 40. How to organize code review?
- 41. Should we use metrics?
- 42. How long?60
- 43. Fast or slow?500
- 44. Big or small commits?400
- 45. How to start?1. Make common decision2. Start slowly3. Select only the most problematic modules4. Inspect and adapt
- 46. 8tipsand tricks
- 47. Before or after check-in?
- 48. Track reviewersNot for blame
- 49. Easy to find person who also knows the code
- 50. More responsibility for reviewerChecklist – make your live easierHas error handling code been tested?Are objects accessed by multiple threads thread-safe?Are variables initialized before they are used?
- 51. Comfortable conditions for reviewers
- 52. All rules should be on WIKI
- 53. Use pen and paper
- 54. Use static code analysis
- 56. And what …
- 57. Books
Editor's Notes
- #22: Спецотряд
- #27: Так, что-то я не понимаю, что ты проверяешь этим тестом.
- #33: Строчки дока, количество найтденных ошибок, ....
- #39: Aleksey: before in most cases because of trunk should contain only good code.
- #47: Есликоднепроходитревьювторойраз, тоонсчитаетсяопасным и ревьювитсяещекем-тоЕслизамечанияпростые, тоониисправляются в паресразуприревьюЕслизамечанийоченьмного, тоониразбиваютсянаполноценныезадачичтобынезатягиватьЕсликоднепрошелревьювовторойраз и естьсерьезныезамечания, тоонобязательноделается в пареРевьюсчитаетсямаксимальнымприоритетом, нонепрерываеттекущейзадачи (ждемперерыва)Задачанеможетпровисетьнаревьюдольшечемдоследующегодэйлискрама