Refactoring a live system that is tightly coupled with improper data models and business logic in the front-end

Question

Scenario

This was a project that I once had to maintain. After reading Working Effectively with Legacy Code, I started to think how I would refactor this system in a live environment, if I had to (thankfully, I didn't).

The system was a legacy system without documentation and extremely tightly coupled. Database relationships were incorrectly modelled - i.e. objects that were meant to be many-to-one were mapped as one-to-one. Using "duplication" allowed for "pseudo-many-to-one" relationships. Business logic was stored as JavaScript solely on the front-end. Data was tightly coupled to Presentation data.

As an example, a Question object could not exist without a Table Cell object. The database had a table call "TableCell" to store inline CSS for each cell which was mapped one-to-one with a "Question" object.

The system was a horrendous mess and eventually lead to loss of data and a complete re-write in the end. In total the project was about 350K LOC.

As a side note, the reason why the system was re-written (or needed refactoring) was that it was to be exposed to the Internet, but we were able to modify the business logic using the Chrome Debugger to elevate roles, inject code, and execute all sorts of undesired functions.

Question

The book used examples where the logic was placed in the middle tier. However, what happens when the business logic is placed in the front-end? From my point of view the refactor process would have to go this way:

1. Refactor the front-end JavaScript to understand the business logic
2. Refactor the middle-tier to include validation
3. Refactor the database to decouple the data models
4. Migrate the data
5. Refactor the middle-tier to decouple the data models
6. Refactor the front-end to reflect the changes in the data models.

I have read Techniques to re-factor garbage and maintain sanity? and it is helpful, but it doesn't address the order in which refactoring should occur for this specific scenario. This process seems to add a lot of redundancy as the front-end and middle-tier are refactored twice in the live system.

• What is a more efficient way to refactor such a system while keeping the system live?

Answer 1

It's not about efficiency, it's about maintaining a working system. I like to compare refactoring to mountain climbing. You never remove the previous safety until the next one is in place. Yes, it's laborious. Yes, it feels like it takes longer, but the consequences of any mistakes are much smaller.

Also, you generally want to think about refactoring in terms of vertical slices. Do the minimum necessary to improve one small part throughout all tiers. For example, instead of tackling the entire database at once, pick one table or even one field and go through all six steps, then repeat for another table. You will learn things each time through that will make things easier on subsequent rounds, so make your feedback cycle as short as possible.

As a side effect, short cycles make it easier to get buy in from management. "Remember how much my changes sped up the invoice page? I want to do the same thing for the shopping cart, which should also make this new feature you want much quicker to add and more robust."

Answer 2

The scenario you are talking about (and Working Effectively with Legacy Code as well) probably doesn't allow you to follow such a long term plan. It's nice to know where you would like to get to, but typically in a live system most refactoring takes place in small steps in service of a particular bug fix or new feature.

The order of refactoring is therefore significantly determined by what business needs are high enough priority to work on. However, for each story you work on, you will have to decide how much refactoring to take on and how to approach it, and you may well be able to slip some non (directly) business driven refactoring in as well.

When you have a choice you would give top (but not absolute) priority to not breaking things, and second priority to getting pieces of the system under test. Both of these are higher priority than clean design, since you can clean up the design much more effectively if the system is under test.

For your specific example it's hard to predict in advance what order you would end up refactoring. My guess is that it would mostly work down from the UI - once the UI dealt with the middle tier via a more reasonable API you would probably separate the business logic farther from the database so that you could refactor the DB and migrate data. Hopefully by then the changed data model wouldn't be visible to the UI and wouldn't require UI changes.

But this process would probably be happening somewhat in parallel with different parts of the application, and in some of those cases might end up going in a different order.

Refactoring a live system is usually necessarily too much an opportunistic and bottom-up process to know in advance what the order will end up being.