In other words, a long time ago, at least before it became independent, it was scattered in several systems, providing some support for the related systems within the auto finance line in business scenarios, such as obtaining financial solutions, checking expense rules, and trial calculation of financial solutions. However, with each iteration of requirements, not only the developers suffered, but also our testers. More importantly, the boss couldn’t accept why a small change in demand required so long research and development hours. In fact, I couldn’t accept it either, because AT that time I just started to take charge of the financial product module (there was no system service yet). I realized the urgency of restructuring and the importance of restructuring in the long run. Thanks to the trust and support of my boss, I started a new journey with the determination to restructure financial products and a new team.

[Note] : The whole article totals more than 5000 words. It is not easy to code words on the mobile phone during the whole journey of Beijing (Shunyi – Dawanglu) subway. In addition, it has been retouched many times. Please forgive me for my poor writing. Thank you readers can really read carefully, I believe you have a lot of feelings and experience.

Car finance past life album serial series, follow wechat public account [Autumn night without frost]

Car finance | financial product center of incarnations

Financial | car GPS incarnations of the audit system

Car financial | basic data platform of incarnations

Car incarnations of financial center | contract system

Car financial | financial product rules engine incarnations (last)

Car financial | financial product rules engine incarnations (medium)

Car financial | financial product rules engine incarnations (next)

Car financial | I M in the two years

takeaway

In my opinion, the status and value of financial product center in auto finance lies in providing different capital parties and regional operation cities, and providing differentiated and personalized loan and financial solutions for different customer groups with auto loan intention.

From the perspective of system architecture design, the financial product platform provides product operators to assist the company in the implementation and implementation of different operational decisions made by different investors and financial schemes. For the auto finance business line system and services to provide capital access, financial products trial calculation and other business scenarios support.

The significance of restructuring is to clarify the role of the financial product center, improve the operation efficiency of product operators, provide stable and scalable architecture services for business lines, quickly meet the company’s business needs, shorten the overall RESEARCH and development cycle, and improve the efficiency of project research and development.

Refactoring is not to be landed at the beginning, but to constantly summarize experience and practice truth in the process of continuous requirements iteration and system upgrade. The real value of reconstruction is to make quantitative change cause qualitative change, make our system service more adapt to the needs of business trend development, make our system service more in line with the overall architecture thought, make our system service more flexible scalability and scalability.

First, the eve of refactoring

Before the reconstruction, there was no independent application system for financial products, and the function maintenance for product operation was a relatively old and bloated system based on SpringMVC+Hibernate+JSP architecture in the company. For the receiving system and the audit system, it is to deal with the financial plan business logic respectively, sharing the same database, you query your data, I modify my data, each for their own business, each for its own.

In addition, when I came into financial products, there were a dozen MySQL stored procedures (if you’re crazy, what’s the age, and this stuff) to support the relevant business scenarios. By the way, it was the beginning of 2018 and I started in September 2017). It resulted in each iteration of requirements (such as matching capital side, financial scheme adjustment, before and after rule adjustment, etc.), and faced with multiple systems requiring code logic changes. However, in fact, these two systems are maintained by two different teams. As long as the adjustment of financial plan related requirements is involved, both systems need to be researched and developed. As the saying goes, “One should not be less, and it is impossible to run away. You run, I run, who needs to do.” .

It seems that it is just business logic adjustment, but each application system needs to adjust the code logic more or less. Since financial products involve different business logic cases, this causes the complexity of their code, and the maintainability is very poor. Not a Java engineer can simply adjust the complete logic without loopholes, endless. Not only does it bring complexity to the test phase, but it also brings in-line instability.

The boss once said that according to the plan, more capital needs to be connected in that year, and the demand will keep coming, so as not to take up repeated research and development time again. At the same time, the boss thought it was incredible why financial products needed such a long period of research and development to get online. We knew that the boss could not forgive this kind of situation again and again.

In addition, there are dozens of MySQL stored procedures, which may seem like a small amount of code, but many of them are thousands of code, and a lot of case WHEN and ifnull keep popping up as you read the code. Long pages of code are not only difficult to read, but also difficult to tweak logic and troubleshoot problems. Although I have worked on Oracle PL/SQL programming for several years, it is far from design and code tracking. Frankly speaking, the Internet uses MYSQL to develop stored procedures, and disaster will make you doubt your life at some point, like falling into the abyss.

Once there was a case involving a prior rule adjustment of the capital, the test environment passed normally. Online, we put the stored procedure SQL script, through the DBA online execution, compilation passed normally. However, in online regression testing, when testing the pre-rule checking scenario, the Java server calls the stored procedure through Hibernate and catches an exception. You don’t know the exact exception information, and you can’t cry (with whom, secretly) if you want to.

