Code Review

7,648
-1

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
1 Comment
13 Likes
Statistics
Notes
No Downloads
Views
Total Views
7,648
On Slideshare
0
From Embeds
0
Number of Embeds
8
Actions
Shares
0
Downloads
20
Comments
1
Likes
13
Embeds 0
No embeds

No notes for slide

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

×