The Goal

Just finished up watching this Implementing a strong code review Culture session by Derek Prior. The topic resonates with me. That's why I want to write a review for the session.

The Definition

We can say that Code Review Practice is The discipline of explaining your code to your peers. At the same time, it is kind of Asynchronous pairing.

The Research

Some peers may think that the purpose of code reviews is finding bugs. Well, sometimes it is true. However, according to the
Expectations, Outcomes, and Challenges of Modern Code Review research by Microsoft, chief benefits from code reviews are:

• Knowledge Transfer
• Increased Team Awareness
• Finding Better Solutions

How to Start or Rules of Engagement

There are two simple rules/best practices:

• As an author provide sufficient context
• As a reviewer use "Ask, Don’t Tell principle."

You've got me right "Ask, Don’t Tell." it is something opposite to well-known OOP principle called "Tell, don't ask.". Let me clarify by example. When You see this review comment
"Extract a service to reduce some of this duplication" it sounds more like a command. Remember, we want to ignite a communication here. Let's change it a bit - "What do you think about extracting a service to reduce some of this duplication ?". Sounds way better, isn't it? Here is just a small list of cliches how to start your communication:

• What do You think about ...?
• Did you consider ...?
• Can you clarify ...?

What Exactly To Review

It might be very context specific thing, actually. However, many teams stick to that list:

• Single Responsibility Principle
• Naming
• Complexity
• Test Coverage

The Benefits

Isn't it worth the price to have the benefits mentioned below? To me it sounds like a fantastic place to work:

• Better Code
• Better Developers/Happier Developers
• Team Ownership
• Healthy Debates

The Summary

If You were not able to convince your team to stick to code review culture and company does not want to change, just pack your shit and leave. It's that simple.