quote
Any fool can write code that a computer can understand. Only those who write code that humans can easily understand are good programmers.
1. What is refactoring? Refactoring is improving the internal structure of
software without changing its observable behavior . Refactoring is a disciplined and methodical method minimizes the chance of introducing errors into the cleanup process. Essentially, refactoring is about improving the design of code after it has been written. If you find yourself needing to add a feature to a program and the structure of the code doesn't make it easy for you to do so, refactor that program to make it easier to add the feature, and then add the feature. 1. The first step of refactoring Whenever we are going to refactor, the first step is always the same: establish a set of reliable test environments (if there is none) for the code to be modified. Good tests are fundamental to refactoring . 2. Use the refactoring strategy to split the big method into small methods , and extract the small method to the place where it should exist (in the class or object). "Single Responsibility Principle", "A class should have only one reason for change" and so on all show that "small" is beautiful. Second, the principle of refactoring First: The purpose of refactoring is to make software easier to understand and modify. Second: Refactoring doesn't change observable behavior. Kent beck has a "two hats" metaphor. When developing software using refactoring techniques, you allocate your time to two distinct activities: adding new functionality, and refactoring
. When adding new functionality, you should not modify existing code, just add new functionality. With tests, you can measure your work progress. When refactoring, you can no longer add functionality, just improve the program structure. At this point, no tests should be added and only modified when absolutely necessary. In the process of software development, hats may be changed frequently and crossed.
2.1 Why Refactoring
1. Refactoring to improve software design
If there is no refactoring, the program design will gradually become corrupt. When people modify the code for short-term purposes only, or before they fully understand the overall design, the program will gradually lose its structure, and it will become increasingly difficult for programmers to understand the original design by reading the source code. Refactoring is a lot like tidying up your code, all you do is get everything back to where it should be. The loss of code structure is cumulative. The harder it is to see the design intent represented by the code, the harder it is to protect the design in it, and the faster the design corrupts. Regular refactoring can help code maintain its shape.
Poorly designed programs often require more code to accomplish the same thing, often because the code uses the exact same statement in different places to do the same thing. Therefore, an important direction to improve the design is to eliminate duplicate code . The importance of this action is to facilitate future modifications. Reducing the amount of code doesn't make the system run any faster, because it hardly has any noticeable effect on the program's trajectory. However, the reduced amount of code will make possible future program modifications much easier. The more code there is, the more difficult it is to correct it, because there is more code to understand. You made a little change here and the system didn't work as expected because you didn't change another place where the code was doing almost the exact same thing, just in a slightly different environment. If you eliminate duplicate code, you can be sure that all things and behaviors are expressed only once in the code, which is the essence of good design. Repetition is the root of all evil.
2. Refactoring to make software easier to understand
Programming is very much about talking to a computer: you write code to tell the computer what to do, and it responds by doing exactly what you tell it to do. You have to fill the gap between "what you want it to do" and "tell it what to do". At the heart of this programming model is "say exactly what I want". Besides computers, your source code has other readers: in a few months there may be another programmer trying to read your code and make some changes. It's easy to forget this second reader, but he is the most important. Does it matter if the computer takes a few more hours to compile? If a programmer spends a week modifying a piece of code, that's hell, if he understands your code, the modification would have taken an hour . The maintenance cost of software is far greater than the initial development cost. Refactoring can reduce costs.
3. Refactoring helps to find bugs
4. Refactoring helps to improve programming speed
Good design is fundamental to maintaining software development and speed. Refactoring can help you develop software faster because it stops the system from corrupting and it can even improve the quality of the design.
2.2 When to refactor the
cubic rule:
quote
Don Roberts gave a rule of thumb: do something the first time just do it: do something similar a second time, but do it anyway: do something similar a third time, and you should do it again structure.
1. Refactoring when adding features
The most common refactoring time is when I want to add new features to the software. At this time, the immediate reason for refactoring is often to help me understand the code that needs to be modified—the code may be written by someone else , or may have written it himself. Whenever I want to understand what the code does, I ask myself: Can this code be refactored so that I can understand it faster. Then I will refactor. Part of the reason for this is to make it easier to understand the next time I look at the code, but the main reason: I can understand a lot more if I structure the code as I move forward
. Here, another motivation for refactoring: the design of the code doesn't help me easily add the features I need. I look at the design and say to myself "If it was designed in a certain way, it would be much easier to add features."
In this case I don't feel sorry for my past mistakes - I make up for it with refactoring. Part of the reason for this is to make it easier to add new features in the future, but the main reason is this: I found this to be the quickest path. Refactoring is a fast and fluid process, and once the refactoring is done, the addition of new features is faster and more fluid.
2. Refactoring when fixing bugs Refactoring
is used during debugging, mostly to make the code more readable. When I look at the code and try to understand it, I use refactoring to help deepen my understanding. I find working with code like this often helps me find bugs.
3. Code review
Many companies do regular code reviews because this activity improves development conditions. This activity helps spread knowledge among the development team and also helps more experienced developers pass on knowledge to less experienced people , and help more people understand more of the larger software system. Code reviews are also important for writing clean code. My code may be clear to myself, but not to others. It's unavoidable because it's so hard to put developers in the shoes of people who aren't familiar with what they're doing. Code reviews also give more people the opportunity to make useful suggestions, after all I can only come up with good ideas in a week. My life would be much better if I could get help from others, so I always look forward to More reviews.
2.3 Refactoring and Design
Refactoring has a special mission: it and design complement each other . When I was a beginner in programming, I immersed myself in writing programs and developed in a hurry. However, I soon discovered that designing in advance saved me the high cost of rework. So I quickly enhanced this "pre-engineered" style. Many people see design as a key part of software development, and programming as a mechanical low-level labor. They think that design is like drawing and coding is like construction. But you know, there is a big difference between software and machines: software is more malleable and is entirely a product of ideas . As Alistair Cockburn said: "With design, I can think faster, but it is full of small holes."
There is an opinion that refactoring can replace up-front design. This means that you don't have to do any design at all, just start coding with the original idea, make the code work, and then refactor it into shape. In fact, this approach really works. I have indeed seen someone so proud to end up with well-designed software. Proponents of Extreme Programming [Beck, XP] strongly advocate this approach.
While refactoring alone can work, as mentioned above, it's not the most efficient way. Yes, even extreme programming enthusiasts pre- design . They would use a CRC card or something like that to test out different ideas before they got the first acceptable solution, then they could start coding, and then they could reconstruct. The point is: Refactoring changes predesigned roles. Without refactoring, you have to make sure that the pre-made design is correct, which is too much pressure. This means that any future modifications to the original design will be very expensive. Therefore, you need to put more time and energy into pre-design to avoid future revisions.
If you choose to refactor, the focus of the problem shifts. You still do predesign, but you don't necessarily have to figure out the right solution. At the moment you just need to get a reasonable enough solution. You know for sure that, as you implement this initial solution, your understanding of the problem will gradually deepen, and you may realize that the optimal solution is a little different from what you originally envisioned. As long as you have the tool of refactoring in hand, it's not a problem, because refactoring makes future modifications less expensive.
This shift has led to an important result: software design has taken a big step toward simplification . When I haven't used refactoring in the past, I've always sought a flexible solution. Any one requirement makes me wonder: what changes will this requirement lead to in the lifetime of the system? Since changing the design is very expensive, I want to build a solution that is flexible enough and robust enough that it can withstand my All foreseeable changes in demand. The problem is that the cost of building a flexible solution is difficult to estimate. A flexible solution is much more complex than a simple solution, so the resulting software is usually harder to maintain - although it is certainly more flexible in the direction I envisioned. Even if you are lucky enough to go in a pre-conceived direction, you must understand how to modify the design. If the change is only in one or two places, it's not a big deal. However, changes may actually occur anywhere in the system. If flexibility is established in all possible places where changes occur, the complexity and maintenance difficulty of the entire system will be greatly increased. Of course, that's the biggest failure if all that flexibility turns out to be unnecessary. You know, there must be some of this flexibility that doesn't really come in handy , but you can't predict which ones won't come in handy. To get the flexibility you want, you have to add in more flexibility than you actually need.
With refactoring, you have a different path to dealing with the risks of change. You still need to think about potential changes , flexible solutions still need to be considered. But instead of implementing these solutions one by one, you should ask yourself "how difficult is it to refactor a simple solution into this flexible one?" If the answer is "fairly easy" (which is most of the time). Then You only need to implement the current simple solution.
Refactoring can lead to simpler designs without losing flexibility, which also reduces the difficulty of the design process and reduces design resistance. Once you feel more about the simplicity of refactoring, you don't even have to think about the so-called flexible solution in advance. Once it is brief, you will always have enough confidence to refactor. Yes, for now, just build the simplest system that works, as for flexible and complex designs, most of the time you won't need it.
Reference:
"Refactoring - Improving the Design of Existing Code" by Martin Fowler