Pair programming replacing peer reviews is a myth in the same way that “agile projects have no documentation”.
From my experience peer reviews continue to hold a vital place in agile development and software craftsmanship. Unfortunately they are often misunderstood or misapplied.
“Humanizing Peer Reviews” by Karl Wiegers is the best primer I’ve read so far on peer reviews so I’m not going to duplicate Karl’s efforts – I strongly recommend a thorough read. In fact, print a copy and give one to every member of your delivery team to read and discuss.
Like everything else in modern software development, peer reviews are a collaborative team learning experience. Reviewing code properly means both the reviewer and reviewee walk away having learned something and improved their craft.
With code reviews; beyond reviewing for functional correctness, (the simplest, most obvious and potentially quickest part of a review) there’s a selection of considerations I expect reviewers to look for. (There are plenty more).
- No code without tests
- Good variable naming
- Correct use of classes and interfaces
- Small methods
- Adherence to standards and conventions
- Style consistency across the team
- Good test coverage from small tests
- Test code follows the same quality standards as production code
- Tests describe expected behaviours
- All tests pass
- Evidence of some test preparation to consider boundary cases, failure modes and exceptions
- Clear exception handing, failure modes and explicit boundaries
- Sensible error messages
- Code smells
- Performance risks or tuning opportunities
- Security or other “ility” issues.
- Opportunities to learn new tricks
- New good practices & patterns
- Functional correctness
Once you have cultural acceptance on the breadth of technical peer reviews develop your own checklist that everyone supports and remember the goal of a review is to share improvement opportunities, not for lazy coders to have someone else find their bugs for them or for staff to step on each other.
If you think peer review of code is problematic for your teams, I guarantee that document peer reviews will be a whole lot worse! – see part 2.