Where do we start refactoring a large method?
We see a large method and decide to refactor.
There is so much to nip away at.
Where do we start?
Has this happened to you? It is not only difficult picking a starting point, but if we pick a less than ideal place to start, the abstractions we end up developing may be no better.
Sandro Mancuso suggests we start with statements nested most deeply within our code.
The deepest branches gives us small, localised problems to solve where there are fewer dependencies to deal with. It is also likely that the deepest branches will be expressing details that don’t belong in the method, i.e. details that violate Uncle Bob’s ‘one Level of abstraction per method’ rule. As we nip away at those details, patterns that express the methods true intent should emerge. Once we start seeing those patterns, we can come up with better abstractions.
Sandro demonstrates the technique in the following video:
Relevant
-
RefactoringRabbitHole
Code can never be perfect. So when we’re refactoring, we must call good enough at some point. When we forget to call good enough, we’re falling down the metaphorical rabbit...
Recent posts
-
A worked example of Value-Stream Mapping
Value-stream maps can be daunting at first glance like these maps on Google Images. ValueTech (a made-up software company for the purpose of our example) thought so too until they...
-
Test pyramid and ice-cream cone
The test ice-cream cone is a strategic anti-pattern. It indicates excessive reliance on expensive and flaky forms of testing, such as manual and end-to-end, especially for components that could otherwise...
-
Notes on Value-Stream Mapping
A value stream is the sequence of activities required to design, produce, and deliver a good or service to a customer. – Value Stream Mapping by Karen Martin and Mike...