Refactoring Patterns: Part 4
content:
Refactoring can not be implemented in the case of the obstacles and solutions to learn refactoring to get short-term efficiency reduction refactoring extra overhead security Refactories About the author
related information:
Other parts of this series
Reasonable, bravely use refactoring 石 一楹 (shiyiying@hotmail.com) Zhejiang University Lingfeng Technology Development Company Director December 2001
Any kind of technique is not universal. Job design mode, reasonable application can greatly increase the efficiency and beauty of design, and then use the so-called reverse mode. Our refactoring is also.
However, as a powerful design evolution tool, refactoring deserves our efforts. I can't give up such tools because of the fear of new technologies, I will explain some issues that may have any resistance to emotions.
No Refactoring occasion program prototype When you prototypeize a system, you usually don't care about the flexibility and efficiency of the program. The purpose of the prototype is to prove a concept, and an exploration is achieved, accelerating the exchange of communications with customers. Once the prototype is completed, such a code should be lost and restarted correctly. However, once the prototype can play a demo, continue to retain it and have been realized in this way will be difficult to resist. You will say: "The program is very good, use this one!" From the purpose of the prototype, such a strategy is not successful. So foote even said that you want to minimize the risk of directing prototypes into products. One way is to choose a specific language or tool to build your prototype, and you will never use this language or tool to complete your Final product. Since the prototype is fundamentally, it will not be intentionally considering the structure of future changes and procedures, and it is impossible to do refactoring for prototypes. The program cannot work if a program itself can't work, then there is no meaning for him for refactoring. Refactoring reserves the observer of the program, then the result of Refactoring still does not work properly. It does not exclude the use of Refactoring to exclude bugs, but that is the most main function of the program has been implemented. Close to the bottom line If you are close to the last submission date, this time the improvement of the efficiency that Refactoring may occur after the bottom line. At that time, everything didn't make sense. But this problem can have another idea, why do you have this situation? Is it because the estimation is serious or less efficient? If the efficiency is too low, how do you improve efficiency? Refactoring is a way to increase productivity because it makes design better, making it faster. So, if you know that time may not be enough, it is often necessary to implement Refactoring's signal to implement refactoring may encounter the obstacle, and the long-term interests of Refactoring brought by everyone can see, but not everyone is willing to use it. Opdyke said: Therefore, supporters of such technologies may be amazed (disappointing) no one in this world to knock their door. Then, he pointed out that even if the long-term benefits have been aware of the long-term benefits, people still reluctantly use the four key reasons for this method:
"I don't understand how to apply your method." "Your method can only get long-term interests, why do you want to do our best? From a long-term perspective, I may not be this project or a member of this organization." Your way is a cost of overhead, I am employed to write new features. "
"If we apply your method, our existing implementation may change or interrupted in a way expected. Naturality and backward compatibility is very important." These problems do not only exist in the refactoring area, When encouraging people to design, we must also solve these problems: technicians may not understand what is reused and how to reuse; if short-term benefits cannot be seen, technicians do not adopt a method of advocating reuse. We must define additional learning curves and other costs that support reuse methods. The method of supporting reuse should not interrupt a project; new implementation should be backward compatible with the existing system. Learning To know how to refactoring, you have to learn. Refactoring has been successfully used for more than 10 years. These programmers also feedback to the OO community. This article aims to provide you with a guide. After learning this article, you can go deep in the following directions:
It is necessary to start to do Refactoring immediately, your best choice is Martin Fowler's "Refactoring: Improving The Design of Exsiting Code", which has a REFAACTORING classification directory. More than 70 refactoring methods are described in detail. Martin Fowler's Homepage (http://www.martinfowler.com) has some recently extended Refactoring methods. You need to read a variety of good program code and design structures, especially design patterns, because design patterns can be called one of the ultimate goals of Refactoring. You can search for a variety of refactoring tools online, I will introduce later, learn to use the Refactoring tool for more secure refactoring. If you want to learn the theory of refactoring, please refer to the various references, especially the Articles of the Ralph Johnson, and the doctoral papers of their disciples. Also, on my homepage www.erptao.org, you can:
Bringing reviews and suggestions in this article to help me improve; in the forum's discussion, you can see some practices in Refactoring, if you have a problem, you can ask it there, I will try to answer. Refactoring gets short-term benefits without short-term benefits, it is difficult for technicians to see the Refactoring effect. Since Refactoring begins at university research institutions and technologies, how to apply refactoring in industrial mainstream software to become an important content of OO community practice. The CHOISE operating system framework of the University of Illinois is part of these studies. Among them, Choice implements support for different file systems that greatly differ in System V, MS-DOS, BSD UNIX. After appfactoring is applied during development, researchers pointed out that Refactoring is indeed a lot of short-term and long-term benefits. For recent, since the repetition code is excluded, the error found in the general code test only needs to be modified in one place. The total amount of code becomes smaller. Code related to a specific file system format is isolated from code that is universal for two or several file systems. For medium periods, abstraction from Refactoring is usually provided for future other file systems. In fact, the abstraction of the two existing file systems is not necessarily suitable for the third file system, but the universal code already existing is a valuable starting point. The results of the subsequent Refactoring application will show what is true abstraction of the file system. The frame development team found that as practical, the efforts needed to join a file system becomes less and less. Even after later file systems are more complex, developers have more lack of experience. Cut the additional overhead of Refactoring For the additional overhead caused by Refactoring, you can view: the development of tools and technology makes refactoring more automated, which can reduce a lot of manual labor and error intervention; experienced OO programmers report, refactoring The additional overhead is fully capable of improving the promotion of the other phase of the program development with Refactoring. Just started using refactoring, you may feel a little awkward. But once it becomes a habit, you will not feel that this is an extra job, you will treat it as a good part of the programmer development process. You can find a lot of such reports on the Internet, and many of the following contents have also talked about this problem. Security Refactory maintains observable behavior is called Refactoring security. To achieve secure refactoring, you usually have several options [William OpdyKe]:
Believe your own coding ability; believe in experts, literature provides the steps to help you reduce errors. I believe that the compiler can capture the errors you have not discovered; I believe that your test suite can capture the compiler without discovery; believe that the Code Review will catch you, your compiler, your test suite missed a variety of errors. Books, materials, papers, and journals can enhance your programming capabilities and can teach you more good style. Martin Fowler's "Refactoring" is such a book, tells us that refactoring has a very small step step, each step is incheat, but a series of refactoring results will have a strong impact on the system. Compiler, good style, test suite, code review is very valuable, but all these methods have their questions, the compiler does not know the dynamic behavior of the program, good style, Code Review completely relying on people Realize, and anyone will make mistakes. There is no way to override all behaviors. Therefore, an important research direction for the Refactoring for the software community is to define the theory of the refactoring security and implement this tool. They can be used to check if a refactoring is securely applied to a program. If it is safe, then there is a tool to complete the refactoring. This also avoids the bug that can be caused by manual completion. 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.
