The document discusses the agile process of peer code review, emphasizing its alignment with agile principles such as promoting sustainable development and continuous attention to technical excellence. It highlights different methods of code review, tools available, and statistical evidence of efficiency improvements, while suggesting best practices for implementation. Additionally, it addresses common concerns about code review processes and the importance of constructive feedback.

1. Peer Code Review: An Agile Process

2. Gregg Sporar Senior Product Manager [email_address] http://blog.smartbear.com http://twitter.com/smartbears

3. Code Collaborator codecollaborator.com

7. But is code review really Agile?

8. Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan The Manifesto

9. Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan The Manifesto

10. Working software is the primary measure of progress. Manifesto Principles - I

11. Working software is the primary measure of progress. Manifesto Principles - I

12. Requirements Design Architecture

13. Requirements Design Architecture Code Discussion Review Review Where many of the bugs come from (void)0

14. Professional Writers Have Editors

16. Spell Czech: Good, butt knot enough

17. ROI: The Experiment

18. Rule of Bug: Earlier == Cheaper What if we had Peer Review? ? ? ?

19. $152k, down from $368k 32, down from 194

20. Move the Feedback

21. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. Manifesto Principles - II

22. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. Manifesto Principles - II

23. Bus Number >= 2

24. Collective Code Ownership

25. Continuous attention to technical excellence and good design enhances agility. Manifesto Principles - III

26. Continuous attention to technical excellence and good design enhances agility. Manifesto Principles - III

27. The Ego Effect

29. if(“integrate”.equals( s )) Continuous Learning

30. Are the meetings necessary?

31. Can We Avoid:

32. Formal Inspections Michael Fagan, IBM, 1976

33. Fagan Phases = Meeting

38. 4%

39. Fagan Phases = Meeting

40. Code review without meetings?

41. Over-the-Shoulder Easy / Free Interruption No info Recorded Walk-through

42. Email Easy / Free No Interruption / Remote Conversation Tracking Info. Hard to Retrieve No End?

43. Pair Programming No Tools or Workflow Deep Thought Big Time Commitment No Info. Recorded Too Close

44. Tool-Assisted Review

45. Typical review process

46. Reviewers Identify Changes Package/Deliver Organize Communication Track Defects Audit Trail Reports Automatic Metrics Hapless Developer Version Control

47. Tool-Assisted Review Collection Communication Chronicling Install and Maintain Time or Money

48. Tools Code Collaborator Commercial Crucible Commercial Review Board Open-Source Rietveld Free/Hosted

49. What’s the most efficient use of time?

50. Cisco® MeetingPlace® Case Study 3,200,000 lines of code 2,500 reviews 50 developers 10 months San Diego, Bangalore, Budapest s

51. CodeReviewBook.com

52. 60-90 minutes max Time (minutes) Defects Found

53. Go slow: 200-500 LOC/hour

54. Not too much: 200-400 LOC

55. Author Preparation is ??? Good!

56. Checklists

57. Checklist for Checklists 7  2 (George Miller, 1952) No obvious stuff Nothing that can be automated Stuff that’s easy to forget EXAMPLE: Errors handled properly in all cases

58. Version Control: Before or after check-in?

59. But won’t people hate doing code reviews?

60. Start Slowly

61. Selected Code Only Stable branch Core modules/10 scariest files Unit tests

62. No Flaming

63. Review the code, not the coder Ask, Don’t Tell Don’t Accuse We All Make Mistakes

64. Careful Use of Metrics

65. We’re Agile - No Metrics!

66. Numbers, Numbers, Numbers LOC Time Defects Inspection and Defect Rates Defect Density

68. Defect rates for a reviewer are task-independent

69. The meaning of metrics depends on the goal of the review

70. Properly Adjusted, Code Review is Agile

71. Gregg Sporar Senior Product Manager [email_address] http://blog.smartbear.com http://twitter.com/smartbears