Refactoring and method
Shi Yizhen (
Shiyiying@hotmail.com)
Zhejiang University Lingfeng Technology Development Company Technology Director
December 2001
Refactoring is more than just a method of encoding. He is also a design method. This paper perspective from the important role of Refactoring from the evolution of software engineering. At the same time, you can also see the close relationship between refactoring and the recent XP development methodology.
Incremental iteration
Since the beginning of software engineering, there are many ways, some of which are often hanging in their mouths. The most famous lifecycle models in these software methods include Waterfall, which is first proposed by Royce in 1970. In general, Waterfall methods strictly divide the process of software development into several stages, including:
Requirement Phase, Specification Phase, Integration Phase, ITEGRATION PHASE, pay attention to testing is not an independent phase, and check and test almost every stage.
It should be said that the Waterfall model is much better by itself. Waterfall enforces all products, and only the next phase of work can only be started after these products passed the relevant reviews, and the considerable part of these products is the detailed documentation of each stage. Specification document, Design document, Code documentation, and other related documents, such as database manuals, user guides, etc. are the basic tools for maintaining product. Studies have pointed out that approximately 70% of software budgets are used for maintenance stages. The Waterfall model enforces each phase must have a detailed document, so it seems that Waterfall can use these documents to reduce this overhead.
However, the Waterfall model can also become a shortcomings by the document. Waterfall started from the demand phase, once the demand report was admitted by the user, you started drafting the Specification document, which pointed out what the software needs to do. The Specification document is usually very long, very detailed, very straightforward, so it is easy to look at the hanest. User is often difficult to understand the SPECification documentation of the software. He is almost impossible to judge whether you are correct, but usually he will still sign.
The problem here is whether the communication between people and people can be implemented fully using documents, even if you can use more advanced graphics such as UML maps. For this problem, biologists Maturana and Varela have studied in biological systems. The following is their answer in "The Tree of Life":
. . . . The phenomenon of communication does not rely on the content delivered, but depends on what happened to the recipient. And this is a very different thing that is very different and "transfer information".
Alistair cockburn explained in his 2001 new book "Agile Software Development" explained that you can imagine that people were surrounded by a film, and they were involved in external stimuli, which were reconstructed into internal signals, thus trigger internal activities. Therefore, the information that people really accept depends on the interior instead of external. More light-out examples also have cockburn, he said:
Consider a specific example, someone rushed into a house and use Japanese to call "fire!". A person who can speak Japanese receives a lot of information and immediately rush to the exit. Another Japanese next to him, just sleeping, so there is no information at all. External stimuli is not converted into internal signals. A person who doesn't understand Japanese is noted that there is someone coming in, but there is no special information from his words. Everyone relies on his internal conditions from the things that receive it.
During the translation of this sound, a Japanese can accept a lot of information rather than the Japanese, but an important reason why the cloud is unsatisfactory is a common experience of the Japanese in the room: Japanese . Software demand acquisitioners, Spectation writers and users often have such common experience. Similarly, it is impossible if the light is designed to design a document to make the designer and developers can achieve good communication. Document helps to enhance understanding, but it is impossible to meet complete understanding. Waterfall attempts to rely on a very detailed document to access the perfection of communication. In fact, the understanding of the document does not depend on the level of detail. It is relying on the common experience between the writer of the document and the document reader.
If I have a design pattern with you, then I said: "Use Visitor Mode", may draw 100 UML class diagrams than two people without design mode experience, write a detailed document of 1000 sentences Can explain the problem.
This accumulation of this common experience is clearly impossible. Of course, in a software company, long-term cooperation may use the designer and developers to achieve higher level communication, for example, when designing, you said: "Just like the problem in the last multilingual ". Then, the programmer can be fully implemented without the need for more design information.
For users' needs, this long-term relationship is rare. Therefore, unless you are very familiar with the user's field, you are familiar with you to understand the user's one. Otherwise, you can't complete the design once, your understanding of the user and the user's understanding, that is, the communication between users and you require multiple times to reach a relatively perfect level.
The issue of communication does not only communicate between people and people, one person needs and the achieved goals. This is what we said. Whether in the demand phase, the tendering phase, the design phase or the implementation phase, the problem solves the problem of your understanding of this problem. The deeper understanding, the problem is solved and perfect. And this understanding is impossible to achieve it. Therefore, there is any stage of software development, you need iteration, so that you can better solve problems.
Another problem with Waterfall is that users cannot see any users before the final product delivery. The user's views of the submitted product are both possible: "i know this is what I ask for, but it isn't real what i wanded."
The reason for producing this result is that because users understand that the documents on paper are far from so much software products that are really useful. Waterfall is directly required for demand and Specification, which may generate products that are not user truly needed.
In order to solve this problem, we need to use an incremental model. Unlike Waterfall and rapid prototyping models, incremental models do not try to publish software that fully compliant user needs one-time. Instead, the final product is divided into several Build, design, development, release or even in accordance with one build. At any stage, users can get a practical software that meets part of the needs. Instead of being a model in front, it is necessary to wait a few months, one year or year, it will wait until the product it does not need.
The incremental model can be adapted to the user's change. Change is the intrinsic feature of user organizations in every growth, and the requirements of change are also part of software development. This is also the meaning of "software is soft". From the customer's financial point of view, the incremental model also makes them do not need a significant amount of funding. If you find problems during the development process, users can also measure back funds in time.
The incremental model will also have problems. One of the difficulties is that each newly released build must be able to smoothly integrate into the existing system without destroying something already. From this perspective, the design under an incremental model may require more complex design than Waterfall. Because Waterfall considers all questions at once, it can see the design in advance (within his own range), since the problem is all, you can solve the problem relatively easy. The incremental model is different. When building the current build, you will not consider the future build. Therefore, the future Build may require current Build's unpredictable support, which may also be integrated into the current system in an unpredictable manner. Object-oriented approach to help much more. One of the basic principles of object-oriented is Open-Closed principles. A module can be written after the release, so even if build is added, it does not destroy the original system. At the same time, it makes the system smoothly integrated in an incremental manner through various object-oriented mechanisms, polymorphisms. However, to close, you must ensure that your design has enough capacity to future modules open. Just like we have said that the one-time design is impossible to achieve such a goal. Obviously, you need a method to change the internal structure in the case where the external behavior of a module is not changed, so that the increment can be successfully performed. Refactoring is a natural solution and core technology of increment iterative models.
Moving Target
The incremental iterative model is dealing with the unique advantage on the processing MOVING TARGET issue. The so-called MOVING TARGET may occur as development progressed, and the demand for software changes.
Today's high-speed information circulation and market competition pressure is the most important reason for this phenomenon. A most competitive company is the most fast and corresponding enterprise. Adaptation changes are the core competitiveness of an enterprise. The reason why software can occupy such an important position in today's society, that is, it is more adapted than other people. If the software does not provide the most powerful support, there is no other artifact to do it.
Moving target is considered to be one of the most difficult solutions in software engineering. Here, with the process constructed, the user's demand continues to change. This will not only cause the development team to have frustrated, but also the software that is very similar to the structure. At the same time, this change will greatly increase the cost of software development.
Perhaps, this problem can be solved by building a fast prototype, such, regardless of whether the user changes needs, as long as the last user is satisfied with Specification, the product will begin to build. But in fact, there is nothing to prevent customers from changing demand again after approved Specification. The benefits of prototype are only able to let users see software that can work, thereby reducing the number and frequency of variations. But if the customer is willing to spend money, it can change the demand every day.
Obviously, too much process control is difficult to solve such problems. The complexity of process control will reduce the response speed of the demand change, then it is not like some software engineering books, what is our situation?
Hugging change - Refactoring and XP
With the birth of Kent Beck, XP is one of the most popular topics of software projects. At the same time, it is also the center of various debates.
Kent Beck gives XP in the second sentence in the XPE preface to the definition:
XP is a lightweight methodology for small-to-medium-sized teams development software in the face of vague or rapidly changing required.
This paragraph explains the topic of XP, which can be seen between the following words:. . . IT Reliance ON An Evolutionary Design Process That Lasts As long as the system lasts.
.
... ..business misunderstood. . . Business changes. . .
The important issue to be solved by XP is how to achieve better communication, thereby adapting to changes in demand. It allows users to change in any direction at any time. In order to achieve this, it does not work with other engineering methods, and the focus is more emphasized more emphasizes personal skills and practical principles.
The basic principles of XP include:
Quick feedback
Assumption
Incremental change
Acceptance
High quality work
In order to achieve these principles, Kent Beck proposed its extreme:
If Code Reviews is ok, we will review Code (Pair Programming) every moment.
If the test is good, everyone is tested every moment (unit test), even the customer is also the same (function test)
If the design is ok, we let it become a daily business for everyone (refactoring)
If it is simple, we let the system maintain simple design to support its current function (The Simplest Thing That Could Possibly Work)
If the architecture is important, each person defines and trimming the architecture (Metaphor) every moment.
If integrated test is important, we integrate and test more times within one day (Continuous Integration)
If the shorter iteration is good, we do it true, really short to second, division, hours, rather than one week, January or year (The Planning Game)
I don't want to discuss XP here. However, I think anyone, whether he thinks that XP is viable, there is a point that it is undeniable: XP's practical principles and program techniques are the long-term accumulation of the software industry. Even if you don't use XP as your development methodology, these principles and techniques are still basic skills that you want to be excellent procedures and designers. This is also the attitude of I treat UML, you can use RUP as your process management guidance, but UML itself is indeed a summary of the software industry to modeling technology. If you think that the picture is more clear than reading the text, then UML still has something (of course, some people don't like the graphics of the log rules, "Kent Beck is one of them).
It can be seen above, refactoring is one of the cores of XP practices. Not that obvious, but maybe more importantly, there is an indivisible connection between refactoring and other principles and practices.
