Trying to figure out how we can improve the efficiency of our code reviews. Finding some interesting stuff on the web…
Like this article: Limit the checklist to 7±2 items. Automate the automate-able and let existing code review data drive the list of common mistakes.
Here is a list of articles, white-papers, and documentation around peer code review. Hmmm. Several resources, but not enough time to look at them all.
Some nice pointers here, but nothing game changing.
A good summary article here.
- Review fewer than 200-400 lines of code at a time
- Aim for less than 300-500 LOC/hour
- Not more than 60-90 minutes at a time
- Authors annotate prior to review
- Establish quantifiable goals and capture metrics to improve the process (I’m noticing a theme here)
- Checklists are good
- Verify that defects are fixed
- Managers must foster a good code review culture in which finding defects is viewed positively.
- Beware the “Big Brother” effect.
- The Ego Effect: Do at least some code review, even if you don’t have time to review it all.
- Lightweight-style code reviews are efficient, practical, and effective at finding bugs.
And here (and here) is an interesting take by Torvalds that Paul found.
- There will be bugs. Don’t aim for zero.
- “Same goes for ‘we should all just spend time looking at each others patches and trying to find bugs in them’. That’s not a solution, that’s a drug-induced dream you’re living in.”
Plan on talking with developers to brainstorm on it…
