Agile Austin - Peer Code Review An Agile Process

3,688 views

Published on

Slides from Gregg Sporar's presentation on peer code review at the January 2010 meeting of Agile Austin. More information available here: http://blog.smartbear.com/the_smartbear_blog/2010/01/is-pair-programming-like-junior-high-sex.html.html

Published in: Technology

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

×