Figure 1 -- Historical lifecycle change costs.
Figure 2 -- Comtemporary lifecycle change costs.
The Cost of Change
變化的代價
Early on in Beck's book, he challenges one of the oldest assumptions in software engineering. From the mid-1970s, structured methods and then more comprehensive methodologies were sold based on the "facts" shown in Figure 1. I should know; I developed, taught, sold, and installed several of these methodologies during the 1980s.
Beck從他的早期的著作開始，就不斷向那些軟件工程中的一些"古訓"發出挑戰。從19世紀70年代中期的結構化方法，以至后來的那些更復雜的方法，他們都基于如圖1所示的那個"事實"，在整個80年代，我必須了解、使用、討論、實施這些方法。
Beck asks us to consider that perhaps the economics of Figure 1, probably valid in the 1970s and 1980s, now look like Figure 2 - that is, the cost of maintenance, or ongoing change, flattens out rather than escalates. Actually, whether Figure 2 shows today's cost profile or not is irrelevant -- we have to make it true! If Figure 1 remains true, then we are doomed because of today's pace of change.
Beck卻給我們提了一個問題，那些在70年代和80年代也許還能起到效果的方法，他們的經費開銷狀況(如圖1)現在已經發生了變化(如圖2)，也就是說，維護的成本(也可以等價為不斷發生的變化)降低了，而不是越來越高。實際上，圖2所示的開銷情況在當今是否是事實其實并不重要，重要的是我們必須認識到，如果圖1的現象還在繼續重演的話，我們只有死路一條，因為當今時代變化實在太快了(也就是說維護的成本將是一個天價)。
The vertical axis in Figure 1 usually depicts the cost of finding defects late in the development cycle. However, this assumes that all changes are the results of a mistake -- i.e., a defect. Viewed from this perspective, traditional methods have concentrated on "defect prevention" in early lifecycle stages. But in today's environment, we can't prevent what we don't know about -- changes arise from iteratively gaining knowledge about the application, not from a defective process. So, although our practices need to be geared toward preventing some defects, they must also be geared toward reducing the cost of continuous change. Actually, as Alistair Cockburn points out, the high cost of removing defects shown by Figure 1 provides an economic justification for practices like pair programming.
圖1中的y軸通常用來表示在開發周期的后期發現錯誤后需要花費的改錯成本�？墒�，這正驗證了一個假設，即后期所有需要做的開動均來自前期的一個錯誤，比方說一個設計缺陷。從這一點來看，傳統方法太依賴于在軟件生命周期的早期"不出錯"。但是在當今瞬息萬變的環境中，我們不能完全預防住那些我們預測不到的東西--即由應用需求不斷增長而帶來的變化，并且這種變化在早期不可能遇見并加以預防。因此，雖然我們要盡可能在早期做出某些應付變化的預防措施，但是更重要的是我們要減少后期改變所帶來的開銷。正如 Alistai Cockburn 所指出的，需要高成本的圖1所示的那種改正缺陷方法，正好從節省開支的角度給了一些實用的方法(如配對編程)一個好的理由。
In this issue of eAD, I want to restrict the discussion to change at the project or application level -- decisions about operating systems, development language, database, middleware, etc., are constraints outside the control of the development team. (For ideas on "architectural" flexibility, see the June and July 1999 issues of ADS.) Let's simplify even further and assume, for now, that the business and operational requirements are known.
在本期eAD雜志中，我打算把討論定位于項目或應用軟件層次上的變化--對類似操作系統、編程語言、數據庫、組件等的討論不在討論之列。(關于軟件結構的靈活性，可以參考ADS雜志1999年6月的那期)另外，讓我們進一步做個簡化，即假定軟件的用戶需求已經確定。
Our design goal is to balance the rapid delivery of functionality while we also create a design that can be easily modified. Even within the goal of rapid delivery, there remains another balance: proceed too hurriedly and bugs creep in; try to anticipate every eventuality and time flies. However, let's again simplify our problem and assume we have reached a reasonable balance of design versus code and test time.
我們的目標是既能快速不斷的發布新功能，同時又要讓軟件的設計易于更改。即使是在快速發布這個目標下，仍然需要在"快速發布但Bug叢生"和"面面俱到但曠日持久"之間進行取舍。因此，讓我再簡化一下我們要討論的問題，我們假定我們已經在設計、編碼和測試這三者之間取得了合理的平衡。
With all these simplifications, we are left with one question: how much anticipatory design work do we do? Current design produces the functionality we have already specified. Anticipatory design builds in extra facilities with the anticipation that future requirements will be faster to implement. Anticipatory design trades current time for future time, under the assumption that a little time now will save more time later. But under what conditions is that assumption true? Might it not be faster to redesign later, when we know exactly what the changes are, rather than guessing now?
在上面這些簡化的基礎上，還留有一個尾巴：我們在設計時對于未知的未來要看多遠?現在的設計已經實現了我們現在想到的一些功能。具有預見性的設計可以使未來的需求更快的獲得實現，也就是說預見性設計方法在以現在的時間換取未來的時間，如果一點點現在的時間可以換來未來節約大量時間，當然是劃算的。但是這種建設怎么才能成為現實呢?也許未來出了問題就整個重新設計一遍也不慢，那又何必現在瞎猜呢?
This is where refactoring enters the equation. Refactoring, according to author Martin Fowler, is "the process of changing a software system in such a way that it does not alter the external behavior of the code yet improves its internal structure." XP proponents practice continuous, incremental refactoring as a way to incorporate change. If changes are continuous, then we'll never get an up-front design completed. Furthermore, as changes become more unpredictable -- a great likelihood today -- then much anticipatory design likely will be wasted.
這就是我們為什么要提出重構的原因。重構，Martin Fowler說過，是不改變軟件對外表現但是重整內務的一種改進。XP方法的支持者在變化的環境中實踐了連續的、增量式的重構方法。如果變化是不斷演化的的，那就不可能存在什么一步到位的設計方法。說白了，如果變化不可預測--正如當今社會的情況--過多的在設計時考慮以后可能的變化，完全是一種浪費。
Figure 3 -- Balancing design and refactoring, pre-internet.
Figure 4 -- Balancing design and refactoring today.
I think the diagram in Figure 3 depicts the situation prior to the rapid-paced change of the Internet era. Since the rate of change (illustrated by the positioning of the balance point in the figure) was lower, more anticipatory designing versus refactoring may have been reasonable. As Figure 4 shows, however, as the rate of change increases, the viability of anticipatory design loses out to refactoring- - a situation I think defines many systems today.
我認為圖3給出的是互聯網時代到來之前的情況。由于變化的速度慢(圖中由天平的支點比較靠左來表示)，早期的預測多一些是合理的。但是在圖4中，由于變化速度變快樂，設計時預測太多是得不償失的，這種情況正是現在許多系統所面臨的。
In the long run, the only way to test whether a design is flexible involves making changes and measuring how easy they are to implement. One of the biggest problems with the traditional up- front-design-then-maintain strategy has been that software systems exhibit tremendous entropy; they degrade over time as maintainers rush fixes, patches, and enhancements into production. The problem is worse today because of the accelerated pace of change, but current refactoring approaches aren't the first to address the problem. Back in the "dark ages" (circa 1986), Dave Higgins wrote Data Structured Software Maintenance, a book that addressed the high cost of maintenance, due in large part to the cumulative effects of changes to systems over time. Although Higgins advocated a particular program-design approach (the Warnier/Orr Approach), one of his primary themes was to stop the degradation of systems over time by systematically redesigning programs during maintenance activities.
在一個長期項目中，檢驗一個設計是否具有很好的靈活性是通過變化需求，同時看看原設計能否很容易的實現新變化的需求。這種傳統的"先設計，再維護"策略的最大問題在于軟件系統存在非常大的熵(極易變化，沒有規律)。一個系統隨著時間的推移，維護、改錯、打補丁、增強功能等工作會使系統的熵越來越大�，F在由于外部環境變化加快，情況正越來越糟。不過，現在的重構技術也不是第一個試圖解決這個問題的方法。早在所謂的"黑暗時期"(circa 1986)，Dave Higgins 就寫過一本名為"Data Structured Software Maintenance"的書，該書指出了由于隨著時間的推移變化的累計影響不斷增大，維護所需要的開銷也將越來說龐大，Higgins 提出了一種新的設計方法(the Warnier/Orr Approach)用于阻止系統的熵增大所帶來的負面影響，該方法的思想是在維護過程中有系統的對程序進行重新設計。
Higgins's approach to program maintenance was first to develop a pattern (although the term pattern was not used then) for how the program "should be" designed, then to create a map from the "good" pattern to the "spaghetti" code. Programmers would then use the map to help understand the program and, further, to revise the program over time to look more like the pattern. Using Higgins's approach, program maintenance counteracted the natural tendency of applications to degrade over time. "The objective was not to rewrite the entire application," said Higgins in a recent conversation, "but to rewrite those portions for which enhancements had been requested."
Higgins 的方法首先為程序改如何設計設定一種模式(雖然那時還沒有模式這個提法)，然后在細致的代碼設計與"好"的模式之間建立一種映射，程序員即根據這種映射關系來理解系統并修改程序，使修改的結果更接近于那個模式。使用 Higgins 這個方法可以通過維護抵消系統誰時間而熵增大的趨勢。Higgins 說："該方法的目標并不是重寫整個系統，而只是重寫那些根據需要必須增強的部分。"
Although this older-style "refactoring" was not widely practiced, the ideas are the same as they are today -- the need today is just greater. Two things enable, or drive, increased levels of refactoring: one is better languages and tools, and the other is rapid change.
雖然這種原始的"重構"技術并沒有被廣泛的實踐檢驗，其思想與現在的重構還是相通的，只不過現在的需求變化更快、更大。不過有兩個東西驅動、提高了現代的重構技術：一是更好的程序設計語言和開發工具;二是更快的變化需求。
Another approach to high change arose in the early days of RAD: the idea of throwaway code. The idea was that things were changing so rapidly that we could just code applications very quickly, then throw them away and start over when the time for change arose. This turned out to be a poor long-term strategy.
在早期的 RAD(快速原型開發)方法中還有另一種應付變化的辦法：代碼拋棄思想。這個思想認為環境和需求變化太快，因此我們唯一的辦法只能是快速編寫新代碼，并且也快速的拋棄老代碼。我們認為這不是長久之計。
Refactoring
重構
Refactoring is closely related to factoring, or what is now referred to as using design patterns. Design Patterns: Elements of Reusable Object-Oriented Software, by Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides, provides the foundational work on design patterns. Design Patterns serves modern-day OO programmers much as Larry Constantine and Ed Yourdon's Structural Design served a previous generation; it provides guidelines for program structures that are more effective than other program structures.
重構(Refactoring)與構造 (factoring)，或者說與設計模式的使用密切相關。Erich Gamma, Richard Helm, Ralph Johnson, 和 John Vlissides合著的《 Design Patterns: Elements of Reusable Object-Oriented 》一書為設計模式做出了奠基性的工作。正如Larry Constantine 和Ed Yourdon 所倡導的結構化設計一樣，設計模式對當代的面向對象技術程序設計做出了巨大的貢獻，為開發人員帶來了福音。通過設計模式，程序的結構的比以往更為有效。
If Figure 4 shows the correct balance of designing versus refactoring for environments experiencing high rates of change, then the quality of initial design remains extremely important. Design patterns provide the means for improving the quality of initial designs by offering models that have proven effective in the past.
如果圖表4 所顯示的設計(designing)與重構(refactoring)在面對高速變化環境時的適應能力方面的差別是客觀的話，初始設計的質量則顯的尤為重要。通過提供過去已被證明是有效的模式，設計模式(Design patterns)提供了一種提高初始設計質量的方法。
So, you might ask, why a separate refactoring book? Can't we just use the design patterns in redesign? Yes and no. As all developers (and their managers) understand, messing with existing code can be a ticklish proposition. The cliché "if it ain't broke, don't fix it" lives on in annals of development folklore. However, as Fowler comments, "The program may not be broken, but it does hurt." Fear of breaking some part of the code base that's "working" actually hastens the degradation of that code base. However, Fowler is well aware of the concern: "Before I do the refactoring, I need to figure out how to do it safely.... I've written down the safe steps in the catalog." Fowler's book, Refactoring: Improving the Design of Existing Code, catalogs not only the before (poor code) and after (better code based on patterns), but also the steps required to migrate from one to the other. These migration steps reduce the chances of introducing defects during the refactoring effort.
現在，也許你會問，為什么還需要一本獨立講重構的書呢?難道我們不可以只使用設計模式來重新設計嗎?可以，也不可以。正如所有的開發人員(包括管理者)都知道，修改原有的程序代碼是一件棘手的事。development folklore年刊上有一句話，"if it ain't broke,don't fix it".然而，正如Fowler所提到的，"程序也許還沒有'壞掉'，但卻造成了潛在的危害." 害怕對那些還能"工作"的代碼重新構造實際上只會加劇代碼性能的衰退。同時，Fowler也清楚的認識到："在軟件重構之前，需要找到安全的做法……我把這些安全的步驟寫進了目錄"。Fowler所寫的<>,不僅編錄了如何對以前的(差的)代碼和以后的(基于模式設計的較好)的代碼進行重構的方法，而且也包含了代碼分割重構的步驟。這些步驟減少了在重構過程中出現差錯的機會。
Beck describes his "two-hat" approach to refactoring -- namely that adding new functionality and refactoring are two different activities. Refactoring, per se, doesn't change the observable behavior of the software; it enhances the internal structure. When new functionality needs to be added, the first step is often to refactor in order to simplify the addition of new functionality. This new functionality that is proposed, in fact, should provide the impetus to refactor.
Beck用"two-hat"方法來描述重構，也就是說, 添加新的功能與重構是兩種不同的行為。在本質上，重構不改變軟件可見的外部功能，它只是增強了軟件的內部結構。當有新的功能需要添加時，第一步常是對軟件進行重構，使添加更簡化。事實上，這種添加的新功能為重構提供著推動力。
Refactoring might be thought of as incremental, as opposed to monumental, redesign. "Without refactoring, the design of the program will decay," Fowler writes. "Loss of structure has a cumulative effect." Historically, our approach to maintenance has been "quick and dirty," so even in those cases where good initial design work was done, it degraded over time.
與重量級的再設計相反，重構可以被認為是增量(incremental)式的再設計，"沒有重構，程序設計會 腐爛"，Fowler寫到," 結構性的缺陷會帶來累積效應 "。歷史上，我們對軟件維護的方法是"quick and dirty"(快速但不徹底的?)，致使一些初始設計工作做的好的項目，隨著時間推移，也會"退化"(degrade).
Figure 5 -- Software entropy over time.
Figure 5 shows the impact of neglected refactoring -- at some point, the cost of enhancements becomes prohibitive because the software is so shaky. At this point, monumental redesign (or replacement) becomes the only option, and these are usually high- risk, or at least high-cost, projects. Figure 5 also shows that while in the 1980s software decay might have taken a decade, the rate of change today hastens the decay. For example, many client- server applications hurriedly built in the early 1990s are now more costly to maintain than mainframe legacy applications built in the 1980s.
圖表 5 顯示了沒有重構時的情況：因為軟件是如此的不可靠，升級維護費用變的讓人望而卻步，于是巨型(monumental)設計(或替換)成了唯一選擇，項目的風險，至少是投入上，變的越來越大。圖 5也顯示，在80年代，軟件的生存期大約要10年，而在今天需求的快速變化加劇了軟件的腐爛。舉個例子，許多90年代初一窩蜂做出來的C/S應用軟件在今天比80年代留下來的大型機軟件的維護費用還要高的多。
Data Refactoring: Comments by Ken Orr
數據重構: Ken Orr注解
Editor's Note: As I mentioned above, one thing I like about XP and refactoring proponents is that they are clear about the boundary conditions for which they consider their ideas applicable. For example, Fowler has an entire chapter titled "Problems with Refactoring." Database refactoring tops Fowler's list. Fowler's target, as stated in the subtitle to his book, is to improve code. So, for data, I turn to someone who has been thinking about data refactoring for a long time (although not using that specific term). The following section on data refactoring was written by Ken Orr.
編者注： 如上所提，XP和重構思想吸引我的一點是他們能夠清楚認識到所要考慮實施問題的邊界條件(boundary conditions).例如，Fowler寫了一章"Problems with Refactoring".其中首要的問題就是數據庫的重構。正如書的副標題所示，Fowler的目標是為了提高代碼質量。為此，我咨詢了一些在數據重構(或者用其他的術語)方面有較深研究的人。以下關于數據重構部分由Ken Orr所寫。
When Jim asked me to put together something on refactoring, I had to ask him what that really meant. It seemed to me to come down to a couple of very simple ideas:
當Jim 要我講一講重構時，我問他重構究竟意味著什么。對我來說，把它歸納為以下簡單的幾點：
Do what you know how to do.
做你會做的
Do it quickly.
速戰速決
When changes occur, go back and redesign them in.
當發生變化時，回過頭來重新設計
Go to 1.
回到 1
Over the years, Jim and I have worked together on a variety of systems methodologies, all of which were consistent with the refactoring philosophy. Back in the 1970s, we created a methodology built on data structures. The idea was that if you knew what people wanted, you could work backward and design a database that would give you just the data that you needed, and from there you could determine just what inputs you needed to update the database so that you could produce the output required.
在過去幾年中，Jim和我一起工作，共同研究各種系統方法學(systems methodologies)，發現所有的方法學與重構思想(refactoring philosophy)有著一致的地方。70年代，我們建立了一種基于數據結構的方法學。其主要思想是：在知道了人們的需求后，逆向工作，設計一個僅含必需數據的數據庫，然后再確定更新數據庫必需的輸入數據，產生需要的輸出數據。
Creating systems by working backward from outputs to database to inputs proved to be a very effective and efficient means of developing systems. This methodology was developed at about the same time that relational databases were coming into vogue, and we could show that our approach would always create a well-behaved, normalized database. More than that, however, was the idea that approaching systems this way created minimal systems. In fact, one of our customers actually used this methodology to rebuild a system that was already in place. The customer started with the outputs and worked backward to design a minimal database with minimal input requirements.
從輸出結果逆向工程到數據庫再到輸入來建構系統的方法被證明是一種非常有效和有效率的系統開發方法。幾乎在關系數據庫開始流行的同時，這種方法也發展了起來。使我們能夠建立起運作良好，規范化的數據庫。除此之外，這種思想也適用于創建最小系統(minimal systems).事實上，我們的一個客戶在重建一個系統時已經使用了這種方法并取得了成功。該客戶從輸出入手，通過逆向工程設計了一個滿足最小輸入需求的最小數據庫。
The new system had only about one-third the data elements of the system it was replacing. This was a major breakthrough. These developers came to understand that creating minimal systems had enormous advantages: they were much smaller and therefore much faster to implement, and they were also easier to understand and change, since everything had a purpose.
新系統只有老系統三分之一的數據元(data elements )。這是一個大的突破。開發人員開始逐漸認識到建立最小系統有著巨大的優勢：系統更小因而可以更快的實現;功能單一更能適應變化。
Still, building minimal systems goes against the grain of many analysts and programmers, who pride themselves on thinking ahead and anticipating future needs, no matter how remote. I think this attitude stems from the difficulty that programmers have had with maintenance. Maintaining large systems has been so difficult and fraught with problems that many analysts and programmers would rather spend enormous effort at the front end of the systems development cycle, so they don't have to maintain the system ever again. But as history shows, this approach of guessing about the future never works out. No matter how clever we are in thinking ahead, some new, unanticipated requirement comes up to bite us. (How many people included Internet-based e-business as one of their top requirements in systems they were building 10 years ago?)
然而，創建最小系統并不符合許多分析員和程序員們的想法，不管有多遙遠，他們總認為自己可以超前思考并預見到未來的需求。我認為這源于軟件難于維護的原因。維護一個大的系統是如此的困難并充斥著問題，以致于許多分析員和程序員寧愿在系統開發的前期花費大量的精力來設計一個"完善"的系統，以求一勞永逸。然而事實證明，預測未來是徒勞的。不論我們有多聰明，思想有多超前，總會有一些不曾預料到的需求出現。(有多少人能夠在10年前就將基于internet的電子商務作為未來的需求寫入自己的軟件)
Ultimately, one of the reasons that maintenance is so difficult revolves around the problem of changing the database design. In most developers' eyes, once you design a database and start to program against it, it is almost impossible to change that database design. In a way, the database design is something like the foundation of the system: once you have poured concrete for the foundation, there is almost no way you can go back and change it. As it turns out, major changes to databases in large systems happen very infrequently, only when they are unavoidable. People simply do not think about redesigning a database as a normal part of systems maintenance, and, as a consequence, major changes are often unbelievably difficult.
最后，維護如此困難的原因之一在于，當改變數據庫設計時，其他的問題都會接踵而來。在大多數開發人員看來，一旦設計好數據庫并在此基礎上開始了編碼以后，再去改變數據庫的設計幾乎是不可能的。在某種程度上，設計數據庫就好比建造系統的地基：一旦你把混凝土灌了進去，你就沒辦法再去改變它。因此，除非不可避免，大型系統中的數據庫極少會發生大的改動。人們不能把重新設計數據庫僅僅當成系統維護的普通一部分。否則的話，對系統進行大的改動會變的難以想象的困難。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
