Beitrag erstellt am: 23.08.23
In may daily work, the quality of PRs is a recurring issue - many PRs are quite big and do not follow the
Single-Responsibility Principle, i.e. the do way too much. This makes it hard to do a meaningful review and increases the chance for oversights.
Creating manageable PRs starts with small and focused commits! Each commit should again only do one thing. Ideally, a PR reviewer can use your commit history for the PR to understand each step of your work and therefore can easily grasp what the PR actually does.
But there is more!
Creating manageable PRs starts with small and focused commits! Each commit should again only do one thing. Ideally, a PR reviewer can use your commit history for the PR to understand each step of your work and therefore can easily grasp what the PR actually does.
But there is more!
Reversibility
In an ideal world, we would strictly separate PRs that cover structural changes from those that introduce behavioral
changes - we’d never mix them.
Why? Structural changes can usually be undone by a simple revert. This is not true for behavioral changes, i.e. changes that alter the observable behavior of the system.
Why? Structural changes can usually be undone by a simple revert. This is not true for behavioral changes, i.e. changes that alter the observable behavior of the system.
Refactor to Deeper Insight
Therefore: Start with structural changes to improve the quality of the code (Refactor to towards deeper insight). This
helps in better understanding what the code actually does. This is key for code that we want to move safely for example from a monolithic structure into a dedicated microservice
or plugable component without introducing inadvertent behavioral changes, and yes breaking working code is a behavioral change...
If we need to move code in order to understand the way it works or uncover hidden dependencies (e.g. partial classes or extension methods) and that move introduces a behavioral change, we revert that change as soon as we understand its effects. Remember: We don't want to mix structural and behavioral changes!
If we need to move code in order to understand the way it works or uncover hidden dependencies (e.g. partial classes or extension methods) and that move introduces a behavioral change, we revert that change as soon as we understand its effects. Remember: We don't want to mix structural and behavioral changes!
Make Change Easy...
Continue your refactorings with the clear aim of making the final change, i.e. moving the code out of the monolith, easy,
and then make that easy change (paraphrasing Kent Beck's famous "Make change easy, then make the easy change").
While this approach might seem a little involved, it is a good practice and a disciplined way to work towards a better code structure that improves our chances of working with an existing code base for many years to come.
While this approach might seem a little involved, it is a good practice and a disciplined way to work towards a better code structure that improves our chances of working with an existing code base for many years to come.