What you need is to clarify the business logic instead of restructuring.

First, let me refer to this article.ArticleNot because this article is completely correct, but a very useful reminder for people who want to refactor. refactoring should be based on the business!

========================================================== ==========================================================

Recently, I met a former company colleague. He mentioned the projects I developed in that company a few years ago. He said the project has now become a "professional killer ". Basically, anyone who has been in touch with this "professional killer" project will eventually leave the company. If the company wantsProgramIf the number of members is greater than 0, the only way is to completely reconstruct the system in a few months.

I have two points to talk about. First, before I leave the company, the unit test coverage rate of the system has reached 85%, so don't blame me. Second, is such a large-scale reconstruction? There will certainly be problems.

Every system has at least one component that becomes an enemy of the people and fears everyone. It carries too many tasks, it has too many States, and too many other components call it. When it's time to pay off technical debt, everyone will look at this component. However, if you only have an incomplete understanding of this component and you put all your work down to completely refactor it, then your chances of success will be very small. This component is more complex and more terrible than you think.

How do you think this component has evolved into such an unfortunate state? Is it because the company has hired an idiot to increase complexity in the system? Or is the initial design of this component too abstract and its scope of responsibility constantly expanding due to changes in demand over the years? (Out of personal self-esteem, I would rather believe that this "professional killer" belongs to the latter ). In, this component turned into today's horrible state, all caused by some "kindness" of "smart people. If you decide to make a big restructuring, you actually owe another technical debt to future generations.

In order to truly completely repay this debt, you need to break down the complexity of this system. You need to spend time searching for all clients that call this component. You need to spend time communicating with your colleagues to understand the history of this component and how it is used. You need to simplify the surrounding environment of this component and see how it works. Every week, you need to spend more time to better understand the business of this component. As long as there is enough time span, you can finally clarify all the complicated problems.

In practice, what should I do with this problem? Instead of taking three months to complete the reconstruction, we should first clean up the system in one quarter. The last step is to rewrite it, but with three months of plan preparation, you have time to analyze and design. You have time to sort out your business.