Interestingly enough, this question came up in a conversation related to a recent event: severe bug escaped into the wild causing embarrassing data loss. The bug was a regression that was introduced and not noticed during a code review. Regression suite failed to catch it as well. Naturally, we were trying to understand what we can do better. One of the questions was related to code reviews: could a more thorough review have prevented this?
To our surprise, we discovered that not everybody agrees on goals of a code review as well as on his/her right and responsibilities as a code reviewer.
So, I came up with these code review goals that are now posted in our office:
- Maintainability and best practices/coding guidelines
- DRY, Design patterns, Readability, Testability
- Test coverage
- Very important for both new features and bugs
- Evaluate exposure to missing tests
- Tests should highlight edge cases + happy paths
- Be able to take over the ownership
- Understand requirements, context, and code
Help the author become better
- Suggest alternative approaches, defend your decisions
Sign-off = Your Reputation on the Line