Practical techniques for maintaining legacy applications

Legacy applications are rarely as follows:

In this beautiful graph, through the definition good pipeline, makes the level and the module block division clear, the interaction facilitates. Modules can be moved, replaced, and easily added to support those important "features": scalability, scalability, maintainability ...

In reality, legacy applications are more likely to look like this:

If you are an unfortunate developer of a legacy application task, sometimes you feel like a mouse in a maze, and every time you turn on, there are more unexpected corners and bends, even death traps.

I've been in charge of maintaining this legacy application for over two years, and in this article I want to share my experience with how to realistically maintain a large legacy application.

I emphasize "pragmatic" because legacy applications may have many technical flaws, and it is not feasible to deal with all technical flaws technically and economically. Choosing the right way requires a strategy.

Spying on the enemy

A brief description of the large legacy application we are maintaining: