極限程式設計（Extreme Programming）—走向極限

march-bird lucian yjf taopin wl jazz韓偉 nullgate Simon[AKA](轉載自cutter.com)　　　　2003年09月15日

　　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 [email protected], and we will add you to the discussion group and send logon information.

　　

　　最後，一個關于如何繼續XP和其他"極端事物"讨論的提示：就象我在前面讨論中宣布的那樣， 我們建立了一個eAD論壇。如果你對加入這個小組感興趣，給我們發email到 [email protected]， 我們将把你加入這個讨論組，并且會把登入資訊發送給你