Your SlideShare is downloading. ×
How to improve quality of the product using “code review”<br />Mikalai <br />alimenkou<br />Aleksey <br />solntsev<br />
Alimenkou Mikalai<br />Java Technical Lead/Scrum Master at Zoral Labs<br />6+ years in software development<br />4+ years ...
Agile volunteer
Certified Scrum Practitioner
Initiator and coordinator of translation of the cult book "Scrum and XP from the Trenches" into Russian
Agile coach at XP Injection</li></li></ul><li>Agenda<br />Introduction and common principles<br />WhyCode Review works?<br...
Where is quality better?<br />
Goals of code review<br /><ul><li>Improve quality of code
Share knowledge
Improve collective code ownership
Check conformance
Verify completeness
Educate
Reach a consensus
Try other approaches</li></li></ul><li>Classification<br />Less formal<br />Most formal<br />
Common principles: roles<br />Third persons<br />A reviewer<br />An author<br />
3<br />main reasons why code review works<br />
Two pair of eyes are better then one<br />
«Teddy bear» effect<br />
Common denominator<br />
reasons why code review couldn’t work<br />3<br />
Interpersonal conflict<br />
“Ego” effect<br />
Too bored procedure<br />
7<br />strategies how to choose a reviewer<br />
1. «Daddy at home»<br />
2. «Help yourself»<br />
3. «Review contract»<br />
4. «Control center»<br />
5. «SWAT»<br />
6. «Everybody dance»<br />
7. «Adulterous relationship»<br />
2<br />ways to drivecode review<br />
1. ATR (Author driver review)<br />Yep, yep<br />I’ve added a couple of new interfaces. There are the implementation.<br /...
2. RTR (Reviewer driven review)<br />Hmm… I don’t understand what you try to verify using <br />this test.<br />Actually, ...
7<br />answers you shouldknow <br />
What should we start with?<br />A reviewer<br />
What to review?<br />Look at code changes/differences<br />Review whole solution<br />Identify methods/functions and class...
How to organize code review?<br />Use changes package (email, patch, etc.)<br />Use separate branch in VCS<br />Use distri...
How to organize code review?<br />
Should we use metrics?<br />
How long?<br />60<br />
Fast or slow?<br />500<br />
Big or small commits?<br />400<br />
How to start?<br />1. Make common decision<br />2. Start slowly<br />3. Select only the most <br />   problematic modules<...
8<br />tipsand tricks<br />
Before or after check-in?<br />
Track reviewers<br /><ul><li>Not for blame
Upcoming SlideShare
Loading in...5
×

Code review

13,717

Published on

Многие жалуются на качество кода, автоматизированных тестов или продукта в целом, на количество ошибок, найденных конечными пользователями или отделом тестирования. Почему это происходит? Необходимо понимать, что для того чтобы не допустить подобных ситуаций требуются дополнительные усилия – необходимо следить за качеством кода и работать над его улучшением.

Code Review является одной из наиболее полезных и эффективных практик для ранней борьбы с дефектами в коде и повышению его качества. Использование Code Review на различных этапах разработки, начиная от дизайна и заканчивая написанием кода и тестов, помогает построить ранний цикл обратной связи и избежать потерь времени в будущем на исправление ошибок.

Дополнительным преимуществом применения Code Review является распространение знаний между членами команды и адаптация других командных подходов. Данная практика может быть интересна любому члену команды вне зависимости от его роли в проекте.

В докладе будут рассмотрены основные аспекты Code Review, способы проведения, инструменты и техники. Также будут продемонстрированы основные ошибки в использовании этой практики, полезные советы, приемы по внедрению и поддержке.

