preface

Recently, I helped a team complete a system reconstruction and migration, and the team undertook an architecture reconstruction of an old system. So my recent experience with system-level refactoring is here.

Refactoring process

System level reconstruction for wide range, the difficulty is big, high risk, and it is hard to get an understanding of the management, become everybody shun work, and all sorts of old system are a rare opportunity to get the ashes, basic is tinkering, developers in a batch of another batch, eventually become a big mud was an unavoidable spherical architecture, to overthrow the redo.

Project analysis

Before you start, analyze the need for refactoring with your team. Generally speaking, reasons for refactoring are as follows: 1. Legacy systems that cannot be maintained; 2. The technical system used by the system is seriously out of touch with The Times, and there are not enough personnel to provide technical support. 3. The technology used cannot meet the business requirements. 4. The technology used cannot meet the new performance requirements of the system. Another important thing to do is estimate the amount of refactoring, which is a concern of every management, because refactoring is paid.

Technology selection

Since system-level reconstruction often cannot avoid the upgrading of technology, it also involves the problem of technology selection. In general, selection should be carried out according to the actual situation. The actual situation mainly includes three factors: 1. Business demand and potential demand After all, the project is carried out for business, and the significance of deviating from the original reconstruction is out of the question. 2. Team reconstruction is to be implemented by the team, and the reconstructed project is also to be operated and maintained by the team. The reconstruction selected a technology that no one in the team knows, so either they are ready to dig holes and run away, or they have no choice, so the choice of technology should be based on the actual situation of the development team. 3. There is no need to go into details about technological development. If it is in line with the trend of The Times, it will be necessary to reconstruct or even start all over again after a period of time.

Workload estimation and planning

Once the technology is finalized, it is essential to assemble the team for a more detailed workload estimate, develop a development plan, and then report it to management.

Preliminary migration

Since it is the reconstruction of the system level can’t avoid the adjustment on the system architecture and framework, this process is best done by a person, at least the construction of the complete the whole frame, and at the same time to find a most representative module refactoring, in the process of reconstruction is to reconstruct the scope of the standard after the refactoring agreed, after the completion of the right can be used as a reference example for junior developers. The most important points in this process are: 1. 2. Examples of each layer; 3. Establish uniform standards.

collaboration

The next step is for the whole team to start refactoring, check progress against the development plan, and review the quality of the refactored project with the testers. Don’t forget about testing during the refactoring process. Testing provides a safety net for refactoring, which can save a lot of time and effort.

acceptance

When it’s done, of course, give management a demonstration and provide resources for refactoring, preferably where we can do better after refactoring, such as how quickly we can respond to user needs, such as how much more reliable we are. This can dramatically change management’s attitude towards refactoring. Rather than expecting management to understand the technology, translate problems in the technology area into metrics they care about.

Pay attention to the point

The lure of control

Refactoring is also hierarchical, do not blindly optimize, system-level refactoring is mainly concerned with the replacement of the technical system, the upgrade of the core framework or the adjustment of the architecture, rather than how many methods have been renamed. It is necessary to focus on the important things and do one thing at a time. You can write down all the problems you find, and then you can do a little refactoring to focus on cleaning up the technical debt.

Resist the lure of technology

There is no best only appropriate, while selecting a technology must be combined with business requirements and the actual situation of the development team, avoid by all means is too pursuit of new technology, in time to switch from the new technology is to test and demonstrate through small projects, and give team a certain amount of time to buffer, and can be developed gradually in formal project, otherwise new technologies will only cause confusion.

Everything is business oriented

In the company, everything is business-oriented. Projects, especially large-scale projects, are not the place for technical research. Everything should create higher value for users and the company.