How to Review Pull Requests 3x faster
Tags: codereview, codenewbie, github
Published: 2022-01-30 14:23:17

**How much time do you spend on average for reviewing a pull request - 3min, 10mins, or 30mins?**

Even experienced programmers spend between 10 mins to 30 mins on average to review a pull request from their colleagues on some project. 

Throughout various enterprise projects (Typescript, Python, Golang, Java), I reviewed more than 100 pull requests and learned to review a pull request 3x faster and more accurately, and then get even faster with automated tool's help.

## No.1: Use a pull request template

Have you ever thought the following in your heart?

**What changes are made and what are not?**

**Where are the relevant documentation for functional requirements, specifications, and designs?**

The solution to the above challenges is easy, but many newbie projects miss it.

**Use a pull request template!!**

It ensures that every pull request has the necessary information in sorted order.

At least, it's good to include the following points.

```
1. Description
2. A list of Changes
3. Future todos
4. Screenshots or movies
5. Test Cases and results
6. How to review your code
```

You can check [my repository](https://github.com/hiroyone/pull-request-template-example) for a complete pull request template.

## No.2: Don't review business logic but prepare a test for it

Have you seen the following comments?

`I tried your new feature on my local PC, but it did not work.`

or

`I checked your code, and the logic in line XX should be the opposite of the specification.`

That would be generous but also too much consuming to guarantee business logic by manually checking the coding counterpart.

For example, look at the following control flow.

```
if (condition1) {
  //  10 lines of code here
} else if (condition2) {
  //  20 lines of code here
} else if (condition3) {
  //  20 lines of code here
} else {
  //  20 lines of code here
}
```

To review the above code, you need to go back and forth between the pull request and documentation 3 or 4 times.

And the real problem of this code is not about the logic but many if/else statements.

Anyway, it is more efficient to use (automated) testings to assure functional qualities of your code.

The procedure is so simple.

```
1. Write test cases to a test sheet
2. Review if test cases are sufficient
3. Write corresponding test code
4. Run the test program in every pull request
```

There are many automated testing frameworks in every programming language and CI/CD tools in code hosting platforms. 

## No.3: Configure a linter and a formatter properly

Have you seen the review comments like the below?

`This variable should be a camelCase.`

or 

`This JSON object should be indented.`

Any project with comments like the above fails to introduce a syntax checker and a code formatter properly.

For instance, ESLint and Prettier are the de fact standard for javascript/typescript development. So it is important to configure eslintrc and prettierrc files properly.

Furthermore, it is also crucial not to allow exceptions without rationals. Think carefully about why a violated lint rule improves/secures your code, and your code could still be an exception.

**The above No.1, No.2, No.3 practices make pull request reviews 3x faster than not.**

It should take between 3 mins to 10 mins for a meaningful review.

You should only focus on:

1. Readability
2. Performance
3. Abstraction

A useful rule of thumb is to keep every file less than 200 lines in the repository.

**But how can you spend even less time for pull request review?**

There is an automated code quality review tool.

## No.4: Use Code Quality Review tool

A good Code Quality Review tool makes pull request reviews another 3x faster, so it is 10x from the beginning.

- [Code Climate](https://codeclimate.com/)
- [Codebeat](https://codebeat.co/)
- [SonarQube](https://www.sonarqube.org/)

I prefer to use Codebeat because it gives a sufficient static code analysis, rich CI/CD supports, a managed service. Moreover, it allows us to focus only on poor but easily fixable code on their Quick Wins panel.

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/922w24dc8j00avhbzhjh.png)

On the other hand, SonarQube is more configurable in-depth and would be helpful in the advanced project requirement.

I recommend two articles for detailed tool comparisons.

- [Comparison of Automated Code Review Tools: Codebeat, Codacy, Codeclimate and Scrutinizer](https://www.netguru.com/blog/comparison-automated-code-review-tools-codebeat-codacy-codeclimate-scrutinizer)
- [Continuous code quality and automated code review tools](https://medium.com/devgurus/continuous-code-quality-and-automated-code-review-tools-aa911dd1b263)

Thank you for reading, and good luck with your review!🙌