I refuse to work in teams without a proper code review process - and you should too!
Tags: teams, processes, codequality
Published: 2019-05-20 11:51:33

---
title: I refuse to work in teams without a proper code review process - and you should too!
published: true
description: There are several reasons why you should not work in a team without having a good code review process in place. Let me show you some of them.
tags: teams, processes, codequality
---

When I'm doing client work as freelancer I refuse to work in teams without a proper code review process. I want to tell you the reasons but first of all let's have a look at my definition of what a "proper code review process" actually is:

- Every feature, bugfix, hotfix or whatever is developed on branches (feature, developer, … up to you). No code is ever directly pushed to the master branch!

- In fact, your main branch(es) should be protected and merging changes into master (develop, …) require at least one approval by one of your colleagues

- Everybody in the team (from trainee to lead) gets and regularly takes(!) time and is even encouraged to do code reviews

- Reviews are taken seriously by everyone involved! No thoughtless clicking of the "approve" button without actually having reviewed the code. If your chosen reviewer does not have any bandwidth now remind him to do that later or ask another colleague if it's urgent.

- Pull requests that still require review don't "pile up" because "there are more important things". It's okay to have a few pull requests open at the same time but you should not have 50 open PRs in a team of 5 developers. From my experience 2-3 open PRs per developer at the same time should be fine and still manageable to review properly but that of course depends a lot on the size of the PRs.

- Pull requests are kept short. 15-20 files in a React project should be the maximum for a PR. Sometimes you can't avoid that but please at least try it.

I refuse to have my code merged into master (and as a consequence sent into production afterwards) without review for several reasons:

1. Maintainability! 🍎 Code that looks super clear to me, might look super confusing to others. Reviews can (and usually do) help a lot here to make complex parts simpler.

2. Liability! 📜 If I commit a super obvious bug that for whatever reason is not covered by tests and it goes into production I am the *only* person responsible for that misfortune. Having it approved by someone else can split this responsibility in half (or even more). Especially when you're a contractor (like I am) who can be held liable for negligence, such a review can be crucial and literally save your butt one day. (I say can, not will!)

3. Documentation! 📋 I usually write a short but understandable description of what's happening in my PR. If later you (or anybody else) is unsure about something you might find the answer in old pull request descriptions if it's not explicitly mentioned in the docs/readme.

4. Sustainability! 🌿 A codebase where everybody can just commit unreviewed code carelessly usually looks exactly like that: like nobody cares. That's not sustainable and will inevitably end in a desaster eventually.

5. Risk reduction! 🛡 Sometimes you're working on a relatively complex feature mostly alone for several days. By having another person reviewing your code, this person inevitably gets an idea what this is all about. That can already reduce your bus factor tremendously.

6. Learning! 🎓 As a developer you can only grow by receiving and giving(!) feedback to code regularly. Code reviews are a great way to discuss alternative solutions and different approaches to the one you went with and let you suck free knowledge out of other people's brains.

Doing a good code review takes time. The best companies I've worked with had really "time consuming" review processes but it is time that is really well invested! The time you lose by being "slower" today is very likely saved by orders of magnitude in a long term codebase at a later point!