Should I refactor up or down the callstack?

Question

Should one make a code change by beginning to refactor at the "entry-point method" or the "inner-most method" of a call-stack?

A colleague and I were talking about a code change that would go through many application layers and touch a number of classes. The end goal was to assign a variable to a SQL table name at the data provider level. But the variable would have to be configured and touched by many other layers.

We figured out that we have opposite approaches to this type of refactor. I like to start at the entry point and trickle "down," and he prefers to make the final change first and then find usages of that innermost method and continue moving "up" the callstack.

What are the considerations between the two methods? What is most optimal and efficient?

Answer 1

The nature of layered architectures is that, if they're done properly, dependencies move in only one direction. For example, in this diagram...

Database --> ORM --> Business Logic --> Controller --> ViewModel --> View

...the Database should not have to know anything about the ORM, which should not have to know anything about the Business Logic Layer, which should not have to know anything about the Controller, and so forth.

It seems to me that your changes should occur from left to right, since the ORM depends on the database, and the BLL depends on the ORM, and so forth.

Answer 2

you are working with a typesafe language which is picky about method signatures and is able to verify them at compile-time, do the change on the bottom layer and work your way up.

The reason is that when you make a change to the database layer's interface, any code which uses that interface will throw a compiler error. Fixing these errors will require to change the interface of the calling code, which again causes errors in the next upper layer, and so on.

You just need to keep following the errors until your whole codebase is fixed.

But should you be working with a language which can only check method signatures (or even method existence) at runtime (like JavaScript), I would recommend to work in the opposite direction, because it's hard to determine all the places from which a given method will be called.