---
title: Code Review Best Practice by Trisha Gee
---

###### tags: `code review`

# Code Review Best Practice by Trisha Gee

{%youtube 3pth05Rgr8U %}

* Video: https://www.youtube.com/watch?v=3pth05Rgr8U
* Slides: https://speakerdeck.com/trishagee/code-review-best-practice
* More resources: https://trishagee.com/presentations/code_review_best_practice/

E' importante avere una **checklist condivisa** da seguire e una **definition of done**...

Don't spend time on thing that can be automated, e.g. code standards, code styles, formatting, etc

## Why?
Ask the team: **why are we doing code reviews?**

* to ensure code does what it's supposed to
* to ensure code is **understandable**
* to **share knowledge**
* to have conversations around the directions we want to move our code, on how to evolve our code

## When?
Quando fare la code review?
Il quando fare la code review dipende molto dal perché si fa la code review.
ad es se lo faccio per condividere la conoscenza non è necessario farla come "gateway review", prima di accettare la pull request ad es.

### when is the review complete?
**what is your definition of "review completed"?**

## Who reviews the code?
Who should be involved in the code review?

* be aware of bottlenecks and blockages putting just one senior person reviewing the code
* **juniors are great people to do code review**: they learn and ask great questions (why this?)
* have a rotating pool of reviewers

### who signs it off?
Who ultimately says "yes, it's good to go"?

* the author? a committee?
* who solves conflicts and blocks?

## Where?
Where is done the code review?

* Pairing => code review on steroids
* Mob reviewing in a conf room (aka zoom room)

Too much confrontational? let's sit together and see

## What?
What to look for in a code review?

It depends on the
* whys?
* whens?
* whos?
* wheres?


Human reviews should be limited to what cannot be automated!

To be able to know what to look for, you have to **understand the constraints of your application**. E.g. performance in a backoffice webapp vs performance in a trading system

If the goal is knowledge sharing, then you should look at what is the code doing and why, (_do I understand what it's happening?_).

When reviewing code when it's code-completed, at the end of the dev process:
* you cannot use it for having feedback on the design: the end of the dev is not the right time (too late)
* you should have a set of checks (there should be no surprises)

### How?
Let's see some mechanics

* automate all you can!!
* reviews should be small! and changes should be small (a few days of work...)
* should be clear WHO is doing the code review (who is responsible?)
* have a checklist of WHAT to look for (to fight "inconsistent feedback" anti-pattern)
* my take: avoid offline code reviews as much as possible. In other words: try to have in-person code reviews

As a reviewer:

* respond in a timely fashion!
* when doing a code review, have a clear idea of WHY, WHEN and WHAT
* be constructive in the comments
* be specific in the comments!
* leave praises on the code reviews!

When making changes:

* respond
* respond in a timely fashion
* resolve: **the goal of the code review is make sure the code is ready to go in production!**
* be clear of when code review is good to go

A good code review is one where the process is clear!

* why?
* when?
* who?
* where?
* what?
* how?