I keep hearing how wonderful code reviews are to help improve the quality of code. There is a lot of information about how code reviews can improve code design, reduce defects, and share knowledge. I have participated in a number of code reviews, and I can definitely say they have the potential to be a powerful tool. My problem with code reviews is not the concept, but the follow through.
I think it can be really easy to implement a code review process, but ultimately it takes discipline to make the process effective. Like any good idea it is all about execution. I believe there is a reason some are seeing true benefits from a code review while others are seeing very little in return.
Below are two lists of responsibilities for both the developer and the reviewer. Of course this is not a list to end all lists, but it is definitely a sound starting point. If your team can be disciplined to execute on these responsibilities you should start seeing consistent return from your code reviews.
Responsibilities of the reviewer:
- evaluate the code and not the developer
- understand the requirements and intent
- ask to see the tests
- review the design
- collaborate to find ways to make the code better
- be engaged
Responsibilities of the developer:
- Do not take feedback personally and be prepared to collaborate
- reduce the size and scope of the review by having frequent reviews
- communicate the requirements and intent
- being willing to talk about the “what” and the “why” you did something
- be willing to make adjustments based on feedback
- be engaged