Nowadays it’s common that in a squad the developers of the same technology do code review of others. It’s an easy way of maintaining consistency in all the codebase and to keep other team members updated about new features that we are implementing.

If we are in a fast growing company, probably a startup, the delivery speed must be high so a developer will spend a lot of time reviewing code from others during the sprint. So it’s important how we do PRs (Pull Requests) or MRs (Merge Requests) if we want to optimize team delivery speed.

One easy solution to keep reviewing time as low as possible is having smaller PRs.

Why?

Let’s review why I think this is so important.

Smaller scope

If the scope is smaller, a developer trying to figure out what change is being merged will understand it much faster. Also, reviewing all the changes is much easier.

Easier to deploy

If we do CI/CD, we’ll be doing a lot of deploys during the day. If as a developer I’m able to deploy a smaller group of changes, I’ll be much more comfortable and confident with what I’m delivering.

Easier to check if it fails

If something fails, it’s much easier to detect the source when we have, say, 20 changed files instead of 500 changed files.

Give value sooner

Since we’ll be able to deploy smaller parts as soon as they are ready, we’ll be delivering value much sooner than if we wait until the end of the sprint when the full feature is ready.

How?

We’ve seen many benefits we can get from following this. But sometimes it seems not that easy; let’s review some techniques I follow.

Refactors before implementing the feature

If I’m working on a new feature and I detect a part of the code that needs to be refactored to ease the feature implementation, I’ll do it in a separate PR that reaches production before the full feature.

Doing that I feel more confident since in case I break something in that refactor I’ll notice sooner and in an isolated deployment.

Break down big features into chained PRs that are deployable

While I’m developing the feature, as soon as I have some part of the code that I think can be deployed without affecting the rest of the application, I’ll create a PR with it and merge it.

Sometimes that implies deploying code that is not really being used by any real user yet, but covered by a unit or acceptance test. That’s totally fine.

But it’s important not to introduce any code that is not under test coverage since that means it is dead code.

Break down already big branches

It can happen that I end up with a branch that is too big. That’s fine. What I’ll do is create a new branch from master and move some changes there that can be deployed earlier.

To do that, I use the branch tree comparison tool that IntelliJ, PHPStorm, and GoLand have available.