進入數據重構
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 GeneXus 1 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
1 Gonda 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.
Crystal Light Methods: Comments by Alistair Cockburn
輕量級的Crystal方法
Editor's note: In the early 1990s, Alistair Cockburn was hired by the IBM Consulting Group to construct and document a methodology for OO development. IBM had no preferences as to what the answer might look like, just that it work. Cockburn's approach to the assignment was to interview as many project team members as possible, writing down whatever the teams said was important to their success (or failure). The results were surprising. The remainder of this section was written by Cockburn and is based on his "in-process" book on minimal methodologies.
編者注：在九十年代早期，Alistair Cockburn IBM顧問組工作時，為OO(面向對象)的開發制訂了一套工作方法。IBM認為不管白貓黑貓，抓的到老鼠就是好貓。Cockburn 深入接觸許多開發小組，寫下了他們認為導致項目成功或者失敗的關鍵之處。結果讓人大吃一驚。以下內容是由 Cockburn寫的，基于他的含有極少方法論的"實戰工作"書 。
In the IBM study, team after successful team "apologized" for not following a formal process, for not using a high-tech CASE tool, for "merely" sitting close to each other and discussing as they went. Meanwhile, a number of failing teams puzzled over why they failed despite using a formal process - maybe they hadn't followed it well enough? I finally started encountering teams who asserted that they succeeded exactly because they did not get caught up in fancy processes and deliverables, but instead sat close together so they could talk easily and delivered tested software frequently.
在IBM的研究組里，開發小組要向以前成功的小組"道歉"，因為他們沒有遵守一道正式的工序， 因為他們沒有用一個高科技的CASE工具，又或者"僅僅"因為他們坐在一起，討論他們下步 該怎么做。 同時，一些失敗的小組覺得非常迷惑，盡管他們使用了正式的工序，他們還是 失敗了--也許是遵守這些工序還遵守的不夠好?后來我開始碰到一些成功的小組，他們宣稱 正是因為沒有陷于花里胡哨的過程和可發布性，而是大家坐在一起，從而使得他們可以 更容易的加以討論并且經常交換測試后的軟件，最終才得以成功。
These results have been consistent, from 1991 to 1999, from Hong Kong to the Americas, Norway, and South Africa, in COBOL, Smalltalk, Java, Visual Basic, Sapiens, and Synon. The shortest statement of the results are:
這些結論從 1991 到 1999，從香港到美國, 挪威, 和南非,在COBOL, Smalltalk, Java, Visual Basic, Sapiens, 和 Synon都是一貫堅持 , 這些結論的最短描述是：
To the extent you can replace written documentation with face-to-face interactions, you can reduce reliance on written work products and improve the likelihood of delivering the system.
盡可能在你的范圍內，用面對面的溝通來代替寫文檔，從而可以減少對寫好了的工作產品的依賴，并 增大發布系統的可能性
The more frequently you can deliver running, tested slices of the system, the more you can reduce reliance on written "promissory" notes and improve the likelihood of delivering the system.
越是經常發布正在運行著并且經過測試的系統片段，就越能讓你減少對寫好的"約定"標記的依賴，越能增大最終發布系統的可能性
People are communicating beings. Even introverted programmers do better with informal, face-to-face communication than with paper documents. From a cost and time perspective, writing takes longer and is less communicative than discussing at the whiteboard.
應當以人性的方式加以溝通。即使是對內向的程序員來說，采用不拘禮節的面對面的交流，都比采用寫在紙上的文檔進行溝通效果要好。從成本和時間上來看，寫文章總比在白板上討論耗費更多的時間，而且溝通的效果也更差。
Written, reviewed requirements and design documents are "promises" for what will be built, serving as timed progress markers. There are times when creating them is good. However, a more accurate timed progress marker is running tested code. It is more accurate because it is not a timed promise, it is a timed accomplishment.
那些寫好的而且評審過的需求和設計文檔，只是"承諾"了要做什么，我們可以將其作為項目進度的標志 使用。有很多進度標志在最初設立時是好的。然而，更準確的進度標志應該是運行測試后的代碼。因為這不是預先承諾的標志，而是真正完成的標志。
Recently, a bank's IT group decided to take the above results at face value. They began a small project by simply putting three people into the same room and more or less leaving them alone. Surprisingly (to them), the team delivered the system in a fine, timely manner. The bank management team was a bit bemused. Surely it can't be this simple?
最近，一個銀行的IT部決定小試一下以上結果。他們啟動一個小項目，使用簡單的把三個人放在一個房間里的方法，讓他們自生自滅。令人驚奇的是，這個小組及時的、優秀的發布了系統。銀行的管理層覺得有點困惑。一定不會這么簡單的吧?
It isn't quite so simple. Another result of all those project interviews was that: different projects have different needs. Terribly obvious, except (somehow) to methodologists. Sure, if your project only needs 3 to 6 people, just put them into a room together. But if you have 45 or 100 people, that won't work. If you have to pass Food & Drug Administration process scrutiny, you can't get away with this. If you are going to shoot me to Mars in a rocket, I'll ask you not to try it. We must remember factors such as team size and demands on the project, such as:
當然不是如此簡單。另外一個采訪了所有其他項目后得到的結論是：不同項目有不同的需要。這是非常明顯的不依賴于方法論的(不知道怎的)。當然，如果你的項目只需要3到6個人，只要讓他們在一個房間里就可以了。但如果你有45或者100個人，這就沒用了。如果你要通過食物藥品管理部門的過程檢驗，你就不能這樣開始。如果你想把我用火箭發射到火星上去，我建議千萬不要嘗試。我們必須記住團隊的大小和項目的需求這類因數：
As the number of people involved grows, so does the need to coordinate communications.
隨著參與人數的增長，協調溝通的需求也更多
As the potential for damage increases, the need for public scrutiny increases, and the tolerance for personal stylistic variations decreases.
隨潛在的破壞性的增長，對于公開檢查的要求也在不斷增加，而同時對由于個人風格的不同所導致差異的可容忍程度也在降低
Some projects depend on time-to-market and can tolerate defects (Web browsers being an example); other projects aim for traceability or legal liability protection.
一些項目依賴市場方面所確定的發布時間，而且對于一些缺陷能加以容忍(WEB瀏覽器就是這樣一個例子);其他的一些 項目致力于條理性和法律責任。
The result of collecting those factors is shown in Figure 6. The figure shows three factors that influence the selection of methodology: communications load (as given by staff size), system criticality, and project priorities.
根據收集到的有關因素總結出的結論如圖Figure 6所示。它顯示了影響選擇不同方法論的三個因數：溝通難度(由成員的數量決定)，系統關鍵程序，以及項目的優先級。
Figure 6 -- The family of Crystal methods.
Locate the segment of the X axis for the staff size (typically just the development team). For a distributed development project, move right one box to account for the loss of face-to-face communications.
根據成員數量確定在X軸上的部分(通常的只是開發組)。如果是一個分布的開發項目，因為面對面溝通的機會減少，向右移動一格。
On the Y axis, identify the damage effect of the system: loss of comfort, loss of "discretionary" monies, loss of "essential" monies (e.g., going bankrupt), or loss of life.
在Y軸上，確認系統損壞的影響：舒適程度下降，明顯的經濟損失，根本性的經濟損失(比如破產)，或者喪命。
The different planes behind the top layer reflect the different possible project priorities, whether it is time to market at all costs (such as in the first layer), productivity and tolerance (the hidden second layer), or legal liability (the hidden third layer). The box in the grid indicates the class of projects (for example, C6) with similar communications load and safety needs and can be used to select a methodology.
在頂層的不同的飛機(板塊panel?)反映了各種項目的不同重點，所耗費的是否是上市時間(就象在第一層)，效率和兼容性(隱藏的第二層)，或者法律責任(隱藏的第三層).網格中的格子決定了在相似溝通難度和安全需求下的項目的類型(例如C6)，你可以用來選擇方法論。
The grid characterizes projects fairly objectively, useful for choosing a methodology. I have used it myself to change methodologies on a project as it shifted in size and complexity. There are, of course, many other factors, but these three determine methodology selection quite well.
這個網格顯示了項目的特性，對選擇一個方法論很有用。我自己在項目的大小和復雜程度改變的時候，用來改變我的方法論。當然還有其他的因素，但這三個用來決定選擇什么方法論是很好的。
Suppose it is time to choose a methodology for the project. To benefit from the project interviews mentioned earlier, create the lightest methodology you can even imagine working for the cell in the grid, one in which person-to-person communication is enhanced as much as possible, and running tested code is the basic timing marker. The result is a light, habitable (meaning rather pleasant, as opposed to oppressive), effective methodology. Assign this methodology to C6 on the grid.
假定現在要選擇項目的方法論。得益于上面所提到的對有關項目的訪談，你可以把建立一個最輕量級的方法論，想象成按照網格中的格子工作，在這里，盡量提高人和人之間的交流，運行測試后的代碼是最基本的進度標志。結果是一個簡單的，符合人的習慣的(意味著更讓人愉快的，反對壓抑人的)高效率的方法論。在網格上指定這個方法論到C6。
Repeating this for all the boxes produces a family of lightweight methods, related by their reliance on people, communication, and frequent delivery of running code. I call this family the Crystal Light family of methodologies. The family is segmented into vertical stripes by color (not shown in figure): The methodology for 2-6 person projects is Crystal Clear, for 6-20 person projects is Crystal Yellow, for 20-40 person projects is Crystal Orange, then Red, Magenta, Blue, etc.
重復這些所有的格子，產生一個輕量級的方法的家族，根據他們對人們的信心，溝通，和發布運行代碼的頻率。我叫這個家族為Crystal Light方法論族。這個家族用顏色(在圖上沒畫)分成不同的豎直的條紋：2-6個人的項目的方法論叫 Crystal Clear ，6-20人的項目的方法論叫 Crystal Yellow , 20-40人的項目的方法論叫 Crystal Orange,然后是 Red，Magenta，Blue，等等。
Shifts in the vertical axis can be thought of as "hardening" of the methodology. A life-critical 2-6-person project would use "hardened" Crystal Clear, and so on. What surprises me is that the project interviews are showing rather little difference in the hardness requirement, up to life-critical projects.
垂直方向間的切換在方法學上被稱為強化。一個短生命期的2到6個人的項目應該使用強化了的Crystal Clear或其派生方法來管理。使我驚喜的是，在這樣的 項目中幾乎看不到增加需求和按時完成項目之間的矛盾。
Crystal Clear is documented in a forthcoming book, currently in draft form on the Web. Crystal Orange is outlined in the methodology chapter of Surviving Object-Oriented Projects (see Editor's note below).
Crystal Clear出自一本即將出版的書，現在網上已經有草稿。在《Surviving Object-Oriented Projects》一書的方法論一章中描述了Crystal Orange的輪廓。
Having worked with the Crystal Light methods for several years now, I found a few more surprises.
在采用Crystal Light方法多年以后，現在我發現了更多的驚喜。
The first surprise is just how little process and control a team actually needs to thrive (this is thrive , not merely survive). It seems that most people are interested in being good citizens and in producing a quality product, and they use their native cognitive and communications abilities to accomplish this. This matches Jim's conclusions about adaptive software development (see Resources and References, page 15). You need one notch less control than you expect, and less is better when it comes to delivering quickly.
第一個驚喜是，一個開發隊伍成功(不僅僅是幸存)并不需要太多的管理和控制。大部分開發人員都樂于專心工作和寫出好的軟件，他們會使用自己的理解能力和溝通能力去 完成這一切。這和Jim做出的關于自適應軟件開發的結論完全一致(參見"資源和參考"，第15頁)。你需要比你預計的要少得多的控制，尤其是當你希望能盡快發布軟件時，越 少就越好。
More specifically, when Jim and I traded notes on project management, we found we had both observed a critical success element of project management: that team members understand and communicate their work dependencies. They can do this in lots of simple, low-tech, low-overhead ways. It is often not necessary to introduce tool-intensive work products to manage it.
更特別的是，當我和Jim交換項目管理的心得時，我們意識到我們都觀察到了成功的項目管理中的一個關鍵要素：開發人員能理解有關人員的工作并加以溝通。他們能通過 許多簡單、低技術含量并且廉價的方法完成這一切。通常這并不需要引入什么特別的工具來管理。
Oh, but it is necessary to introduce two more things into the project: trust and communication .
不過項目中還是需要兩個關鍵要素：信任和溝通。
A project that is short on trust is in trouble in more substantial ways than just the weight of the methodology. To the extent that you can enhance trust and communication, you can reap the benefits of Crystal Clear, XP, and the other lightweight methods.
在一個項目中，缺乏信任比選擇了錯誤的方法學更要命。從某種程度上講，只要你能加強信任和溝通，你就一定能受益于Crystal Clear，XP(極限編程 ?)或別的輕量級開發方法。
The second surprise with defining the Crystal Light methods was XP. I had designed Crystal Clear to be the least bureaucratic methodology I could imagine. Then XP showed up in the same place on the grid and made Clear look heavy! What was going on?
第二個驚喜是當我們定義Cystal Light方法的時候它就和XP一致了。我把Crystal Clear設計成我所能想象的最不官僚的方法學。隨后XP在 同一領域出現并展露鋒芒，在它面前Clear仿佛成了重量級的開發方法!這是怎么一回事?
It turns out that Beck had found another knob to twist on the methodology control panel: discipline. To the extent that a team can increase its internal discipline and consistency of action, it can lighten its methodology even more. The Crystal Light family is predicated on allowing developers the maximum individual preference. XP is predicated on having everyone follow tight, disciplined practices:
這大概是因為Beck發現了方法學的控制面板上的另一個開關：紀律。在某種程度，如果一個開發小組能增強內部的紀律性并保證行動的一致性，方法學可以變得更加 輕巧。Crystal Light衍生的方法學給予開發者最多的個性化。XP則要求每個人都遵守嚴格的有紀律的實踐：
Everyone follows a tight coding standard.
每個人都必須遵守一個嚴格的編碼標準。
The team forms a consensus on what is "better" code, so that changes converge and don't just bounce around.
關于什么是好的代碼, 開發小組在此方面應達成共識，這樣所有的變化都集中在一起，避免了反復。
Unit tests exist for all functions, and they always pass at 100%.
每個函數都必須經過單元測試，并且必須100%通過。
All production code is written by two people working together.
所有產品的代碼都是由兩名開發人員一起工作完成的
Tested function is delivered frequently, in the two- to four- week range.
以每兩周到四周為一個周期, 頻繁地發布那些經過測試的函數，。
In other words, Crystal Clear illustrates and XP magnifies the core principle of light methods:
換一句話說，Crystal Clear展示了輕量級方法的核心法則，而XP放大了它：
Intermediate work products can be reduced and project delivery enhanced, to the extent that team communications are improved and frequency of delivery increased.
在一定程度上，如果開發隊伍的交流得到了改善，發布的頻率得到提高，那么就可以減少中間產品的工作量，從而能更快地完成項目。
XP and Crystal Clear are related to each other in these ways:
XP和Crystal Clear有如下關聯：
XP pursues greater productivity through increased discipline, but it is harder for a team to follow.
XP通過增強紀律性提高生產效率，但是它對于開發者更難于遵守。
Crystal Clear permits greater individuality within the team and more relaxed work habits in exchange for some loss in productivity.
Crystal Clear給予開發者更多的個性空間，允許比較松散的工作習慣，但是同時損失了一些生產效率。
Crystal Clear may be easier for a team to adopt, but XP produces better results if the team can follow it.
開發隊伍可以比較輕松地使用Crystal Clear方法，但是如果能夠有效地使用XP，效果會更好。
A team can start with Crystal Clear and move itself to XP. A team that falls off XP can back up to Crystal Clear.
開發隊伍可以從Crystal Clear開始，然后轉移到XP方法。開發隊伍也可以放棄XP，重新使用Crystal Clear。
Although there are differences in Crystal Clear and XP, the fundamental values are consistent -- simplicity, communications, and minimal formality.
盡管Crystal Clear和Xp之間存在很多差異，但是它們的基本價值觀是一致的--簡單、交流和盡量減少形式化。
Editor's note: For more information on the Crystal Clear methodology, see Alistair Cockburn's Web site, listed in the References and Resources section. For more information on Crystal Orange, it is covered in the book Surviving Object-Oriented Projects , also listed in the References and Resources section.
編者按：如果你想深入了解Crystal Clear，請看"相關資源與引用"部分列出的Alistair Cockburn的網站，在。如果你想深入了解 Crystal Orange，你可以參閱《Surviving Object-Oriented Projects》一書，同樣有關信息在"相關資源與引用"部分也已列出。
Conclusions: Going to Extremes
結論：走向極限
Orr and Cockburn each describe their approaches and experience with lighter methodologies. But earlier, in describing Chrysler's C3 project, I alluded to the difficulty in extending the use of approaches like XP or even RAD. In every survey we have done of eAD subscribers, and every survey conducted of software organizations in general, respondents rate reducing delivery time as a critical initiative. But it is not just initial delivery that is critical. Although Amazon.com may have garnered an advantage by its early entry in the online bookstore market, it has maintained leadership by continuous adaptation to market conditions -- which means continuous changes to software.
Orr 和 Cockburn 都描述了他們的輕量級方法和經驗。但在前面描述Chrysler的 C3 項目時，我間接的提到，擴展使用類似XP或者甚至是RAD的方法都存在著困難。在我們 對eAD的訂閱者所做的所有調查以及所有軟件組織的行為調查中，一般說來，快速的響應 速度，減少發布時間是一個關鍵的開始。但這并不是說只有首次發布才是關鍵的。雖然 Amazon.com 因為更早進入網上書店市場而擁有優勢，但它為了維持它的領導地位，必須 持續不斷的適應市場條件----這意味著軟件的持續更改。
Deliver quickly. Change quickly. Change often. These three driving forces, in addition to better software tools, compel us to rethink traditional software engineering practices -- not abandon the practices, but rethink them. XP, for example, doesn't ask us to abandon good software engineering practices. It does, however, ask us to consider closely the absolute minimum set of practices that enable a small, co-located team to function effectively in today's software delivery environment.
快速發布.快速修改.頻繁變更.通過這三者的驅動，加上更好的軟件工具，迫使我們重新 思考傳統的軟件工程實踐----并不是放棄它們，而是對其重新加以思考。例如，XP 并沒有 要我們拋棄好的軟件工程實踐。相反，它要求我們去深入地思考，在 當今軟件發布環境下，小型協作團隊能夠高效運作所需的最低環境要求有哪些。
Cockburn made the observation that implementation of XP (at least as Beck and Jeffries define it) requires three key environmental features: inexpensive inter-face changes, close communications, and automated regression testing. Rather than asking "How do I reduce the cost of change?" XP, in effect, postulates a low-change cost environment and then says, "This is how we will work." For example, rather than experience the delays of a traditional relational database environment (and dealing with multiple outside groups), the C3 project used GemStone, an OO database.
Cockburn 觀察發現，XP(至少按照Beck和Jeffries所定義的那樣)的實現至少需要三個 環境特征：界面修改不會帶來昂貴的的代價，更密切的交流和自動的回歸測試。實際上 XP 不是問"我該如何降低變更帶來的成本"，而是要求一個低更改成本的環境，然后說"我們將這樣工作"。例如， C3項目使用面向對象數據庫GemStone，而不是去使用傳統關系數據庫(以及 和多個外部組打交道)。
Some might argue that this approach is cheating, but that is the point. For example, Southwest Airlines created a powerhouse by reducing costs -- using a single type of aircraft (Boeing 737s). If turbulence and change are the norm, then perhaps the right question may be: how do we create an environment in which the cost (and time) of change is minimized? Southwest got to expand without an inventory of "legacy" airplanes, so its answer might be different than American Airline's answer, but the question remains an important one.
有些人也許會說這種方法是欺騙，確實如此。例如，西南航空公司在創建動力室時，使用 同一種類型的飛機(波音737)來降低成本。如果湍流和改變都是標準的，那么正確 的問題可能就是：我們如何創建一個導致最低變更成本(和時間)的環境?西南航空公司在擴 張時，沒有遺留的飛機存貨。對于美國航空公司來說，這個問題的答案也許會不同，但是 它仍然是個重要的問題。
There are five key ideas to take away from this discussion of XP and light methods:
在這個關于XP和輕量方法的討論中，我們能得到如下五個主要觀點：
For projects that must be managed in high-speed, high-change environments, we need to reexamine software development practices and the assumptions behind them.
對于那些處于飛速變化環境中的項目而言，我們需要重新檢視有關的軟件開發實踐以及與之對應的有關假定。
Practices such as refactoring, simplicity, and collaboration (pair programming, metaphor, collective ownership) prompt us to think in new ways.
類似于重構、簡單化和合作(配對編程，隱喻，代碼共享)等實踐促使我們以一種新思路來思考。
We need to rethink both how to reduce the cost of change in our existing environments and how to create new environments that minimize the cost of change.
我們不僅需要重新思考如何在現有環境中降低變更導致的成本，而且還需要重新考慮如何創造一個新的環境, 從而能夠將變更成本降到最低。
In times of high change, the ability to refactor code, data, and whole applications becomes a critical skill.
在頻繁變動中，對代碼, 數據以及整個應用重構的能力將會成為一項關鍵的技能。
Matching methods to the project, relying on people first and documentation later, and minimizing formality are methods geared to change and speed.
將方法應用到項目中去時，先依賴人，再依賴文檔，盡量減少形式化的東西，從而有效地將方法與項目相結合
Editor's Musings
編者的沉思(編后語)
Extreme rules! In the middle of writing this issue, I received the 20 December issue of BusinessWeek magazine, which contains the cover story, "Xtreme Retailing," about "brick" stores fighting back against their "click" cousins. If we can have extreme retailing, why not Extreme Programming?
極端的規則。在寫這篇文章的過程中，我曾經收到12月20日發行的商業周刊雜志。其中有 一個封面故事，"極端零售"，關于"brick"商店反擊它們的堂兄弟"click"。如果我們可以 有極端零售，為什么不極端編程呢。
Refactoring, design patterns, comprehensive unit testing, pair programming -- these are not the tools of hackers. These are the tools of developers who are exploring new ways to meet the difficult goals of rapid product delivery, low defect levels, and flexibility. Writing about quality, Beck says, "The only possible values are 'excellent' and 'insanely excellent,' depending on whether lives are at stake or not" and "runs the tests until they pass (100% correct)." You might accuse XP practitioners of being delusional, but not of being poor-quality-oriented hackers.
重構，設計模式，對單元測試的充分理解，配對編程----這些都不是黑客們的工具。它們是開發者 們為了解決產品快速發布，同時又能保持較少的缺陷和靈活性時探索出的新方法。關于質量，Beck說，"只有兩種情況下是有價值的：'優秀'或者'極其優秀'，這取決于其對軟件產品生存的影響程度"，以及 "執行測試直到它們通過(100%正確)"。你也許可以指責XP的實踐者是受到了蒙蔽，但是他們決不是那種不重視質量的黑客。
To traditional methodology proponents, reducing time-to-market is considered the enemy of quality. However, I've seen some very slow development efforts produce some very poor-quality software, just as I've seen speedy efforts produce poor-quality software. Although there is obviously some relationship between time and quality, I think it is a much more complicated relationship than we would like to think.
對于傳統方法的支持者來說，縮短發布時間是質量的敵人。然而，我看過一些開發速度 很慢而且質量非常差的軟件，就象我看過的另一些開發速度很快但質量低下的軟件一樣。雖然在時間 和質量間存在一些明顯的聯系，但我認為這個聯系比我們一般所想象的要的復雜的多。
Traditional methodologies were developed to build software in environments characterized by low to moderate levels of change and reasonably predictable desired outcomes. However, the business world is no longer very predictable, and software requirements change at rates that swamp traditional methods. "The bureaucracy and inflexibility of organizations like the Software Engineering Institute and practices such as CMM are making them less and less relevant to today's software development issues," remarks Bob Charette, who originated the practices of lean development for software.
傳統方法可用于開發那些變化程度不大并可預期最終結果的軟件.然而，商業世界卻是變化莫測的，并且傳統開發方法已無法滿現在的快速變化軟件需求的要求。輕量級軟件開發實踐的創始人Bob Charette認為"由于軟件工程研究所(SEI)這樣組織的官僚化、頑固性，以及諸如CMM的實踐，使得他們日益脫離當今的軟件開發。
As Beck points out in the introduction to his book, the individual practices of XP are drawn from well-known, well-tested, traditional practices. The principles driving the use of these practices, along with the integrative nature of using a specific minimal set of practices, make XP a novel solution to modern software development problems.
就象Beck在他書中所寫的簡介中指出的一樣，XP中的各個獨立實踐，都是從著名的，經過很好的測試 的，傳統實踐中抽取出來的。這些原則驅動著實踐的使用，與一個特別的實踐最小集自然的一 體化在一起，使得XP成為一個解決現代軟件開發問題的新方案。
But I must end with a cautionary note. None of these new practices has much history. Their successes are anecdotal, rather than studied and measured. Nevertheless, I firmly believe that our turbulent e-business economy requires us to revisit how we develop and manage software delivery. While new, these approaches offer alternatives well worth considering.
但是我必須以一條警告來做結束語。所有的這些新實踐都沒有很長的歷史，它們的成功就象 逸事一樣，沒有被加以研究和度量。然而我堅信，我們混亂的電子商務經濟需要我們重新審視 如何開發和管理軟件發布。這些方法雖然很新，但它們提供了有價值的另一條思路。
In the coming year, we will no doubt see more in print on XP. Beck, Jeffries, Fowler, and Cunningham are working in various combinations with others to publish additional books on XP, so additional information on practices, management philosophy, and project examples will be available.
明年，我們毫無疑問地可以看到更多關于XP的出版物，Beck, Jeffries, Fowler和Cunningham 都在相互合作出版更多關于XP的書。因此，你將看到更多的關于實踐的信息，管理哲學和項目 實例等。
Finally, a note on how to continue the discussion of XP and other "extremes": as I announced in the previous issue, we have initiated an eAD discussion forum. If you are interested in joining the group, send us an e-mail at ead@cutter.com , and we will add you to the discussion group and send logon information.
最后，一個關于如何繼續XP和其他"極端事物"討論的提示：就象我在前面討論中宣布的那樣， 我們創建了一個eAD論壇。如果你對加入這個小組感興趣，給我們發email到 ead@cutter.com， 我們將把你加入這個討論組，并且會把登錄信息發送給你。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
