Pull Requests and Boy/Girl-Scouting

My biggest gripe with the PR/MR model is how much more slower code refactoring on the fly is.

Code refactoring to me is like cleaning house. You need to do it everyday, and you need to do it often and in small pieces, one at a time, and maintain a readable Git commit history when doing it.

So like the good boye in the picture, you do your refactoring, and then comes the time when you have to merge it into master, through a PR.

When you have small bits of refactoring changes…

For small, single line sensible changes (with no changes in logic) this itself is a waste of time when you have to step out from the current feature you are on, branch off master to apply the refactor, create a PR for it, and return to your feature branch. This process is tedious, if it’s a simple change.

When there is a lot more than that…

If I am refactoring code related to an entire feature, I would have multiple commits to logically separate the changes.

That might mean multiple PRs to keep the changeset in each PR small, readable and understandable.

A lot of manual work.

To add to this, due to the very nature of unmerged work, if some one else were working on the area of code where the refactoring was done (and still unmerged), then that might mean potential merge conflicts for me.

Of course, the last scenario is avoidable if the reviews happen in a timely manner — and if the classes and methods in your projects follow SRP well — but that is not always the case in all projects.

My personal take to teams is, if you are on a PR model, do it for the sake of getting another person’s opinion on what you’ve done and do not treat it as some sort of a “gate” to master. Be a bit more pragmatic about the practice, unless there is a regulatory restriction that is in your way. Use pair programming to your advantage here.

And I have heard from a senior member on one of my teams that a PR process is a learning tool, but I disagree, particularly if the team is experienced. I believe you don’t need a PR model for that, all that is needed is to frequently read — every morning, the commits that are made into the repository the previous day. You could also have team members present lunch-and-learn sessions at work to share knowledge between each others.

Suggested reading if you have a PR/MR model: https://hackernoon.com/the-art-of-pull-requests-6f0f099850f9 I tend to follow a lot of the practices there.