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.

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

3. Agile volunteer

4. Certified Scrum Practitioner

5. Initiator and coordinator of translation of the cult book "Scrum and XP from the Trenches" into Russian

7. Where is quality better?

9. Share knowledge

10. Improve collective code ownership

11. Check conformance

12. Verify completeness

13. Educate

14. Reach a consensus

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

17. 3 main reasons why code review works

18. Two pair of eyes are better then one

19. «Teddy bear» effect

20. Common denominator

21. reasons why code review couldn’t work 3

22. Interpersonal conflict

23. “Ego” effect

24. Too bored procedure

25. 7 strategies how to choose a reviewer

26. 1. «Daddy at home»

27. 2. «Help yourself»

28. 3. «Review contract»

29. 4. «Control center»

30. 5. «SWAT»

31. 6. «Everybody dance»

32. 7. «Adulterous relationship»

33. 2 ways to drivecode review

34. 1. ATR (Author driver review) Yep, yep I’ve added a couple of new interfaces. There are the implementation. A reviewer An 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 reviewer An author

36. 7 answers you shouldknow

37. What should we start with? A reviewer

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

39. How to organize code review? Use changes package (email, patch, etc.) Use separate branch in VCS Use distributed VCS Code exchange tools built in IDE Specialized 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 decision 2. Start slowly 3. Select only the most problematic modules 4. Inspect and adapt

46. 8 tipsand tricks

47. Before or after check-in?

49. Easy to find person who also knows the code

51. Comfortable conditions for reviewers

52. All rules should be on WIKI

53. Use pen and paper

54. Use static code analysis

55. Easy, tiger, easy

56. And what …

57. Books

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