tags: code review

Code Review Best Practice by Trisha Gee

• 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?