Substantial, complicated updates break software in large, complicated ways. Smaller, simpler changes break in smaller, simpler ways. It would help if you considered applying the “ship more, ship smaller” mindset. It’ applies the single responsibility principle to your pull requests. Avoiding large pull requests also means avoiding arduous code reviews and delayed deployments. Here are five patterns you can use to refactor your pull request strategy.
“Prefactor” Your Code
This idea is from Ben Ornstein on the Art of Product podcast. If there is any refactoring required, do it in a pull request separate from any functionality changes. It would be best to keep this branch as pure as a refactor as possible, with no functionality changes whatsoever.
Deploy Lonely Functions
You can create a PR that adds unused as of yet functions and classes. You can deploy this code with tests to ensure they do what you expect them to do. Creating PRs like this also helps you practice better software development practices, as it encourages you to avoid complex and intricate dependencies in your codebase.
Decouple Your Database Schema
Separate changes to your database schema into an independent pull request. This tactic helps you avoid scenarios where your code and your schema get out of sync. The larger and more complex your database gets, the more useful this becomes.
APIs Without A UI…
You can create pull requests to add unused internal API endpoints. I’d only recommend this for internal APIs for your frontend, not for public APIs, just in case.
…And UIs Without an API
On the other side of the coin, you can create unreachable UIs filled with mock data. You could show these to only the development team using feature flags or environment settings.
Why It Matters
By using these techniques, you can improve the deployment and flexibility of your development team. Flexibility is one of the best factors to optimize in both teams and code bases. Making more, smaller changes is more flexible than making fewer, smaller ones. It’ll force the team to get their CI/CD house in order so that they can deploy changes frequently. By breaking up PRs, you’ll end up with a more effective process and higher quality software.
Any Other Ideas?
What are some other ways you can break up your pull requests?
Top comments (0)