Agile Austin - Peer Code Review – An Agile Process

At last night's Agile Austin meeting, Gregg Sporar gave an excellent talk on Peer Code Reviews to seventy attendees. Here are a few of my cryptic notes:

1. Professional writers have editors, why shouldn't coders? In fact, in the US we are blessed with twice as many professional editors as writers.
   
2. We need to move the feedback closer to origin when writing code. The earlier the code is peer reviewed the better. Should code be reviewed before being checked-in?
   
3. One of our Agile principles is Collective Code Ownership. Peer reviews aids this process by helping everyone understand the code.
   
4. If coders know their code will be reviewed they code better.
   
5. Peer reviews help everyone learn new techniques for programming.
   
6. Michael Fagan, the founding father of code reviews encouraged lots of meetings. Is roi there for lots of meetings? Only 4% of bugs are found in meetings.
   
7. Types of Code Reviews:
   
   
   
   1. Over the shoulder code review. Just grab a friend and have them look over your shoulder at your code.
      
   2. email
      
   3. pair programming
      
   4. Automated tools
      
   
   
8. How long to review code. Studies show most bugs found in 60-90 minutes. On average 1 bug per 10 min.
   
9. How many lines of code to review? 200 loc per hour seems to be the sweet spot.
   
10. Regarding checklists: Don't put too many items in a checklist. 5-9. Error handling would be a good item for a checklist.
    
11. One way to review code is to only review unit tests to make sure they are thorough, and then the code should be fine.
    
12. A few suggestions for not letting the reviews get to heated: Remember it's the tone that counts. Also "Ask don't tell", (e.g., Why did you use this API?)
    
13. Smartbear offers a free book at Codereviewbook.com
    
14. Gregg blogs at Blog.smartbear.com.