How to refactor code-refactoring plan

The previous article has already elaborated on the ideas and methods of reconstruction. Here we will mainly discuss the reconstruction plan mentioned in the next section.

First, understand an old project to be restructured

Project name A A key project of a company has been officially launched and run for several years. The company's business is distributed all over the world and many countries have offices or R & D departments. AndWith the continuous development of the company, business processes are constantly improving and changing.

technically, the project is CS architecture, support online and offline two ways of operation, for online, data access is directly connected to the Oracle database on the server, offline data access is a local access database. For local databases, the system provides WebService to synchronize local data.

the current project Code has reached more than 1 million lines, the same group is responsible for project development and maintenance. There are 10 developers and designers, which are the basic conditions of the project.

project problems:

1. the maintenance workload is huge, which takes about 40% of the time, mainly because of poor usability, however, because too much logic is put in the previous code on the UI layer, in the case of complicated business and complex interfaces, you cannot modify them, which leads to the failure to improve ease of use.

2. It is difficult to reduce development bugs, especially when you do some change tasks, simple modifications often involve many bugs. This is because the project code is messy and the copied code is everywhere, which makes it difficult to complete the change analysis.

3. Low code reusability, resulting in a long development time for each version, and, each version development leads to a surge in code size.

4. In terms of business, the project is mature, and the company wants to productize the project, in addition, it implements the internal componentization (dividing modules based on business modules, and quickly combining and splitting modules as a piece of wood) architecture.

Existing architecture:

The project is divided into several sub-modules based on the business architecture. The following three modules are extracted, and the relationships between modules are also displayed.

Each sub-module is divided according to the traditional three-tier model, but the business data between layers is represented Datatable As the core.

After learning about the above, I don't know what you think? For me, this process is depressing now. It took me three months to come up with the final reconstruction plan from the start of the project!

1. Existing Problems, existing architecture, reconstruction time (one and a half months of development), and project risks have been comprehensively considered to create a new architecture.

(After seeing the figure above, some people may be unable to sit down and feel very ordinary. There is no advanced or new things, and even the basic design principles are not consistent, why not add a design pattern, such as using interface isolation between layers and using the factory pattern for data operation classes? In fact, I have never thought about this. The reason for removing this pattern is simple:Do not idealize the old project during initial reconstruction. The primary purpose of the old project is to solve existing problems. We will implement the idealized things in the future continuous reconstruction.)

2. If you select the restructured code, more than 1 million of the Code cannot be reconstructed within one and a half months. Therefore, it is very important to select the Code. In the above three modules, the sales module has the highest degree of use, where the user's problem feedback accounts for about 80%, and the code size is in the average stage. Based on these considerations, this part is used for reconstruction. What about other modules ?! When there is a need to change the module in the later stage, adopt a new architecture for the change content to achieve the goal step by step.

3. The UI Layer of the selection module allows Ba, UI engineers and users to redesign the interface process.

4. Develop detailed execution steps for code changes within the module. For example, add the object attributes and related methods in the class from the business layer, and then use the attributes to remove the datatable, finally, we need to extract the business rules at the UI Layer, clarify the degree of dependencies between jobs, and make serial and parallel tasks. For example, the above steps require serial, the refactoring of basic component modules can be parallel. This ensures that you have good control over the entire refactoring process.

5. The next step is the substantive encoding phase. Note that it is best to arrange two designers to check the modified Code every day to ensure that today's code will not be restructured tomorrow.

 

In this way, after a whole hard work for a team for a month, the reconstruction was finally completed! Although there are still many problems in the current Code, at least we have eliminated the problem that has been plagued, and there may be new problems. To avoid this situation, introduced the agile development process-continuous Refactoring for each version!