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.

1. How to improve quality of the product using “code review” Mikalai alimenkou Aleksey solntsev

3. 6+ years in software development

4. 4+ years of working by Agile methodologies

5. Expert in Agile engineering practices

7. Agile volunteer

8. Certified Scrum Practitioner

9. Coordinator of translation of the book "Scrum and XP from the Trenches" and “Kanban and Scrum – making the most of both” into Russian

11. WhyCode Review works?

12. WhyCode Reviewcouldn’t work?

13. How to find reviewer?

16. Share knowledge

17. Improve collective code ownership

18. Check conformance

19. Verify completeness

20. Educate

21. Reach a consensus

23. Common principles: roles Third persons A reviewer An author

24. 3 main reasons why code review works

25. Two pair of eyes are better then one

26. «Teddy bear» effect

27. Common denominator

28. reasons why code review couldn’t work 3

29. Interpersonal conflict

30. “Ego” effect

31. Too bored procedure

32. 7 strategies how to choose a reviewer

33. 1. «Daddy at home»

34. 2. «Help yourself»

35. 3. «Review contract»

36. 4. «Control center»

37. 5. «SWAT»

38. 6. «Everybody dance»

39. 7. «Adulterous relationship»

40. 2 ways to drivecode review

41. 1. ATR (Author driver review) Yep, yep I’ve added a couple of new interfaces. There are the implementation. A reviewer An author

42. 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 reviewer An author

43. 7 answers you shouldknow

44. What should we start with? A reviewer

45. What to review? Look at code changes/differences Review whole solution Identify methods/functions and classes

46. How to organize code review? Use changes package (email, patch) Use separate branch in VCS Use distributed VCS Code exchange tools built in IDE Specialized instruments

47. Specialized instruments

48. Should we use metrics?

49. How long? 60

50. Fast or slow? 500

51. Big or small commits? 400

52. How to start? Make common decision Start slowly Select only the most problematic modules Inspect and adapt

53. 8 tipsand tricks

54. Before or after check-in?

56. Easy to find person who also knows the code

58. Comfortable conditions for reviewers

59. All rules should be on WIKI

60. Use pen and paper

61. Use static code analysis

62. Easy, tiger, easy

64. And what if … There are a lot of remarks after review Convert 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 time This 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 remarks Use Pair Programming practice for solving all problems

68. And what if … I need a reviewer ASAP Code review task should wait till the end of reviewer’s current task

69. And what if … Code review task is hanging Review has lifetime till the next Daily Scrum

70. Books

71. Q&A Email us: mikalai.alimenkou@xpinjection.com aleksey.solntsev@xpinjection.com