The Split Phase Refactoring
When we write code to solve a tricky problem, we often end up with methods that show us the whole journey of how we got to the solution: there is code to load data, followed by transformation logic intertwined with data clean-up hacks to prevent the creation of a report from exploding.
It is nothing wrong with writing code that way and to iterate until we reach the goal. The problem is that we keep everything in the order in which we initially wrote it. The developer who needs to fix a bug does not care if we found a missing default value at the beginning of the implementation or at the end. They much more prefer code that separates the different phases (load, clean-up, transform, report) and guides them towards the place where they should implement the fix.
