Peer code review is one of the most effective ways to find defects – but is it agile? Because agile teams loathe heavy process, code review practices can easily fail. However, lightweight peer code review aligns well with the central tenets of agile—keeping feedback close to the point of creation, increasing team velocity by finding defects faster, and improving collective code ownership through frequent collaboration. Gregg Sporar shares recent research on code review practices and describes an agile code review approach—how much time to spend, which code to review, how much code to review at a time, how to set goals, the value of annotation, and more. After comparing four styles of code review—pair programming, over-the-shoulder, email, and tool-assisted—Gregg gives specific advice for creating review checklists and dealing with the social effects of code review in an agile environment.

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

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