There is no quick solution to this problem, we are online in the evening, testing blocked in this link. At a critical moment, we communicated a compatibility solution with the product. We restored the backup SQL script of the original stored procedure, and then added the logical test to the rules after the audit process of the audit system. Although the process lagged behind, it still ensured the effectiveness of the rule test. The reason why the post rules can be easily adjusted is that the audit system is implemented based on Java language hard coding (a lot of if condition judgment), which is certainly easy for our server development and troubleshooting.

Based on the above background and predicament, we could not make up our minds and put forward the plan and goal of reconstructing the Financial products Center, which started our team’s plan of reconstructing financial products and wrote our wonderful story.

Second, the process of reconstruction

It was a hard journey, but it was an unforgettable journey, and not just for me, but for the people who worked on the project.” The success of one person is not true success, the success of leading everyone is true success.

2.1. Set goals

Through research and analysis, we formulate the overall project goal: to create financial products center, to solve the current pain points of the project, the car financial business line stability of other systems offer the same service (you don’t have to develop after several system, we provide the interface service, can satisfy the current business scenario support, once and for all, WBH). At the same time, our team needs to meet the normal demand iteration at the present stage and ensure the normal launch of the demand as scheduled, so that we need to invest in the project reconstruction in a shorter time.

2.2. Break down goals

In order to show the results of reconstruction to the boss in the shortest time, shorten the reconstruction cycle and minimize the impact on the line, as the general director of the project reconstruction, I carefully divided the big goal into three stages to achieve:

  • In the first stage, complete the reconstruction of the financial product platform (for the use of product operators), migrate the function menu of the original system to a new domain name platform, realize the separation of business modules from the old system, independently deploy system functions, and lay a foundation for the subsequent function optimization and continuous upgrade of the platform.

  • Two stage build a financial product service centre (for car finance related lines of business system interface services such as providing financial solutions trial), provide financial products trial, foreign financial plan, inspection main functions such as cost rules, docking system related to the business scenario support, implement a financial product team to complete the follow-up demand iteration and service upgrade, Shorten the research and development cycle, improve the system scalability and flexibility.

  • In the third stage, the MySQL database of the Financial Products Center was split, and the database instance of the Financial Products Center was split from the original system. The independent deployment and maintenance of service provision and data storage were truly realized, and the coupling dependence on the original system was cancelled.

In these three stages, progress is made step by step, and the overall goal is finally achieved. In addition, the transformation of stored procedures was also promoted in parallel, and one by one came to an end. (Here I would like to thank Xiao Zhao, a new member of the team, and Xiao Jia, who supported all the stored procedure test research and development and finally went online.)

2.3. General idea

We do not expect to eat one big mouthful, but one step at a time, and finally reap the fruits of our victory.

This is the basic idea of our overall strategy. Our basic tenet is that “every small goal should be achieved on time and every small task should be completed beautifully”.

Is what is meant by “a” on schedule, we split out the milestones of the goal, we combined with the project and resource situation, arrange the project plan, and then report to the boss a look, let the boss in the short term to see a new change, sure we reconstruct the value, in this way, the boss can surprise to look forward to the next target.

What is “beautiful completion”, is that we want to keep improving, meticulous, even a small task, we have to maintain a careful and awe of the state of mind, from the beginning to the completion, do a word “beautiful”, win every small battle.

2.4. Implementation stage

You have your big goals, you have every small goal you break down, and you have your daily tasks for everyone you break down. We work hand in hand, adhere to the basic idea, uphold the purpose of the project, every few days we need to follow up the completion of the progress, and constantly improve my ideas and ideas.

In the early stage of the development of the financial product platform, we formulated the architecture idea of separating the front and back ends (the front end is based on VueJs and the server end is based on SpringBoot). In this way, the front-end and server-side engineers can perform their respective duties and develop in parallel (unlike the original front-end using JSP language development, as a server-side we also need to write HTML and CSS), facilitating system maintenance and upgrade deployment.

Everything is ready except the east wind. I reported to my boss that THERE was a lack of front-end r&d, and the boss applied for a front-end engineer (Mr. Hui and Mr. Liang, who was briefly supported later). The server transferred a strong man (Mr. Kang) from the architecture group, and brought me two servers (initially). With the pace of reconstruction and the continuous progress of the project, the boss later came to the rescue and transferred two partners (Xiao Tao and Xian’er) from other teams.

The first stage of reconstruction took a month of research and development and testing (we tested the function menu of the new platform by ourselves, used the new platform in parallel with the old system, and invited the product operation students to help test) and went online, completed that the new platform had the original function menu of the old system, and improved the interactive experience of related functions.

The new platform invites users who operate related products to try it out for a period of time. Problems and defects feedback will be repaired and put online in time to ensure the normal function of the new platform, and finally complete the full switch of users’ platform and end the historical mission of product modules of the old system.

