In the context of refactoring, you sometimes come across the term “bottom up approach”, which makes sense in a way that you change the smallest moving parts first when refactoring.
However I never heard of “top down refactoring” and can’t find any resources on the topic, so I was asking myself if it actually exists or if it’s an oxymoron.
Is there a formal definition of bottom up refactoring vs. top down refactoring?
I think top down aproach are more a re-design than a mere refactoring.
From my experience refactors are usualy somehow a re-organization of the existing code. Its a low scale re-design. So you get complexe features that already meet their proposals but are not flexible enough and hardly re-usable. And you split its feature into small subprocess. The best way to do so is as you pointed out, with bottom up aproach.
However if you are facing a deep change of these features and these changes have an important impact all over the project or atleast on a big portion of its business. In order words if changes are deep enough to make you re-design the way your code meets the business requirements, then the best way is to see the aproach from above. Going from to the global issue up to the specific way to solve it. Top down. Like drafts of what they should be. Not going into details. Once the strategy and the new design is set, you can go into details again with bottom up strategy fullfiling the core.
Look the peoblem from inside (b-u) or from outside (t-d) or alternate points of View till reach the solution.
I use top down aproach for prototypes or mock-ups. In this stage I set the high-lines. Then in dev phase I go into details. It also make easy to delegate tasks to juniors.
Top Down is when you take the whole problem and break it down into smaller and smaller problems until you get to the bottom where you have lots of actual implementation details.
Bottom Up is when you create lots of small, detailed building blocks that are generally useful and that can be assembled together to solve larger and larger problems.
Top down is useful for analyzing and understanding how a large problem can be broken down into areas of responsibility and produces the overall structure of a piece of software. One drawback is that it tends to produce task specific code at the bottom that is generally hard to reuse in other applications.
Bottom Up, on the other hand, is often the approach that library builders take. It is entirely focused on producing small components that are as generic and reusable as possible within their specific areas of utility.
When (re)designing a whole system both approaches are important. Initially the Top Down approach will give you a logical structure specific to the application. Once that has been achieved the Bottom Up approach can be applied where the low-level specifics are addressed. This could mean locating relevant libraries that are well matched for solving lower tier problems or embarking on an in-house library based solution.
The point being that the actual implementation code should be as reusable as possible. That way creating successive applications should get progressively cheaper. To that end the Top Down approach can only take you so far and at that point the Bottom Up approach fills in the gaps with something less specific to the current task but more useful to tasks in general.