When it comes to refactoring, different people have different opinions. As a code farmer who has been working for four or five years, I also talk about my own views. It happened that I participated in the training on clean code today, and I also confirmed some of my thoughts on refactoring.
With the rapid development of the Internet today, refactoring, like continuous integration, has become an indispensable part of software development, along with the entire software life cycle. However, refactoring is different from continuous integration. Refactoring is a spontaneous behavior of programmers. Sometimes it is difficult to get the understanding and support of bosses, especially some PMs who have never written code. They may feel that refactoring is simply in the waste time. Because refactoring is difficult to measure and calculate KPIs. For them, there is no essential difference between good programmers and bad programmers. Coupled with the factors of the entire environment, it is difficult for programmers to feel at ease to carry out the refactoring to the end. Therefore, it is very important to communicate with the bosses, and let the PM realize the importance and necessity of refactoring.
Since refactoring is so important, what is refactoring, why and how? These questions will immediately enter your brain.
What is refactoring? Here's a quote from Martin Fowler's definition in the book Refactoring. Refactoring is an adjustment to the internal structure of software. The purpose is to use a series of refactoring methods to adjust its structure, improve its understandability, and reduce its modification cost without changing the observable behavior of the software. Refactoring, by this definition, is tidying up code. From a technical point of view, refactoring is the use of a series of efficient and controlled code cleaning techniques to modify the code to improve the readability, stability, scalability and maintainability of the code. Before and after refactoring, no or little change is made to the external behavior of the observable lines of the software. There are two main points here, the first is the method of reconstruction, and the second is to change the internal and not to change the external.
Why refactor? From the perspective of software design, in the entire software life cycle, the change of requirements is inevitable and will always occur. Programmers modify the code without fully considering the entire software design, the program will gradually lose its original design structure, and the code will become more and more difficult to read and maintain. The most typical is to add a bunch of if/else without adding a requirement to a function. When the accumulation reaches a certain level, no one may be able to read it at all, and the maintenance cost can be imagined. From a design point of view, the architecture design is based on some basic conditions. During the operation process, the magnitude of the load changes, and these basic conditions are likely to change. When a bottleneck is reached, the software system is likely to have various Such an accident. Refactoring requires that the code can be extended and modified when these basic conditions occur. This also shows from another aspect that the architect should participate in the implementation of the code, and feedback some defects of the design from the implementation to reduce the risk.
How to reconstruct it? Refactoring is the behavior of the code, first to find out which code needs to be refactored. Good code doesn't need to be refactored, only bad code needs to be refactored, so we need to find out the bad code. In the words of Martin Fowler, bad code smells bad. We use certain rules to identify bad code. The benefits of good code may vary, but the harm of bad code is obvious to all. For example, duplication of code, copy is everywhere for a variety of reasons, even Microsoft often has this kind of thing (go to google and you will find a lot of such little stories). Another thing is that the size of the function is too large. A function may have thousands of lines of code, and it is impossible to read at all, not to mention maintenance and modification. For more bad taste, you can refer to Martin Fowler's book "Refactoring", I believe you will find the mistakes we make every day.
Refactoring is a programmer's behavior and an attitude of being responsible for one's own work. Therefore, first of all, we must affirm refactoring, identify the bad smell of code, learn the skills of refactoring, and then develop a habit of these and integrate them into Go to the daily coding. Let's share.