Refactoring Patterns: Part 2
content:
Simplify testing simple design refactoring enhanced software can be understood by refactoring to improve software design refactoring helps you look for bugrefactoring lets you program faster about the author
related information:
Other parts of this series
Why do you want refactoring 石 一 楹 (shiyiying@hotmail.com) Zhejiang University Lingfeng Technology Development Company Director December 2001
Why do you want to change the software that can be run correctly? Does this change affect our design, further changing the methods and ideas for the design of the object-oriented system? This section tries to answer these questions.
Although more "extra work" is needed, it is obviously worthy of our efforts to give us all the benefits to us.
Simplifying a good refactoring implementation can reduce the test amount of new design. Because each step of Refactoring maintains observable behavior, that is, all unit tests of the system can pass smoothly. So only the code that has changed needs to be tested. This incremental test makes all subsequent tests on a solid foundation, and the complexity of the entire system test is greatly reduced. A simpler design refactoring reduces the complexity of the initial design. Gamma pointed out that a trap in complex design patterns is excessive enthusiasm: "The mode has its cost (indirect, complicated), so the design should reach the flexibility required by the demand, not The more flexible and better. " If the design that is trying to intervene too much, it may require unnecessary complexity and errors. Refactoring can expand in a variety of ways. He encouraged the task of hand to establish a proper solution, and when new needs came, you can expand it through the Refactoring extension. The ultimate goal of the refactoring enhancement program is to guide the computer to complete what people need to be completed. However, it is easier to complete this goal. The program is written is a human activity, and people must first understand to act. Therefore, another role of the source code is the tool for communication. Others may modify your code after a few months. If you don't even understand your code, how do he complete the revised modifications? We usually forget this use of source code, although it may be a more important use of source code. Otherwise, we develop high-level languages, object-oriented languages, why don't we use assembly languages or even machine language to write programs? Don't we really spend more computers how many CPU cycles do? If a person can understand our code, he may only take a day to complete a task of adding a function, and if he doesn't understand our code, you may need to spend a week or longer. The problem here is that we need to consider the idea of computer CPU when writing code, but also put the future developers in mind. Unless you write the code's unique purpose, you will lose it. You don't want any other developers to use this code, including yourself. Because you can't remember all the code you have written, if you often go back to see your code, you will experience how the code can be understood. Refactoring makes your code more appreciated, refactoring supports smaller classes, shorter methods, fewer local variables, smaller system coupled, refactoring requires you to be more careful about your name mechanism, let the name reflect your intentions . If which piece is too complicated, you need to refactor to him. You may think that reflecting the intent of the code should be the responsibility of comments and documents. Suppose you write a program, give him a comment, and what you have done this code. You need to modify your comments each time the code changes. In fact, the code itself should be enough to explain this problem. If the code can't reflect your intentions, even more comments are not enough to let you understand all the mechanisms of the code unless you add any comments in every sentence of the code. Even, this repetition responsibility makes it inconsistency once the comments and the code are inconsistent, which will hinder your understanding of the code. And any programmer is not willing to write too much annotation and documentation. So Martin Fowler said: when you feel the need to write a comment, First Try to refactor the code so what any Comment Becomes Superfluous. Martin Fowler also pointed out that refactoring not only increases others understanding of your code, but also a very good understanding of others code, learn other people's code. Usually, when you get a lot of code, you may feel awkward, I don't know where to start.
The best way to learn someone else's code is to perform Refactor on the code. If you find that you can't understand a code, try to use it to yourself, oh, this code may be doing something. Give him a meaningful name, refactor it. Refactor makes your understanding of the code is not only staying in your head, but seeing the code is indeed a change in your understanding. If your Refactor changed the behavior of the system, then you have a problem with your understanding. You must return to the back. Refactoring Improved Software Design Many people think of programming as a low-level event. They think that the code is just a designed accessory. However, it is code, not the design on your head or on the paper, really drives the computer to do what you want. And most of the bugs are also produced in the coding phase. Many methodologies believe that higher quality software can be produced by analyzing and designed rigorously, which is actually impossible. Just as Brain Foote and Joseph Yoder pointed out in the "Big Ball of Mud", although many authors have made a lot of ideal airtight architecture such as Layer, Pipeline, etc. But in practice, it is almost never seen such a clear system. This aspect is due to analysis and design of an application need to have a wealth of knowledge in this field, and this knowledge is not available at the beginning. We usually need to deepen your understanding of this field in the process of practical feedback. Thus, the design we started could not correctly reflect the inherent nature of the system, so it is impossible to get a good reflection in the code. On the other hand, even if the design is intact, as the user is in depth, new demand may be added, and the old demand will be modified, deleted. A first design is impossible to completely anticipate these changes. Once the implementation begins to deviate from the initial design, its code will not be controlled, so that corrosion is inevitably started. The more code added, the faster the corrosion is. If there is no way to keep the design as much as possible, then the final result of this corrosion is that the code has to be abandoned. However, the code implementation and design is always consistent is not that simple. In the traditional software method, once it is developed to the implementation phase, it is difficult to change the design. Therefore, the recent development of object-oriented methodology uses an incremental iteration as a fundamental principle. Perhaps the topic, in some "heavy" software methodology, we can find a clear support, definition, and operational process for iteration (including the iteration), and how to improve programmers can adapt to this dynamic Method of development capabilities. In my opinion, heavy software methodology can be able to include all the issues in software development even if they can play a certain role in software development. Development methodology emphasizes life cycle management and control, but software development does not only have process and life cycle, but more importantly, it is often ignored by "formal" software methods, software development is human activities. No matter how strinted your process control, no matter how perfect your life cycle model, if you can't improve people's productivity, improve the quality of the product, then everything is meaningless. Here, to achieve such an incremental iterative development model, you must enable analysts, designers, program staff, testers, etc., all those who participate in development activities have the ability or can have practical ways to come Implement iteration and achieve increment. If this is not the case, you can't keep the consistency between implementation and design, and you cannot feed back the unreasonable design found in the coding implementation to the initial design, and it is impossible to get the impact generated by the implementation when demand changes. reflect.
If there is no practical basic approach to support the changes you need in iteration, then iteration will be very difficult. We can envisage, once new demand arrives, the new round iteration begins, and the original system design is proved to be adapted Now changes, how can you make an iteration smoothly in an incremental way? Refactoring provides the best support for Incremental Item Development. With the evolution of the system, the structure of the code is getting worse, usually this means that a thing to complete a more code. Many cases, usually have similar code in several different places. Therefore, one of the most important topics of Refactoring is to exclude repetition. We can reach the realm of Once and Only Once by excluding repetition. And it is a basic standard for good design. Once and only overce although it cannot directly improve the efficiency of the software, it makes the code modification and understanding easier, and the structure of the system is clearer. It is the best way to eliminate code corrosion. Refactoring helps you find bugs to help understand the code, can also help you find bugs. Many code is in some very subtle places in the system. If you just read the code over and over again, I am afraid you can never find bug. Sometimes, you can use the IDE to provide such bugs. Because if your code is not a good structure, such as a class has too many responsibilities, then it must have too many states. When debugging, you also need to pay attention to too much phenomenon. You can use refactoring to make the program code more clearer, every moment can pay more attention to specific data and behavior, which will greatly reduce your work. At the same time, because refactoring requires Small Steps, and strict testing for each step, BUG is easy to appear. Refactoring allows you to program more about Refactoring, you might recognize that Refactoring can improve software quality, design, structure, readability, reduce BUG, but you will think that it is possible to use Refactoring technology to develop your development speed. . After all, you have to write additional unit tests, you have to go to the code that you can work. So why is you so trouble? Does he drag my progress? In fact, refactoring does speed up the development speed of the software. A basic prerequisite for a good design is to allow faster software development. It is more absolute, and all the design is not faster and more flexibly supports the changes in software. If there is no good design, you may be able to develop very fast, but with the increase in the function, your code gradually corroded, the structure gradually lost. Each time you need to join a new feature, you have to spend a lot of time to understand the original code, modify the original code bug. Changing a function requires a longer time. Refactoring supports good structure, design and understandability, which makes you develop software faster. Because it prevents software erosion, he is even used for improved design. About the author Shi Yizhen, is currently the technical director of Zhejiang University Lingfeng Technology Development Company. Many years engaged in OO system analysis, design. The main research direction is refactoring and analysis mode. You can contact me via shiyiying@hotmail.com.