Published in: Technology
0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
13,717
On Slideshare
0
From Embeds
0
Number of Embeds
6
Actions
Shares
0
Downloads
13
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide
  • Спецотряд
  • Так, что-то я не понимаю, что ты проверяешь этим тестом.
  • Строчки дока, количество найтденных ошибок, ....
  • Aleksey: before in most cases because of trunk should contain only good code.
  • Есликоднепроходитревьювторойраз, тоонсчитаетсяопасным и ревьювитсяещекем-тоЕслизамечанияпростые, тоониисправляются в паресразуприревьюЕслизамечанийоченьмного, тоониразбиваютсянаполноценныезадачичтобынезатягиватьЕсликоднепрошелревьювовторойраз и естьсерьезныезамечания, тоонобязательноделается в пареРевьюсчитаетсямаксимальнымприоритетом, нонепрерываеттекущейзадачи (ждемперерыва)Задачанеможетпровисетьнаревьюдольшечемдоследующегодэйлискрама 
  • Transcript of "Code review"

    1. 1. How to improve quality of the product using “code review”<br />Mikalai <br />alimenkou<br />Aleksey <br />solntsev<br />
    2. 2. Alimenkou Mikalai<br />Java Technical Lead/Scrum Master at Zoral Labs<br />6+ years in software development<br />4+ years of working by Agile methodologies<br />Expert in Agile engineering practices<br />Agile coach at XP Injection<br />Solntsev Aleksey<br /><ul><li>Process Architect at Infopulse Ukraine
    3. 3. Agile volunteer
    4. 4. Certified Scrum Practitioner
    5. 5. Initiator and coordinator of translation of the cult book "Scrum and XP from the Trenches" into Russian
    6. 6. Agile coach at XP Injection</li></li></ul><li>Agenda<br />Introduction and common principles<br />WhyCode Review works?<br />WhyCode Reviewcouldn’t work?<br />How to find reviewer?<br />Practices, metrics, tips and tricks<br />
    7. 7. Where is quality better?<br />
    8. 8. Goals of code review<br /><ul><li>Improve quality of code
    9. 9. Share knowledge
    10. 10. Improve collective code ownership
    11. 11. Check conformance
    12. 12. Verify completeness
    13. 13. Educate
    14. 14. Reach a consensus
    15. 15. Try other approaches</li></li></ul><li>Classification<br />Less formal<br />Most formal<br />
    16. 16. Common principles: roles<br />Third persons<br />A reviewer<br />An author<br />
    17. 17. 3<br />main reasons why code review works<br />
    18. 18. Two pair of eyes are better then one<br />
    19. 19. «Teddy bear» effect<br />
    20. 20. Common denominator<br />
    21. 21. reasons why code review couldn’t work<br />3<br />
    22. 22. Interpersonal conflict<br />
    23. 23. “Ego” effect<br />
    24. 24. Too bored procedure<br />
    25. 25. 7<br />strategies how to choose a reviewer<br />
    26. 26. 1. «Daddy at home»<br />
    27. 27. 2. «Help yourself»<br />
    28. 28. 3. «Review contract»<br />
    29. 29. 4. «Control center»<br />
    30. 30. 5. «SWAT»<br />
    31. 31. 6. «Everybody dance»<br />
    32. 32. 7. «Adulterous relationship»<br />
    33. 33. 2<br />ways to drivecode review<br />
    34. 34. 1. ATR (Author driver review)<br />Yep, yep<br />I’ve added a couple of new interfaces. There are the implementation.<br />A reviewer<br />An author<br />
    35. 35. 2. RTR (Reviewer driven review)<br />Hmm… I don’t understand what you try to verify using <br />this test.<br />Actually, I’m also a little bit confused …<br />A reviewer<br />An author<br />
    36. 36. 7<br />answers you shouldknow <br />
    37. 37. What should we start with?<br />A reviewer<br />
    38. 38. What to review?<br />Look at code changes/differences<br />Review whole solution<br />Identify methods/functions and classes<br />
    39. 39. How to organize code review?<br />Use changes package (email, patch, etc.)<br />Use separate branch in VCS<br />Use distributed VCS<br />Code exchange tools built in IDE<br />Specialized instruments<br />
    40. 40. How to organize code review?<br />
    41. 41. Should we use metrics?<br />
    42. 42. How long?<br />60<br />
    43. 43. Fast or slow?<br />500<br />
    44. 44. Big or small commits?<br />400<br />
    45. 45. How to start?<br />1. Make common decision<br />2. Start slowly<br />3. Select only the most <br /> problematic modules<br />4. Inspect and adapt<br />
    46. 46. 8<br />tipsand tricks<br />
    47. 47. Before or after check-in?<br />
    48. 48. Track reviewers<br /><ul><li>Not for blame
    49. 49. Easy to find person who also knows the code
    50. 50. More responsibility for reviewer</li></li></ul><li>Checklist – make your live easier<br />Has error handling code been tested?<br />Are objects accessed by multiple <br />threads thread-safe?<br />Are variables initialized before <br />they are used?<br />
    51. 51. Comfortable conditions for reviewers<br />
    52. 52. All rules should be on WIKI<br />
    53. 53. Use pen and paper<br />
    54. 54. Use static code analysis<br />
    55. 55. Easy, tiger, easy<br />
    56. 56. And what …<br />
    57. 57. Books<br />
    58. 58. Q&A<br />Email us:<br />mikalai.alimenkou@xpinjection.com<br />aleksey.solntsev@xpinjection.com<br />

    ×