Refactoring Patterns: Part 5
content:
Increment iterative MOVING TARGET hugs change -Refactoring and XP reference information about the author
related information:
Other parts of this series
Refactoring and Method Shiyiying@hotmail.com) Zhejiang University Lingfeng Technology Development Company 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.
Increment iteration has started a lot of methods since software engineering, some of which are often hanging in the mouth. These software methods include Waterfall, which is from ROYCE in 1970. First of all. In general, Waterfall methods strictly divide the process of software development into several phases, including: Requirement Phase, Specification Phase, Design Phase, Implementation Phase, Integration Phase, pay attention to testing is not an independent phase, 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 "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 brightened examples also have cockburn, he said: Consider a specific example, someone rushes into a house, 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 really what i wanted." The reason for generating this result is because the user is understood by the document through the paper. The things that are far away are far less than the software that can truly use. 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. The MOVING TARGET incremental iterative model is dealing with the unique advantage over 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? Embrace Change -Refactoring and XP With the birth of Kent Beck's famous "Extreme Programming Explained", 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 XP: XP is a lightweight methodology for small-to-medium-size Teams developing Software in the face of vague or rapidly Changing Requirements. 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 ... ... System goes sour -. The software is successfully put into production, but after a couple of year the cost making changes or the defect rate rises so much the System must be replaced. ... .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 assumes a simplified incremental change accepted change
High Quality Work In order to achieve these principles, Kent Beck proposed its extreme saying:
If Code Reviews is good, we will review if the test is good, each person is tested (unit test), even the customer is also the same (function test) if the design is good We let it turn into everyday daily business (refactoring) if it is easy, let's keep the system to support its current function (The SimpleSt Thing That Could Possibly Work) If the architecture is important Everyone defines and trimming the architecture of each person, if the integration test is important, then we integrate and tested many times within one day (Continuous Integration)
If the shorter iteration is good, we do real, really short to second, division, hourly iteration, not a 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. Kent Beck pointed out that you can't be designed for today's code. Otherwise, your design will walk into the dead alley, and the system cannot evolve, so that it cannot adapt to the changes in demand. However, the complex design is not only able to solve the problem, but also adds the cost of design, increasing the difficulty of understanding, but also the difficulty of increasing expansion and modification, which makes your system very rigid. So, simple design - Simple Design - is the key to success. However, a simple design must be able to adapt to future needs, there must be a practical method to overcome the current limitations later. Refactoring is one of the key technologies. However, this is not easy to achieve. To make Refactoring to truly reach such a goal, you need to control the ownership of the code, otherwise, you will be difficult to modify the codes of others to your code, so you need a common code ownership (Collective Ownership). In order to make Refactoring faster, easy to do, your code must have a good style and a Coding Standard that you have agreed. If you have pair programming, then you can better handle complexity. Refactoring, also makes the possibility of Refactoring error greatly reduced. Further, Testing enables Refactoring more secure. Encoding is a team's work, so you need Continuous Integration, so when your Refactoring is conflict, you can know that the original code and design can be restored in time. You still need enough rest (REST) so that you will have more courage, not afraid to make mistakes, carry the refactoring to the end. 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.