2.5. R&d phase

Core Code Design

In the second stage, to participate in the project of refactoring server only four people (including me, the other is a small Kang, small Tao, small Xian ‘er), so I divide four two teams, I lead small Kang, the task is more difficult, you need to complete financial products center core trial logic code and docking of the bill of lading system interface flow gray level access, The other two partners (Xiao Tao and Xiao Xian’er, xiao Xian’er was entrusted with other tasks by the leader in the critical period of reconstruction) completed the auditing system docking and gray scale access.

When designing the technical scheme, I discussed gray scale design and system access scheme with Xiao Kang. Grayscale scheme needs support. A more fine-grained and flexible grayscale flow access scheme can be provided according to the dimensions of the investor, product, single volume and whether the original trial data is covered, so as to ensure that the impact of the online reconstruction on the online is minimized and the diversity of the flow into the sample coverage is improved.

After careful consideration and evaluation of the research and development period, we realized the design and code implementation of this gray scale scheme with the minimum research and development cost. Although it is not a day in a day, overtime is no longer necessary to meet the rapid access of the subsequent bill of lading system and audit system, and ensure that the team can fulfill the quality commitment of the boss online.

When designing the core test code of financial products, I have been thinking about this design for many nights before going to bed and during the subway journey to and from work. Considering the expansibility and flexibility of the system in the later stage, Google Aviator computing engine is introduced (thanks for the investigation of Mr. Kang, in fact, there are applications based on JepExpression engine in the system, but the expansibility is not good), which effectively solves the flexibility and expansibility of customized functions. In addition, design patterns (templates + policies + chains of responsibility) are introduced through further abstraction of design.

The reason for this design is that at the beginning of the reconstruction, the existing business logic processing is sorted out through the way of thinking map, and it is found that the total loan expense item needs to be checked and filtered by each expense rule each time, and the amount of each independent expense item is calculated, and finally the total loan amount is accumulated. Through a lot of preliminary combing and research and analysis, the final design of this technical scheme.

Audit System Connection

The complexity of auditing system access is due to the fact that the refactoring involves not only the Java server, but also several JSP pages (containing thousands of lines of JavaScript scripts) of the old system. We can imagine the initial design to implement the front-end form verification through JavaScript, but it is hard to imagine that these JavaScript scripts contain a lot of cost calculation and carry and round processing, with the continuous iteration of requirements, many scene lines no longer need to support, but these legacy code throughout the refactoring code.

Audit system docking development, in fact, quite big pressure. After all, it involves an important link – audit link (preliminary review/review/final review), due to the spread of a large scope, the order process is more critical. So how do we reconstruct it?

Through the research scheme (thanks to Xiao Xian’er who proposed the scheme), our team proposed two reconstruction technology design schemes:

  • First, in the existing several JSPS and compatible with gray business scenarios of business logic processing, through a large number of if to determine the route of the new logic or the original logic.
  • Second, maintain the existing several JSP business logic unchanged, copy the new JSP, through Ajax call server charge item loading and financial scheme trial calculation, in the server controller layer to achieve grayscale routing jump.

In both of these scenarios, you can see that there is a lot of code development; But the least impact is the second scheme, but the disadvantage is that with the demand iteration, the need to maintain the new JSP and old JSP business logic processing, if the gray scale time is longer, this pain lasts longer, development and testing need to test these two different scenarios, the cost is very large.

We reported these two reconstruction schemes to the leader. Fortunately, the boss also favored the second scheme, but put forward a requirement that required the shortest time to gray scale and full switching. Therefore, we arranged important persons to observe online data and analyze sample data in the whole gray scale stage to ensure traffic coverage and normal switching of full volume.

2.6 test phase

During the whole reconstruction project, the r&d time occupied most of the construction period, and the deadline expected by the boss was close at hand. Therefore, we explained the current test objectives to the test team and listed the key test scenarios. During the test, the R&D team will cooperate with the test to confirm the correctness of business logic of interface input and output in each case scenario.

At the same time, in order to improve the efficiency of collaboration, we applied for a closed test of an independent conference room. In fact, this way of efficiency is really greatly improved, after all, we want to feedback a bug or reply a question, no longer need to knock word by word, sometimes the two sides are not timely read, the relevant response to understand the deviation.

2.7. Online stage

As we have developed a rigorous on-line plan, the on-line is very smooth. Financial product trial calculation has a gray master switch, which can support whether to use the new trial calculation to cover the original trial calculation result, which is the simplest design of my downgrade scheme.

At the same time, in the access system, the input and output results of the trial calculation of the original financial scheme are printed out through the log, which is convenient for us to observe the trial calculation of the flow manually, ensure the accuracy, and facilitate problem tracking and troubleshooting.

2.8. Observation stage

