In-depth understanding of how to refactor code from the case-refactoring plan

Project name a: a key project of a company that has been officially launched for several years. The company's business is distributed all over the world and many countries have offices or R & D departments. With the continuous development of the company, the business process is constantly improved and changed.

Technically, the project is based on the CS architecture and supports online and offline operations. For the online mode, data access is a direct connection 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.

Currently, the project code has reached more than 1 million lines, and the same group is responsible for project development and maintenance. Among them, there are 10 developers and designers, these 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 on the UI Layer in the previous code, 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 performing some change tasks, simple modifications often involve many bugs. This is because the project code is messy and the copied code is everywhere, as a result, the change analysis is difficult to be comprehensive.

3. the low degree of code reuse leads to a long development time for each version, and each version development leads to a sharp increase in the Code scale.

4. In terms of business, the project is mature. The company wants to productize the project and implement componentization internally (modules are divided based on business modules, and quickly combine and split the 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.

In each sub-module, it is divided according to the traditional three-tier model. However, the business data between layers is represented by the 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 innovative 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 the existing problems. We will implement the idealized things in the future .)

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!

 

Http://dev.yesky.com/172/11321672.shtml

In-depth understanding of how to refactor code from the case-refactoring plan