2

If you have a big legacy application (big ball of mud), lets call it MudApp.

If you then create a new application to make us of new technology and to make a new good looking frontend because that was impossible in the MudApp. This new application is supposed to the fresh one and with only the most important features of the MudApp. Lets call it MobileApp.

Some features is really difficult to implement in the MobileApp with identical functionality as in the MudApp so the solution has been to just make a request (via API, SOAP or whatever) from MobileApp to MudApp and let the MudApp do all the work. Some other features is written directly inside the MobileApp.

My first thought is that this is bad with to much coupling between them etc. But I can not really make an argument for why it's bad.

So my question is:

Is this bad or good? And why?

Note 1: the applications is sharing database (which for some is bad practice, but in this case I think it's fine because it would be to much work syncing to another database and so on.)

Note 2: The reason for the question is because the MobileApp is supposed to be further developed. Some features will be added and some removed. So I'm trying to figure out if the NEW MobileApp should make us of the current MobileApp (Took approx. 2-4 month to write) or just start over on a clean sheet

emajl
  • 59

2 Answers2

5

Surface Area

The problem is that any change now requires consulting two or more "separate" code bases using different styles, conventions, frameworks, and perhaps even languages, paradigms, or platforms.

The surface area that must be explored is larger, and necessarily includes the dark, and dank area inhabited by the decaying mud ball™.

Worse some changes require work in both the old and new world. This is seriously limiting. Either you must:

  • envision two distinct solutions, and a clean mapping between them.
  • or implement a single common solution which suffers the worst constraints of both the new and old world with none of their unique benefits.

In neither case are you being setup for success. Just more misery...

Clean mappings are Hard as anyone who has had to massage data from one database to another well knows. Which is made worse by the fact that the best solutions in the new and old world will probably have incompatible data models.

The single common solution means that not only are you writing bad code, you are writing code fundamentally worse than what was present in the old world. To top it off, if you ever sever the link to the old world, you are already stuck with this tragic implementation. If by a miracle the implementation is actually mildly okay or actually good code then you have a maverick genius and the fates have smiled upon you - just don't rely on it to be true for the next Code Change™.

Coupling

This is why the Coupling is so bad. Its not that you have a shared database, or shared APIs. Its that you have two different paradigms of implementation duking it out without a good boundary between the two keeping the peace.

If you do happen to have a decent boundary between the two, its hard to maintain. Largely because the two code bases co-habitat quite closely: sharing common data, data-structures, and are attempting to solve the same problem.

You can envisage them as two large stars slowly eating each other as their close proximity allows their gravity to ripe at the other one.

Anti-Corruption Layer

An anti corruption layer is a good start. Its like a microservice (even if its just a dll) that stands as a guardian of the integrity of shared data structures. Usually it protects a database, but you could have similar guardians responsible for shared communication streams. Their goal is to ensure that neither program puts the data-structures into a bad state due to bad code, asynchronous behaviours, or luck.

Tight Modules

Start enforcing module boundaries. It might be ugly on the inside, but a tight module is also a replaceable module. No code from the new or old world is to directly access the implementation (aside from the "entry" class).

Module Level Tests

Also advantageously, a tight module is much easier to test, and tests improve the quality of life for you when dealing with legacy code, even if its written in the new world.

Kain0_0
  • 16,561
1

Prepare to become yet another team who realizes the very-hard way that "it cannot be done." You cannot "screen scrape" from the existing app. You must create new interfaces within it – interfaces which the legacy language never contemplated and therefore does not at all support. The reality is that you are facing re-implementation.

I've spent a couple decades now, teaching this lesson to one company after another after another.

Mike Robinson
  • 1,821