Code Review – how to make it extremely efficient

Why you need quality Code Review process

I hope that the code review process is established in your project. Otherwise, do not read this article until it is! This article is for developers, who regularly review the code and sincerely want to make this process more efficient and less time-consuming.

1. Create a code quality gate to filter out buggy, unreadable and inefficient code;
2. Spread the knowledge across developers;
3. Get a collective opinion about the implementation;
4. Keep the consistent source code style;

This is why most of the projects already have the code review process established.

But I bet you still often meet the code that makes you say:

“Who the hell wrote this? I’m surprised it really works…”

In most cases, the code review process is way less efficient than intended.

I want to share with you several code review techniques. Each of them can significantly increase the code quality level in your repository. Every time you review the code – you are looking at the code you and your team will work with and maintain in the future.

Code Review Best Practices

If you want you Code Review process to bring the best results — just follow these rules.

You must have a code review checklist

Yes, this is the Holy Grail of the successful code review. You need to have a list of requirements that are mandatory for each pull request. And the only way to make sure all of these requirements are checked by each reviewer — is to create a code review checklist.

What should it include? It should be a step-by-step instruction on what should be checked so that the reviewer doesn’t forget or miss something.

It can include whatever your teamconsiders important. Here’s an example of the code review checklist I regularly use:

✔️ Branch and commit names are correct
✔️️ Code is readable
✔️ Styleguides and naming conventions are followed
✔️ Folders / Files structure is reasonable
✔️ Code is structured well. No classes / functions should be broken down into smaller ones
✔️ Covered with tests
✔️ Documentation is created

Make your checklist a part of each pull request description and merge only when the reviewer fills it.

Do not make it unreasonably long. Remember to include only those items that your team considers mandatory.

Automate all possible checks

Now when your checklist is ready — look through each item in it and answer the question: “Can I automate this”?

Most probably most of the items in your checklist can be at least partially automated. Here is the list of recommended tasks to automate:

1. Automatically check branch and commit names;
2. Run linters to verify that the codestyle is followed (choose a linter here);
3. Run beautifier tool to format the code correctly (choose a code beautifier here);
4. Run code analysis tool to find inefficient algorythms, potential code smells or security issues (e,g, SonarQube or Codacy);
5. Run automated tests and programmaticaly check the test coverage;

When to run the automation task?

1. Pre-commit hook / pre-push Git hook. Ideal for the fastest tasks: linter, beautifier.
2. CI Pipeline (Jenkins, Teamcity). Can be executed when the PR is created. Best for the integrity checks and tests. Here you can run code analysis tool, verify the successful build of the app and run the tests here.

After you set up the automation pipeline — make it a reviewer. Let your pipeline approve the PRs before the human checks it. It’s impossible to overestimate how much time it saves for the further reviewers.

After the pipeline checked the PR you can just review the logic. You no more think whether this test works or are all the curly braces paired. You just focus on the logic.

Review the code manually

So now when all automated checks are passed you open the PR to review it:

Start with the ticket description

Every piece of code makes much more sense when you know why it is written. Read the ticket carefully and check where is the code that satisfies the requirements.

Always review the code in IDE or the special code review tools

Of course it is much faster to review the code in browser. But just try to checkout on the branch yourself, compare branches in IDE and start the review process there. You can see the files structure, go to references and see where the functions are declared. You can also use your favorite IDE extensions to support you.

Just trust me — code review in IDE is several times more efficient.

Review only the relatively small chunks

Familiar situation: you open the PR and see 276 files were changed. You quickly scroll through them, looking only through the main structure, and approve because it’s 7PM and you don’t want to waste few hours reviewing them.

Meet with your team and define the maximum size of the PRs all of you are ready to review. It’s much better to often review granular PRs than to rarely just scroll through the huge ones, letting the undesirable code pass through.

---

👋🏻 Thank you for your reading. I hope this article inspired you to improve your code review process. If you implement at least one of the above advices in your development cycle you will notice its pleasant effect immediately.

✅ Follow me so you don’t miss out the new articles!

💬 Your thoughts and ideas are very appreciated in the comments below