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 primize 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:
To minimize this risk that the prototype is directly to the product, a method is to use 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 find that the time may not be enough, it is often a signal that needs refactoring.
Implementing Refactoring may encounter the obstacle and solution Refactoring's long-term benefits that everyone can see, but not everyone is willing to use it, Opdyke said:
Therefore, the supporters of such technologies may be amazed (disappointing) no one in this world knocking 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 interrupt in a way expected. Naturality and backward compatibility are important to us."
These problems do not only exist in the refactoring field, and we must also solve these problems when they encourage people to design, write more reused systems:
Technicians may not understand what is reuse and how to reuse; if short-term benefits cannot be seen, technicians do not adopt methods for 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 in the experience of their Refacorting.
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 Home (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.
In addition, in my homepage http://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 caused by Refactoring, you can look at it:
The development of tools and technology makes Refactoring more automated, reduces a large number of manual labor and error intervention; experienced OO programmers report, the additional overhead caused by Refactoring is fully enhanced using refactoring to develop other phases. 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 found; I believe that your test suite can capture the compiler without discovery errors; believe that the Code Review will capture you, your compiler, your test suite missed the error
Various books, materials, papers, journals can enhance your programming capabilities, and 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.
