Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
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
Easy to find person who also knows the code
More responsibility for reviewer</li></li></ul><li>Checklist – make your live easier<br />Has error handling code been tes...
Comfortable conditions for reviewers<br />
All rules should be on WIKI<br />
Use pen and paper<br />
Use static code analysis<br />
Upcoming SlideShare
Loading in …5
×

Code Review

10,184 views

Published on

Presentation from Agile Base Camp 2 conference (Kiev, May 2010) and AgileDays'11 (Moscow, March 2011) about one of the most useful engineering practices from XP world.

Published in: Technology

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 />

×