Share a real case of refactoring

Write in front

Think about why refactoring?

If there is no reason to say, it is recommended not to refactor easily.

Status of air ticket system a

Background of a system

Business: moved from Hangzhou to Beijing, as a re incubation project, want to be bigger and stronger. There is great competitive pressure in the industry. If you can't make achievements, the project will be killed.

Technically: for the old legacy system, a monomer modified on the basis of another system, the team has changed hands four times, and no one can be found who knows the system.

Relationship: Beijing company was newly established and got this project as a big project. It is also a project to set a benchmark.

An email I wrote at that time described the current situation of the system.

Pressure and choice of reconstruction

At that time, redo was the best way, but it was unrealistic.

Business party: you can't stop business, or you'll die

Developer: there are not many resources, and it will be greatly promoted after half a year.

You can only choose to refactor based on the old system.

How to promote the reconstruction of a system

A common conflict point is:

The business side thinks that system reconfiguration does not bring business value, and maybe there are some bugs, which is risky.

As soon as you say something else, they'll say "it works anyway".

For reconstruction, all parties have their own views and requirements. For the business party, the requirements are as follows:

For the product side:

For the developer:

Finally, all parties reached an agreement, but R & D must be the most stressful. Don't be afraid. While taking orders in such a crisis, you can make demands and set rules. (if these requirements are not put forward in the initial stage, it will not be so easy to meet them in the medium term.)

In line with this goal, the following requirements are put forward:

How to set reconstruction goals

Balance short-term and long-term interests

1. Phased

First reconstruct the search module, then order transaction and product inventory.

There are five main objectives of the search module:

Specific description of objectives:

2. Variable organization

Reconstruction process

Step 1: Planning

Determine the plan and transform step by step.

Start the project and pull together the ideas.

Step 2: clarify the business

Step 3: Architecture adjustment

Layered transformation and gradual docking.

In a demand cycle, the technical transformation will be released while completing the business requirements.

3.1 performance optimization

3.2 introduction standards

Learn from previous ESB experience, solve the complexity of docking and standardize the integration mode.

Different airlines have very different interfaces, different data structures and different data effectiveness.

The original external docking is seriously coupled with the business system, and the docking methods are also various. Take out a standard specification and make a set of ACS system to specifically connect with the interface of external airlines. Support better horizontal expansion and maintainability.

3.3 grayscale Publishing

Through gray release + feature switch, ensure reliable online.

First, the advance environment is launched and accessed in the office. Then online gray scale, internal IP access of the company. Then we will visit Hangzhou and Beijing. Finally, the national visit was completely liberalized.

3.4 monitoring, operation and maintenance

Realize a comprehensive operation and maintenance system to quickly find and deal with problems. Realize the online switch and debug mechanism to quickly locate the problem. Make automatic statistics and send e-mails for daily business data, so that everyone knows the business situation clearly.

Final effect:

The new system has perfect documents and advanced architecture. The code is less than 1 / 3 of that of the old system, and the performance is improved by 30 times.

(Note: the above case is the real reconstruction case of Mr. Qin Jinwei)