Peer Code Review An Agile Process

8,150
-1

Published on

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.

Published in: Technology
1 Comment
16 Likes
Statistics
Notes
  • More info. available here: http://blog.smartbear.com/the_smartbear_blog/2009/11/peer-code-review-an-agile-process.html
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
No Downloads
Views
Total Views
8,150
On Slideshare
0
From Embeds
0
Number of Embeds
5
Actions
Shares
0
Downloads
0
Comments
1
Likes
16
Embeds 0
No embeds

No notes for slide

Peer Code Review An Agile Process

  1. 1. Peer Code Review: An Agile Process
  2. 2. Gregg Sporar Senior Product Manager [email_address] http://blog.smartbear.com http://twitter.com/smartbears
  3. 3. Code Collaborator codecollaborator.com
  4. 7. But is code review really Agile?
  5. 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
  6. 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
  7. 10. Working software is the primary measure of progress. Manifesto Principles - I
  8. 11. Working software is the primary measure of progress. Manifesto Principles - I
  9. 12. <ul><li>Requirements </li></ul><ul><li>Design </li></ul><ul><li>Architecture </li></ul>
  10. 13. <ul><li>Requirements </li></ul><ul><li>Design </li></ul><ul><li>Architecture </li></ul><ul><li>Code </li></ul><ul><li>Discussion </li></ul><ul><li>Review </li></ul><ul><li>Review </li></ul>Where many of the bugs come from (void)0
  11. 14. Professional Writers Have Editors
  12. 16. Spell Czech: Good, butt knot enough
  13. 17. ROI: The Experiment
  14. 18. Rule of Bug: Earlier == Cheaper What if we had Peer Review? ? ? ?
  15. 19. $152k, down from $368k 32, down from 194
  16. 20. Move the Feedback
  17. 21. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. Manifesto Principles - II
  18. 22. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. Manifesto Principles - II
  19. 23. Bus Number >= 2
  20. 24. Collective Code Ownership
  21. 25. Continuous attention to technical excellence and good design enhances agility. Manifesto Principles - III
  22. 26. Continuous attention to technical excellence and good design enhances agility. Manifesto Principles - III
  23. 27. The Ego Effect
  24. 29. if(“integrate”.equals( s )) Continuous Learning
  25. 30. Are the meetings necessary?
  26. 31. Can We Avoid:
  27. 32. Formal Inspections Michael Fagan, IBM, 1976
  28. 33. Fagan Phases = Meeting
  29. 38. 4%
  30. 39. Fagan Phases = Meeting
  31. 40. Code review without meetings?
  32. 41. Over-the-Shoulder Easy / Free Interruption No info Recorded Walk-through
  33. 42. Email Easy / Free No Interruption / Remote Conversation Tracking Info. Hard to Retrieve No End?
  34. 43. Pair Programming No Tools or Workflow Deep Thought Big Time Commitment No Info. Recorded Too Close
  35. 44. Tool-Assisted Review
  36. 45. Typical review process
  37. 46. Reviewers Identify Changes Package/Deliver Organize Communication Track Defects Audit Trail Reports Automatic Metrics Hapless Developer Version Control
  38. 47. Tool-Assisted Review Collection Communication Chronicling Install and Maintain Time or Money
  39. 48. Tools Code Collaborator Commercial Crucible Commercial Review Board Open-Source Rietveld Free/Hosted
  40. 49. What’s the most efficient use of time?
  41. 50. Cisco® MeetingPlace® Case Study 3,200,000 lines of code 2,500 reviews 50 developers 10 months San Diego, Bangalore, Budapest s
  42. 51. CodeReviewBook.com
  43. 52. 60-90 minutes max Time (minutes) Defects Found
  44. 53. Go slow: 200-500 LOC/hour
  45. 54. Not too much: 200-400 LOC
  46. 55. Author Preparation is ??? Good!
  47. 56. Checklists
  48. 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
  49. 58. Version Control: Before or after check-in?
  50. 59. But won’t people hate doing code reviews?
  51. 60. Start Slowly
  52. 61. Selected Code Only Stable branch Core modules/10 scariest files Unit tests
  53. 62. No Flaming
  54. 63. Review the code, not the coder Ask, Don’t Tell Don’t Accuse We All Make Mistakes
  55. 64. Careful Use of Metrics
  56. 65. We’re Agile - No Metrics!
  57. 66. Numbers, Numbers, Numbers LOC Time Defects Inspection and Defect Rates Defect Density
  58. 68. Defect rates for a reviewer are task-independent
  59. 69. The meaning of metrics depends on the goal of the review
  60. 70. Properly Adjusted, Code Review is Agile
  61. 71. Gregg Sporar Senior Product Manager [email_address] http://blog.smartbear.com http://twitter.com/smartbears

×