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 code base and to keep other team members updated about new features that we are implementing.

If we are in a fast growing company, probably an 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 go to review why I think this is so important.

Smaller scope

If the scope is smaller a developer that is trying to figure out what change is trying to get merged will understand it much faster. Also, reviewing all the changes it’s way easy to do.

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 be deploying smaller group of changes I’ll be 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 with we have let’s say 20 changed files instead of 500 change 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 that if we wait at the end of the sprint when the full feature it’s ready.

How?

We’ve seen many good things we can get from following this. But sometimes seems to be 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 separated PR that will get 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 in chained PRs that are deployable

While I’m developing the feature as soon 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 I’ll merge it.

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

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

Break down already big branches

Could happen that I ended up with a too big branch. That’s fine. What I’ll do is that I’ll create a new branch from master and I’ll move there some changes that could get deployed before.

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