preface

Not long ago, I came across a saying in Zhihu, “The only way to control the mountain of excrement is not to reconstruct, but not to reconstruct”. I think that makes a lot of sense. Instead of using it as a guideline, the entire project was completely refactored.

refactoring

Refactoring is caused

In the end, I decided to refactor, for several reasons. There are four reasons:

  1. The support of the leader, willing to pay the cost, and pay the time
  2. The project byThe project a.completelycopy 至 Project BAnd,Project BonlyThe project a. 中 A quarterThe function of the
  3. The technology stack used by this project is too different from other projects to unify the project architecture of the same type of project
  4. The project inNew/ModifiedFunction, because the code is too old, causing pain

Refactoring process

In fact, it is not accurate to say that the reconstruction of “shit mountain”, more like rewriting “shit mountain”.

  • Organize the pages you need and break them down into tasks.
  • The whole project was rebuilt at the bottom layer, discarding the unintroduced libraries and rewriting routing, request encapsulation, utils tools, file structure, proxy, and….
  • Page after page is rewritten through the new framework

Refactoring online

By the time the entire project is reconfigured and goes live. Something is wrong emmm…. List of questions:

  1. A page that has been referenced is not collated, causing the page to disappear
  2. There’s a pagetitleI wrote a wrong word.
  3. There is a data request interface for the page, should beGETAnd I sent itGETRequest, but the old code request type isPOSTThe interface request failed. Procedure

PS: Before problem 3 came up, I had a problem that the interface request type was GET instead of POST. But you never expected a POST request for GET.

When I encountered problem 1, I added the page as soon as possible. When I encountered problem 2, I wasted no time in correcting typos. When I encountered problem 3, I wasted no time in correcting them

I’m stuck here now and the problem has been solved but I’m afraid to go online because I actually requested the page for problem 3 many times in the test environment and it didn’t happen. I’m afraid there may be other bugs that haven’t been detected.

I don’t care about the problem itself, what I care about most is why I don’t dare to go online after the problem. Finally, the following are summarized:

  1. The leader wants the project to switch seamlessly without any problems
  2. The product is already running smoothly online, and any problems with refactoring are unacceptable
  3. Compared to new products, users are more interested inbugIs less tolerant of sudden appearance
  4. No test
  5. There were no steps online, leading to a cluster of problems

conclusion

In order to ensure that our refactoring does not end in surprise, we need to know the following questions:

  • Do you need to refactor?
  • Why refactor?
  • How should you refactor?

Whether refactoring is required

If I had understood this, I would not have refactored it rashly!!

If (the project is too big) {return Never refactor!! } if (chunk of code you don't know what to do) {return never refactor!! } if (you have been with the company for less than 1 year) {return does not need to refactor} if (you need to serve KPI && Refactoring is not good for KPI) {return does not need to refactor} if (your leader does not want you to refactor) {return does not need to refactor} Return You most likely don't need to refactorCopy the code

For the most part, the average developer doesn’t think about refactoring. When considering refactoring, consider the following:

  • Is it good for the company
    • In most cases, the benefits of refactoring for a company are small, as it is difficult to guarantee progress from “Mountain 1.0” to “Mountain 2.0”
  • Is it good for you
    • In most cases, the benefits of refactoring are far less than the time spent learning new things and consolidating old ones
  • Are the costs proportional to the benefits
    • In most cases, the costs and benefits of refactoring are not proportional
  • How to ensure the follow-up effect
    • Specify specifications in advance and ensure that the specifications are strictly followed during reconstruction and subsequent maintenance

Why refactoring

When a system is running steadily online, there always needs to be a good reason for refactoring. The reason cannot be “scalability and maintainability”. The resources consumed by large-scale refactoring cannot be supported by such two short sentences. You should make sure that you are severely deficient in at least one of the following:

  • Lack of performance
    • The existing code does not run smoothly online and does not guarantee the user experience
  • Ability to scale
    • Existing code is basically unextensible and difficult to complete when new requirements come along
  • Maintenance costs
    • Existing code is fatally flawed in maintenance, leading to a surge in refactoring needs on your team

Otherwise:

  • Before refactoring, no one else can accurately estimate your workload
  • In refactoring, other people can’t accept problems after they occur
  • After refactoring, other people are unaware of the benefits of refactoring

And:

  • You complete the KPI

How you should refactor

When refactoring a project that is already running smoothly, we should not leave a period of time entirely to refactoring. The refactoring should be carried out in parallel with the business requirements, and the business requirements should come before the R&D requirements.

Our refactoring at least follows the following principles: before refactoring, ensure the compatibility of the project, ensure the full understanding of the code, ensure the separation of tasks, ensure the establishment of specifications; In the reconstruction, the development of business requirements will not be affected, and step by step online is guaranteed. After refactoring, ensure complete test coverage and ensure strict maintenance in accordance with the specification.

All of this is so that there are no surprises in our refactoring, and surprise here is a neutral word, and there should be no surprises in your refactoring, good or bad.

Before the refactoring

Before refactoring the project, we must:

  • To ensure the compatibility of the project after reconstruction
  • Deep code reading to ensure the steady operation of the project after refactoring
  • In order to ensure the timeliness of the project, the reconstruction time is accurately estimated
  • The module scale of reconstructing online process is refined to avoid too many or too few online modules at one time
  • Develop the coding specification of the refactored project
  • Prepare new domain name, new warehouse, convenient project step by step online

In the reconstruction

In project refactoring, we must:

  • Ensure page consistency and function consistency before and after reconstruction
  • Manage time properly to ensure that it does not affect the development of business requirements
  • Do unit testing well
  • Step by step online
  • Do online tests

After the reconstruction

After refactoring the project, we must:

  • Ensure complete coverage of tests, avoiding untested code and surprisesbug
  • Maintain the project according to the established specifications, and avoid the progress from “Mountain 1.0” to “Mountain 2.0”.

conclusion

The problems in this refactoring are relatively classic, representing typical problems in the life cycle of the whole project.

Problem 1: Unnecessary refactoring

In the final analysis, this reconstruction is an unnecessary reconstruction, and the result of reconstruction is not to gain any benefits, but to get a bunch of problems. The hidden benefits are:

  • In subsequent updates, the same content used in the same scene can be uniformly removednpm
  • After the new front end students are hired, they can learn all the projects in this scene faster

Problem 2: Write all the data and go online once

The benefits of writing all online at once are:

  • There is no need for a new domain name, a new repository for intermediate substitution

The disadvantage is that:

  • As a result, the test of each module is not detailed enough, and some problems are ignored
  • Cause problems to explode on a massive scale, which can lead to emotional swings, which can set off a chain reaction

Problem 3: The module is missing

The collection of used modules is not careful enough, resulting in module missing when online

Problem 4: Not knowing enough about the page

Due to the lack of in-depth understanding of the page, resulting in the test, part of the background entrance missed, resulting in the occurrence of problems.