Part.1
Why do programmers refactor code when they say something wrong?
When you see your ex written as a ball of code; Adding a few lines of code to a super-large function that requires half a day of logic; When you finally find your way through a maze and carefully add new code only to crash other calling systems; And old, slow systems…
At this point, the programmer has only two choices: suck it up or refactor.
There is a limit to tolerance. The “rule of three” of refactoring states that a programmer can bypass the messy code the first time he sees it. The second time again encountered this, although the in the mind dislike but again reluctantly bypass; The third time will be irresistible.
The following scenario sounds familiar:
Test: Why did you change more than 300 files with such a small function?
Development: hey hey hey, I moved the old code by the way.
Testing: Do you know how much testing this adds to my workload? I have to go back to all that.
Development: no testing, no risk, I just tidy up the code.
Testing: last time you said the same thing, the result secretly changed a certain interface, affecting the downstream system. And that time you…
Product: Are you refactoring again? I’ve got a ton of untapped needs.
Development: my refactoring system is also very important.
Product: What matters? You waste so much manpower refactoring, users can’t see what’s changed, and you might even break old features. Please don’t refactor.
Development: I…
While refactoring is frowned upon by other roles, your fellow programmers will understand and appreciate it. Refactoring is about optimizing your code design to make it more readable.
It’s just that refactoring is a pit, and you fall into it.
Part.2
“I will leave as soon as THE system is restructured.” Longge said.
Due to the improper design of the core system in the early stage, the boundary between power and responsibility is blurred, as long as the marginal code is piled up, resulting in the system is too large, logic confusion, a problem, resulting in the core business paralysis.
The system that is too old and too big is too central is like an untimed bomb. After several losses, the business group decides to unplug this hidden danger: reconstruct the system and divide it into subsystems with single functions according to the business processing logic to reduce the coupling degree.
The team started this as the most important part of the season: running a meeting system, sorting out code logic, scheduling tests, and making notes.
After receiving the task, everyone began to work hard.
But refactoring systems is like threading lines through a vast maze, an expensive process that is easy to miss. New requirements later in the product are added directly to the refactored system. The development team enters a vicious cycle: some people branch new functions in the old system, others in the new, resulting in the submitted code branch chaos, slow construction process, planned task delay, and finally testers find many omissions, and then rework.
People are constantly working on code, refactoring, testing, trying to get the job done 100 percent perfect, and not keeping track of the overall project schedule.
The launch was delayed from September to December, and finally in June, taking more than a year to complete.
Everyone is tortured by reconstruction tired unceasingly, return short time does not see the effect, but already invested manpower and material resources, we have to go down hard scalp.
Later, people could not remember why they had to refactor at the beginning, and what kind of refactor they wanted to reach. They only thought about when the refactor would end and when they would be liberated.
After half a year of reconstruction, some people left the company and only one product of the original project team was left when the project was launched. He said that the project was finally finished and IT was time for me to leave.
Part.3
The above refactoring did not have a reasonable project planning, and also committed the great taboo of refactoring: refactoring code while adding new functions, which is equivalent to overthrowing the original system and redoing it, which is extremely risky.
So how to arrange refactoring reasonably?
1. Follow the “two hats” refactoring principle
During refactoring, two different operations are performed separately: refactoring code and adding functionality.
Modify the design of existing code without changing the functionality of the original system, so that the correctness of these changes can be easily verified using the original testing method.
Then add new functions on the basis of the reconstruction, so that the new functions and old functions are coupled.
In the above example, the business team developed new functions while reconstructing, which put great pressure on the testers. The original testing methods were not applicable and the workload of regression testing was increased.
2. Use the “baby steps” refactoring strategy
Refactoring avoids the use of “big layout” to plan the project process. If it takes several months to sort out requirements, design interfaces, develop joint investigation and test launch, the whole team will have to change direction in a chaotic manner if there is a problem in the process, and the trial and error cost is too high.
“Bub Run” allows us to focus on only one problem point and solve only one problem when refactoring. Small change, small local optimization, short time consuming, quick effect.
This requires us to make refactoring a habit and build it into every code change.
Test driven development
In the example above, it took the best part of a month to test the performance of the entire system interface by leaving all the quality assurance of the code to the tester, and then having to change the code again after the tester had compiled the list of problems. Not only was it a waste of time, it also introduced a big risk.
The correct posture for refactoring is to incorporate testing into each refactoring, take small steps, change a piece of code, test it, and then move on. Refactoring is risky, and development testing is two-fold.
Any fool can write code that a computer can understand, says Refactoring. A good programmer is one who writes code that a human can understand.