I enjoy doing code reviews with my colleagues. But code reviews may also be unpleasant because of pressure and blame game within a team. With the right team's attitude, code review is a perfect way to share knowledge, get confident working with a codebase, and mentor developers.
Of course, code review doesn't have to be a place for an unproductive casual chat and long discussions. After all, we want to ship quality code as soon as possible. But having a learning environment should help increase the bus factor in the long run. Here are some tips on how to make code review a productive learning activity:
- It doesn't have to be one-way communication. The author should begin discussions whenever they're not sure about their code decisions.
- The reviewer should avoid comments without explanations unless they are clear from the context. Blindly following the reviewer's directions doesn't help the author learning and growing.
- Whenever possible, the reviewer should give more context to the author: business logic and code design considerations.
- When something isn't clear, the reviewer should ask questions. It's not a rare scenario when one skips code they don't understand and assumes the author does the right thing, leading to future problems.
- The reviewer may provide positive feedback when learning something new from the author or liking their solution
- Arguing about code style and other small details is a waste of time. The communication during code review should be productive for both sides. There are tools to check and fix the code style automatically.