This stage is, frankly speaking, rather dull work. During the gray scale period, we need to check the correctness of the amount of each cost item one by one in the order of the day’s flow. If differences in related fields are found, we will arrange personnel to troubleshoot the problem, and then repair the test and quickly go online on the same day.

At this stage, Kang’s struggles were unparalleled. This task is not difficult, but it requires a careful person to complete the work, and finally Kang completed the final mission.

2.9. Traffic Switching

Even though we go through the “observation phase” process, we still can’t guarantee 100% accuracy on every order. Therefore, we are more conservative daily flow out of a few lists, and further observation, so gradually put more lists day by day, from 1 single to 5 single, from 20 single to 50 single, in order to complete the full switch online declared the victory of gray stage.

Third, continuous transformation

Endless refactoring and perfect pursuit is our team mission.

3.1. Go to the front

After the first and second stages of reconstruction, we separated the independent financial product platform and independent financial products and services. But this is just the beginning, because this year — 2018 — has also been an extraordinary year. In that year, the product manager in charge of financial products was on leave. Nevertheless, we took the initiative to undertake the requirements of front-line product operation and ensure the normal iteration of requirements.

In order to understand the pain points of the daily operation of our products, we went on business trips to frontline cities and communicated with them face to face about their current problems. By sorting out these pain points, DURING the business trip, I learned Axure prototype design from scratch as a research and development officer, and designed the first draft of the interaction design scheme. After several rounds of meetings and communication with operation students, I finally determined a set of functional design scheme.

Deeply understand the daily operation pain points of frontline users, let us remember. With responsibility and mission, we went back to Beijing to achieve this part of the function design in a short period of time and prioritized with the front end, and went online one by one, winning their recognition.

3.2. Continuous optimization

The more frequent operation of daily product operation is to support the diversified operation landing and execution of different capital parties and cities in different regions. However, the current system cannot support such large-scale operation and modification, so that they often need to update the operation in batches through SQL. Although this method is quick, but it is also very risky, due to the boss’s concern, this SQL operation method also occasionally brought online failure. Through communication with product operation students, we designed a series of functional interaction schemes for batch operation. These functions were able to meet their daily operational needs, and after several major optimizations, these problems were finally resolved.

3.3. Warehouse demolition process

Although the system is separated into separate services, the database still shares the original database instance. The problem is also very common, because many systems are refactoring out separate services, but the database is basically shared by everyone. The number of free connections and cpus available for database instances is limited, so it is these dependent services and systems that are affected when problems occur.

This problem once occurred online, because a large number of slow query SQL database connection can not be released, resulting in free connection full, and then reach the maximum connection limit, affecting the whole chain of service business invocation, this disaster is very terrible, but also very fatal.

Therefore, in the second half of 2018, we started the three-stage target dewarehousing. The purpose of dewarehousing is to keep the database table structure unchanged to reduce the impact of dewarehousing. When the implementation plan is dismantled and goes online, we choose a suitable time point – low peak period, app service will be suspended.

Then the DBA will cooperate to migrate the related tables of the old database to the new database. After the data migration, the related tables and data of the original database will be retained at the same time. At this time, the service data source will be switched to the new data source to complete the whole process test of running orders. Observe the situation on line the next day, and deal with the plan at the same time. If there is a fault, the service will be quickly switched to the original release version Tag, and the original deployment will be restored in the shortest time. Planning is essential, after all, to deal with emergencies. Congratulations, the next day there were no breakdowns and we achieved another milestone.

Four, the lingering sound is not in the WIND

As the refactoring came to an end, the biggest change it brought about was that it initially required two teams to complete the requirements matchmaking, but now only our financial products team can do it. At the same time, our own development of computational link analysis, whether in research and development, joint commissioning, testing, or online benefits a large number of role users. This makes it convenient for us to track each order financial scheme trial calculation request and output log, so as to further investigate and confirm problems, which virtually improves the efficiency of all aspects and shortens the cycle.

In terms of financial product solutions, the development cycle can be realized with simple configuration and minimum research and development period no matter what additional or adjusted cost items are required for the subsequent demand. This comparison takes 3-4 days of work before refactoring and is a gorgeous qualitative change.

Hard work always pays off, and these refactoring experiences also benefit other teams, providing experience and practical ideas. The promotion of the post in that year also constitutes a beautiful scenery line in the promotion report. I can share this process and achievements and win the affirmation of leaders.

As boss words “a person’s success is not successful, lead the team to success in order to be truly successful” together, this journey experience not only me, but also with our team, and starting from the initial reconstruction, we started this financial product team was born and grown up, successes and our team’s glorious history.

I would like to thank everyone involved in this process for creating this glorious history together. Thank you! I also want to thank the readers at the end of this article. This is the end of my story. I hope you have been inspired by this story. Thank you!! The world is beautiful because of you!!