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.
最后，維護如此困難的原因之一在于，當改變數據庫設計時，其他的問題都會接踵而來。在大多數開發人員看來，一旦設計好數據庫并在此基礎上開始了編碼以后，再去改變數據庫的設計幾乎是不可能的。在某種程度上，設計數據庫就好比建造系統的地基：一旦你把混凝土灌了進去，你就沒辦法再去改變它。因此，除非不可避免，大型系統中的數據庫極少會發生大的改動。人們不能把重新設計數據庫僅僅當成系統維護的普通一部分。否則的話，對系統進行大的改動會變的難以想象的困難。
Enter Data Refactoring
進入數據重構
Jim and I had never been persuaded by the argument that the database design could never be changed once installed. We had the idea that if you wanted to have a minimal system, then it was necessary to take changes or new requirements to the system and repeat the basic system cycle over again, reintegrating these new requirements with the original requirements to create a new system. You could say that what we were doing was data refactoring, although we never called it that.
Jim和我永遠都不會承認一旦系統開始運行就不能再改變數據庫設計的觀點.我們認為,如果你想使系統保持最精簡的狀態,就必須要把所要做的變化或新的功能引入到系統中并重復基本的開發過程,使新的需求和舊的需求融合在一起而成為一個新的系統.你可能會說我們所作的就是數據重構,可我們從來不那么說.
The advantages of this approach turned out to be significant. For one thing, there was no major difference between development of a new system and the maintenance or major modification of an existing one. This meant that training and project management could be simplified considerably. It also meant that our systems tended not to degrade over time, since we "built in" changes rather than "adding them on" to the existing system.
這么做的好處是顯而易見的.首先,開發一個新系統和維護或對舊系統統進行較大改造的區別并不是很大.這就意味著管理一個項目和培訓工作將大大減少.同時,也將減少開發時間,這是因為我們對變化的處理方式不同，一個是'built in'(建立在變化之上),另一個是'adding them on'(添加變化)。
Over a period of years, we built a methodology (Data Structured Systems Development or Warnier/Orr) and trained thousands of systems analysts and programmers. The process that we developed was largely manual, although we thought that if we built a detailed-enough methodology, it should be possible to automate large pieces of that methodology in CASE tools.
在過去的幾年里，我們建立了一種方法（結構化系統設計方法或Warnier-Orr法）并且培訓了數以千計的系統分析員和編程人員。即便我們在定義了足夠詳細的各種說明后有可能用CASE工具實現大部分工作，但開發過程仍需要大量的手工工作。
Automating Data Refactoring
自動化的數據重構
To make the story short, a group of systems developers in South America finally accomplished the automation of our data refactoring approach in the late 1980s. A company led by Breogán Gonda and Nicolás Jodal created a tool called GeneXus1 that accomplished what we had conceived in the 1970s. They created an approach in which you could enter data structures for input screens; with those data structures, GeneXus automatically designed a normalized database and generated the code to navigate, update, and report against that database.
為了縮短開發時間，南美的一組系統開發人員在80年代年開發出了數據重構自動化工具。由Breogán Gonda 和 Nicolás Jodal領導的公司開發了一種名叫GeneXus的工具，這正是我們在70年代所構想要的。他們創建的方法使我們在輸入數據結構以后，系統能夠自動為你創建規范的數據庫并產生瀏覽、更新和輸出數據的代碼。
But that was the easy part. They designed their tool in such a way that when requirements changed or users came up with something new or different, they could restate their requirements, rerun (recompile), and GeneXus would redesign the database, convert the previous database automatically to the new design, and then regenerate just those programs that were affected by the changes in the database design. They created a closed-loop refactoring cycle based on data requirements.
這就使事情簡單了，這種工具使得當用戶的需求或系統的要求改變后只需要修改原有的定義，重新編譯，就能夠重新設計數據庫以適應新的需求，并產生僅僅受數據庫修改影響而需要改變的代碼。這就是基于數據的閉環的重構過程。
GeneXus showed us what was really possible using a refactoring framework. For the first time in my experience, developers were freed from having to worry about future requirements. It allowed them to define just what they knew and then rapidly build a system that did just what they had defined. Then, when (not if) the requirements changed, they could simply reenter those changes, recompile the system, and they had a new, completely integrated, minimal system that incorporated the new requirements.
GeneXus使我們認識到重構能構給我們帶來的真正的東西。就我的經驗而言，這使開發人員從對未來需求的擔憂中解脫出來，從而能夠使開發人員僅僅定義他們所知道的并快速的實現所定義的所有內容。因此，當系統的需求更改以后，他們只須簡單的加入那些修改，重新編譯，就可以得到一個新的、完全集成的、滿足新的需求的最小系統。
What Does All This Mean?
所有的這一切意味著什么？
Refactoring is becoming something of a buzzword. And like all buzzwords, there is some good news and some bad news. The good news is that, when implemented correctly, refactoring makes it possible for us to build very robust systems very rapidly. The bad news is that we have to rethink how we go about developing systems. Many of our most cherished project management and development strategies need to be rethought. We have to become very conscious of interactive, incremental design. We have to be much more willing to prototype our way to success and to use tools that will do complex parts of the systems development process (database design and code generation) for us.
重構正在逐漸變成一個時髦的詞語。與所有的時髦的東西一樣，既有好的一面，也有壞的一面。好的一面是：如果能夠正確的實施，重構使我們有可能快速構建健壯的系統。壞的一方面是：我們不得不重新考慮如何進行開發。原先采用的所有開發和管理策略需要重新考慮。我們必須了解交互式的、增量的開發方法；我們還必須習慣于使我們能夠成功的模式化的開發方法和使用工具來完成系統開發工作中那些復雜的工作（數據庫設計和代碼生成）。
In the 1980s, CASE was a technology that was somehow going to revolutionize programming. In the 1990s, objects and OO development were going to do the same. Neither of these technologies lived up to their early expectations. But today, tools like GeneXus really do many of the things that the system gurus of the 1980s anticipated. It is possible, currently, to take a set of requirements, automatically design a database from those requirements, generate an operational database from among the number of commercially available relational databases (Oracle, DB2, Informix, MS SQL Server, and Access), and generate code (prototype and production) that will navigate, update, and report against those databases in a variety of different languages (COBOL, RPG, C, C++, and Java). Moreover, it will do this at very high speed.
80年代，CASE使開發產生革命性的變化。90年代，對象和OO方法也使開發產生革命性的變化。這些技術都沒有像達到期望的效果。但現在，像GeneXus這樣的工具切切實實的做到了80年代人們所期望的東西。確實有可能在給定系統需求后自動進行數據庫設計，生成一種實際工作的商用關系型數據庫（Oracle, DB2, Informix, MS SQL Server, and Access），并產生能夠瀏覽、更新和輸出數據庫中數據的不同語言（COBOL, RPG, C, C++, and Java）的代碼（原型和結果）。
This new approach to systems development allows us to spend much more time with users, exploring their requirements and giving them user interface choices that were never possible when we were building things at arm's length. But not everybody appreciates this new world. For one thing, it takes a great deal of the mystery out of the process. For another, it puts much more stress on rapid development.
新的系統開發方法能夠使我們有更多的時間和用戶交流，分析用戶的需求，讓用戶選擇不同的交互界面，這在只憑自己來完成所有事情的時侯是不可能的。但是并不是所有人都喜歡這一開發方法。一個是因為這將很大程度上撥開開發過程的神秘面紗。另一個是因為這也給快速開發增加了壓力。
When people tell you that building simple, minimal systems is out of date in this Internet age, tell them that the Internet is all about speed and service. Tell them that refactoring is not just the best way to build the kind of systems that we need for the 21st century, it is the only way.
當人們告訴你在Internet時代已經不可能再建立簡單、精簡的系統的時侯，那么告訴他們Internet是速度和服務的天下，告訴他們重構不僅僅是在21世紀建立這樣系統的最好方法，也是唯一的方法。
-------------------------------------------------------------------------------
NOTES
1Gonda and Jodal created a company called ARTech to market the GeneXus product. It currently has more than 3,000 customers worldwide and is marketed in the US by GeneXus, Inc.
文章來源于領測軟件測試網 http://www.kjueaiud.com/
