As we have explored in several issues of eAD, the two most pressing issues in information technology today are:
正如我們在eAD的若干期中探究的那樣，當今信息技術(shù)中最迫切的兩個(gè)問(wèn)題是:
Change is changing. Not only does the pace of change continue to accelerate, but, as the September issue of eAD pointed out, organizations are having to deal with different types of change -- disruptive change and punctuated equilibrium. Disruptive technologies, like personal computers in the early 1980s, impact an industry (in the case of PCs, several related industries), while a punctuated equilibrium - a massive intervention into an ecosystem or an economy -- impacts a very large number of species, or companies. The Internet, which has become the backbone for e-commerce and e-business, has disrupted a wide range of industries -- more a punctuated equilibrium than a disruption.
變化本身也在不斷地變化中。不僅僅是變化的速度在不斷地提高，而且，如eAD的10月中所指出的， 組織正在不得不應付各種類(lèi)型的變化-- 劇變與不斷被打破的平衡。 產(chǎn)生劇變的技術(shù)，象在80年代早期的個(gè)人計算機，沖擊了一個(gè)工業(yè)(PC機以及若干相關(guān)的工業(yè))而不時(shí)打斷的平衡--一個(gè)對生態(tài)系統或者對整個(gè)經(jīng)濟產(chǎn)生巨大影響的介入--則 影響了無(wú)數的物種，或者說(shuō)，公司。已經(jīng)成為電子商務(wù)支柱的Internet, 就已使大范圍的行業(yè)產(chǎn)生劇變--更多的是打斷的平衡而不僅僅是一次劇變。
When whole business models are changing, when time-to-market becomes the mantra of companies, when flexibility and interconnectedness are demanded from even the most staid organization, it is then that we must examine every aspect of how business is managed, customers are delighted, and products are developed.
當整個(gè)商業(yè)模式正在發(fā)生變化，當"時(shí)間意味著(zhù)市場(chǎng)"正成為公司的咒語(yǔ)，當適應性與互連性正在成為甚至是最呆板的組織的需要的時(shí)候，我們將有必要檢查以下的每一個(gè)方面:商業(yè)是如何管理的，客戶(hù)為什么而感到高興，以及產(chǎn)品是如何開(kāi)發(fā)的。
The Extreme Programming movement has been a subset of the object-oriented (OO) programming community for several years, but has recently attracted more attention, especially with the recent release of Kent Beck‘s new book Extreme Programming Explained: Embrace Change. Don‘t be put off by the somewhat "in-your- face" moniker of Extreme Programming (XP to practitioners). Although Beck doesn‘t claim that practices such as pair programming and incremental planning originated with XP, there are some very interesting, and I think important, concepts articulated by XP. There‘s a lot of talk today about change, but XP has some pretty good ideas about how to actually do it. Hence the subtitle, Embrace Change.
終極編程(Extreme Programming )運動(dòng)成為面向對象編程這個(gè)團體的一部分已經(jīng)有數年了， 但是直到最近才引起了越來(lái)越多的注意，特別是最近Kent Beck的《終極編程 釋義:擁抱變化》(Extreme Programming Explained: Embrace Change)一書(shū)的出版。千萬(wàn)不要因為終極編程(業(yè)內人簡(jiǎn)稱(chēng)為XP)這一稱(chēng)呼而對它產(chǎn)生反感。 盡管Beck沒(méi)有說(shuō)象配對編程(pair programming)，增量式計劃(incremental planning)之類(lèi)的來(lái)源 于XP,但是仍然有一些非常有趣的，我認為也是很重要的概念可以借用XP來(lái)表達?，F有有許多關(guān)于變化的討論， 但是XP卻有許多如何實(shí)際去做的非常好的想法。也就是這個(gè)副標題:擁抱變化。
There is a tendency, particularly by rigorous methodologists, to dismiss anything less ponderous than the Capability Maturity Model (CMM) or maybe the International Organization for Standardization‘s standards, as hacking. The connotation: hacking promotes doing rather than thinking and therefore results in low quality. This is an easy way to dismiss practices that conflict with one‘s own assumptions about the world.
有一種趨勢，特別在那些嚴格的方法論者中，希望剔除那些與"能力 成熟度模型"(Capability Maturity Model CMM)或者是國際標準化組織的標準相比不那么笨重的方法，比如象hacking.注釋: hacking推崇行動(dòng)而不是思考從而導致了較低的質(zhì)量。 剔除與某人關(guān)于這個(gè)世界的假設相沖突的實(shí)踐，這倒不失為一種簡(jiǎn)單的方法。
Looked at another way, XP may be a potential piece of a puzzle I‘ve been writing about over the past 18 months. Turbulent times give rise to new problems that, in turn, give rise to new practices -- new practices that often fly in the face of conventional wisdom but survive because they are better adapted to the new reality. There are at least four practices I would assign to this category:
從另一個(gè)角度來(lái)看XP，它倒可能是一個(gè)難題的某個(gè)潛在的部分，這個(gè)一個(gè)我在過(guò)去18個(gè)月中一直都在寫(xiě)的內容?；靵y 的時(shí)期產(chǎn)生新的問(wèn)題，而后者又導致了新的實(shí)踐--新的實(shí)踐公然違抗 傳統的知識，但卻得以幸存下來(lái)是因為它們能更好地適應這個(gè)新的現實(shí)世界。至少有四種實(shí)踐方式我覺(jué)得是屬于這個(gè)范疇的:
Although there are differences in each of these practices, there are also similarities: they each describe variations from the conventional wisdom about how to approach software development. Whereas lean and adaptive development practices target strategic and project management, XP brings its differing world view to the realm of the developer and tester.
盡管這些實(shí)踐中存在著(zhù)差異，但是它們中也有相似的地方:它們都描述了與傳統軟件開(kāi)發(fā)不同的方法。 雖然輕量級的開(kāi)發(fā)與自適應開(kāi)發(fā)針對的是戰略與項目管理的，但是XP卻用不同的視角將開(kāi)發(fā)方法帶入了程序員與測試員的領(lǐng)域。
Much of XP is derived from good practices that have been around for a long time. "None of the ideas in XP are new. Most are as old as programming," Beck offers to readers in the preface to his book. I might differ with Beck in one respect: although the practices XP uses aren‘t new, the conceptual foundation and how they are melded together greatly enhance these "older" practices. I think there are four critical ideas to take away from XP (in addition to a number of other good ideas):
XP中許多部分其實(shí)都來(lái)自于業(yè)已存在的那些優(yōu)秀的開(kāi)發(fā)實(shí)踐。"XP中沒(méi)有一個(gè)想法是全新的。大多數想法產(chǎn)生的時(shí)間實(shí)際上和編程一樣古老"Beck在他書(shū)中的前言中這樣說(shuō)道。但是我在某一個(gè)方面考慮的也許與Beck有所不同： 盡管XP所用的實(shí)踐方式不是全新的，但是概念的建立以及它們如何融合在一起極大地增強了 這些"老"的實(shí)踐。我想(除了許多其它的好思想外，還)可以從XP中提煉出四個(gè)關(guān)鍵的思想:
But first, I discuss some XP basics: the dozen practices that define XP.
但是首先，我們來(lái)討論XP的基礎:那十二個(gè)用于XP的實(shí)踐方式。
I must admit that one thing I like about XP‘s principal figures is their lack of pretension. XP proponents are careful to articulate where they think XP is appropriate and where it is not. While practitioners like Beck and Ron Jeffries may envision that XP has wider applicability, they are generally circumspect about their claims. For example, both are clear about XP‘s applicability to small (less than 10 people), co-located teams (with which they have direct experience); they don‘t try to convince people that the practices will work for teams of 200.
我必須承認一件事情，就是我喜歡XP的原因應該是它沒(méi)有其他的那些花哨的東西。支持XP的人們總是會(huì )向你指出XP適合的地方以及他的某些局限性。而XP的實(shí)踐者Beck以及Ron Jeffties卻相信XP會(huì )有更廣泛的應用前景。他們通常對于自己的要求都是很謹慎的。例如：小的（小于10人），公司局部（他們有直接的經(jīng)驗）兩者對于XP的適應性都是很清楚的；他們并沒(méi)有試圖讓人們相信XP可以適用于一個(gè)200人的團隊。
The most prominent XP project reported on to date is the Chrysler Comprehensive Compensation system (the C3 project) that was initiated in the mid-1990s and converted to an XP project in 1997. Jeffries, one of the "Three Extremoes" (with Beck and Ward Cunningham), and I spent several hours talking about the C3 project and other XP issues at the recent Miller Freeman Software Developer conference in Washington, DC, USA.
最為著(zhù)名的XP項目是克萊斯勒綜合補償系統（稱(chēng)為C3工程），它在上個(gè)世紀的90年代中期開(kāi)始，到1997演變?yōu)閄P。Jeffries,是"終極編程三人組"之一（另外兩個(gè)是Beck同Ward Cunningham） 。我在華盛頓特區同自由軟件人談?wù)摿擞嘘P(guān)C3的以及其他與XP項目有關(guān)的東西。
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
注解： Chrysler Comprehensive Compensation system 克萊斯勒綜合補償系統
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
Originally, the C3 project was conceived as an OO programming project, specifically using Smalltalk. Beck, a well-known Smalltalk expert, was called in to consult on Smalltalk performance optimization, and the project was transformed into a pilot of OO (XP) practices after the original project was deemed unreclaimable. Beck brought in Jeffries to assist on a more full-time basis, and Jeffries worked with the C3 team until spring 1999. The initial requirements were to handle the monthly payroll of some 10,000 salaried employees. The system consists of approximately 2,000 classes and 30,000 methods and was ready within a reasonable tolerance period of the planned schedule.
最初，C3是一個(gè)基于OO（面向對象技術(shù)）的開(kāi)發(fā)項目，尤其是它采用Smaltalk語(yǔ)言進(jìn)行開(kāi)發(fā)。（Smaltalk ：Xerox公司開(kāi)發(fā)的一種高級程序設計語(yǔ)言,它支持和鼠標合用的選項屏驅動(dòng)式應用程序,有助于建立便于使用的計算機程序。）作為著(zhù)名的Smalltalk專(zhuān)家，Beck被邀請來(lái)討論有關(guān)SmalTalk性能優(yōu)化的問(wèn)題，并且在原項目被認為不可救要的時(shí)候將其變?yōu)橐粋€(gè)采用面向對象OO（XP）方法的試驗性項目。Beck并且帶來(lái)了Jeffries用于幫助那些基本的東西，Jeffries在C3組一直干到1999年的春天。最開(kāi)始的需求是要做一個(gè)對約10，000個(gè)雇員每月薪水發(fā)放進(jìn)行管理的系統。這個(gè)系統由大約2，000個(gè)類(lèi)以及30，000個(gè)方法構成，并且在計劃方面提供有合理的容忍度
As we talked, I asked Jeffries how success on the C3 project translated into XP use on other Chrysler IT projects. His grin told me all I needed to know. I‘ve been involved in enough rapid application development (RAD) projects for large IT organizations over the years to understand why success does not consistently translate into acceptance. There are always at least a hundred very good reasons why success at RAD, or XP, or lean development, or other out-of-the-box approaches doesn‘t translate into wider use -- but more on this issue later.
正向我們所談到，我問(wèn)Jeffries他怎樣成功的將C3變?yōu)閄P并應用到其他的克萊斯勒IT項目。他笑著(zhù)告訴了我。多年來(lái)我為許多大型IT組織開(kāi)發(fā)了不少RAD系統（快速原型開(kāi)發(fā)），因此我知道為什么我們無(wú)法將成功的經(jīng)驗運用于其它項目中. 對于RAD, XP, 輕量級的開(kāi)發(fā)以及其它一些未得到廣泛應用的方法, 它們成功的原因至少有一百條.
One thing to keep in mind is that XP practices are intended for use with small, co-located teams. They therefore tend toward minimalism, at least as far as artifacts other than code and test cases are concerned. The presentation of XP‘s practices have both positive and negative aspects. At one level, they sound like rules -- do this, don‘t do that. Beck explains that the practices are more like guidelines than rules, guidelines that are pliable depending on the situation. However, some, like the "40-hour week," can come off as a little preachy. Jeffries makes the point that the practices also interact, counterbalance, and reinforce each other, such that picking and choosing which to use and which to discard can be tricky.
應記住的一件事情就是我們應傾向于在小型的, 局部的團隊中運用XP。除了代碼與測試用例外, 盡量減少有些的影響。XP的實(shí)踐既有正面的表現,也有負面的。在某些方面看來(lái)，他們聽(tīng)起來(lái)就像一堆規則，要做這個(gè)，不要做那個(gè)。對此Beck解釋道, 與規則相比, XP更像是指導方針，一個(gè)靈活的依賴(lài)于具體環(huán)境的開(kāi)發(fā)方針。但是諸如"每周工作40小時(shí)"等看起來(lái)可能會(huì )感覺(jué)續續道道。Jeffries使得實(shí)踐也會(huì )互相作用的，平衡，互相加強。以至于挑選使用的同丟棄的都是棘手的事情。
The planning game. XP‘s planning approach mirrors that of most iterative RAD approaches to projects. Short, three-week cycles, frequent updates, splitting business and technical priorities, and assigning "stories" (a story defines a particular feature requirement and is displayed in a simple card format) all define XP‘s approach to planning.
計劃的制定：XP中關(guān)于制定計劃的實(shí)現方法中可以反映出大多數迭代式RAD項目的特點(diǎn)。短期的，每三周為一個(gè)循環(huán)，頻繁地更新，按優(yōu)先級劃分任務(wù)與技術(shù)， 分配stories（一個(gè)story定義了一個(gè)特殊的功能需求并以一種簡(jiǎn)單的方式記錄在卡片上），所有的這些就是構成了XP中的計劃。
Small releases. "Every release should be as small as possible, containing the most valuable business requirements," states Beck. This mirrors two of Tom Gilb‘s principles of evolutionary delivery from his book Principles of Software Engineering Management: "All large projects are capable of being divided into many useful partial result steps," and "Evolutionary steps should be delivered on the principle of the juiciest one next."
小版本："每個(gè)版本應該盡可能的小，而且包含最有商業(yè)價(jià)值的需求"，Beck如是說(shuō)。這也反映了Tom Gilb在他的<軟件工程管理原則>書(shū)中提到的關(guān)于漸進(jìn)式發(fā)布的兩點(diǎn)："所有的大的項目都可以被分為局部的, 有用的小的步驟"以及"進(jìn)化的步驟會(huì )傳遞到下一級。"
Small releases provide the sense of accomplishment that is often missing in long projects as well as more frequent (and more relevant) feedback. However, a development team needs to also consider the difference between "release" and "releasable." The cost of each release -- installation, training, conversions -- needs to be factored into whether or not the product produced at the end of a cycle is actually released to the end user or is simply declared to be in a releasable state.
小型版本的發(fā)布意味著(zhù)具有在大型項目中經(jīng)常缺少的頻繁的反饋的實(shí)現.。 然而，一個(gè)開(kāi)發(fā)小組當然需要考慮到"發(fā)布"同"可發(fā)布"的不同。無(wú)論是否是最終的版本發(fā)布還是一個(gè)簡(jiǎn)單的可發(fā)行版本的發(fā)布, 都需要付出安裝，培訓，轉化等代價(jià)。
Metaphor. XP‘s use of the terms "metaphor" and "story" take a little wearing in to become comfortable. However, both terms help make the technology more understandable in human terms, especially to clients. At one level, metaphor and architecture are synonyms -- they are both intended to provide a broad view of the project‘s goal. But architectures often get bogged down in symbols and connections. XP uses "metaphor" in an attempt to define an overall coherent theme to which both developers and business clients can relate. The metaphor describes the broad sweep of the project, while stories are used to describe individual features.
隱喻：在XP中"隱喻"以及"story"的使用可能會(huì )讓人有一點(diǎn)不舒服。但是，這些術(shù)語(yǔ)的使用可以幫助我們以一種更人性化的方式加以理解，尤其是對客戶(hù)而言。從某種程度上來(lái)說(shuō)，隱喻同體系結構是同意語(yǔ)――他們都著(zhù)重于從全局描述一個(gè)項目。但是體系結構經(jīng)常會(huì )陷于符號與連接的泥潭。而XP使用"隱喻"定義一個(gè)從開(kāi)發(fā)者到商業(yè)客戶(hù)都可聯(lián)系的全面一致的主題。隱喻用于描述項目全面的面貌，而Story用于描述個(gè)別具體的特征。
Simple design. Simple design has two parts. One, design for the functionality that has been defined, not for potential future functionality. Two, create the best design that can deliver that functionality. In other words, don‘t guess about the future: create the best (simple) design you can today. "If you believe that the future is uncertain, and you believe that you can cheaply change your mind, then putting in functionality on speculation is crazy," writes Beck. "Put in what you need when you need it."
簡(jiǎn)單的設計：簡(jiǎn)單的設計包含兩個(gè)部分。一，為已定義的功能進(jìn)行設計，而不是為潛在地未來(lái)可能的功能進(jìn)行設計。二，創(chuàng )建最佳的可以實(shí)現功能的設計。換句話(huà)說(shuō)，不用管未來(lái)會(huì )是怎樣，只創(chuàng )建一個(gè)目前為止可以實(shí)現的最好的設計。"如果你相信未來(lái)是不確定的，并且你相信你可以很方便的改變你的主意的話(huà)，那么對未來(lái)功能的考慮是危險的。"Beck寫(xiě)到。"只有在你真正需要的時(shí)候才去做"
In the early 1980s, I published an article in Datamation magazine titled "Synchronizing Data with Reality." The gist of the article was that data quality is a function of use, not capture and storage. Furthermore, I said that data that was not systematically used would rapidly go bad. Data quality is a function of systematic usage, not anticipatory design. Trying to anticipate what data we will need in the future only leads us to design for data that we will probably never use; even the data we did guess correctly on won‘t be correct anyway. XP‘s simple design approach mirrors the same concepts. As described later in this article, this doesn‘t mean that no anticipatory design ever happens; it does mean that the economics of anticipatory design changes dramatically.
在二十世紀八十年代，我發(fā)表了一篇有關(guān)自動(dòng)化資料管理的文章"實(shí)際的同步數據"文章的意思是說(shuō)數據的質(zhì)量是使用功能，不是捕捉與存儲。此外，我說(shuō)數據如果不是很系統的使用便會(huì )變壞。數據質(zhì)量是系統使用的功能，不是可預料的設計。無(wú)論預期的對還是錯，試著(zhù)設計一個(gè)我們從來(lái)都不會(huì )用到的數據，最終結果很可能我們一次也不會(huì )用到它們。XP的簡(jiǎn)單設計方法反映了相同的觀(guān)點(diǎn)。如在本文后來(lái)所描述的那樣，這并不意味著(zhù)不需要預測，而是說(shuō)為預測的內容所做的設計一旦發(fā)生變化，其導致的代價(jià)是十分巨大的。
Refactoring. If I had to pick one thing that sets XP apart from other approaches, it would be refactoring -- the ongoing redesign of software to improve its responsiveness to change. RAD approaches have often been associated with little or no design; XP should be thought of as continuous design. In times of rapid, constant change, much more attention needs to be focused on refactoring. See the sections "Refactoring" and "Data Refactoring," below.
重構：如果我不得不找出一個(gè)能夠將XP和其他方法區別開(kāi)來(lái)的東西那就是重構――不斷的軟件再設計以改進(jìn)它對于變化的反應。RAD方法常常很少甚至根本不與設計相關(guān)；XP應當被看作持續設計。當變化既快而且頻繁的時(shí)候，應投入更多的精力于重構之上。參見(jiàn)下面的"重構"和"數據重構"部分。
Testing. XP is full of interesting twists that encourage one to think -- for example, how about "Test and then code"? I‘ve worked with software companies and a few IT organizations in which programmer performance was measured on lines of code delivered and testing was measured on defects found -- neither side was motivated to reduce the number of defects prior to testing. XP uses two types of testing: unit and functional. However, the practice for unit testing involves developing the test for the feature prior to writing the code and further states that the tests should be automated. Once the code is written, it is immediately subjected to the test suite instant feedback.
測試：XP充滿(mǎn)發(fā)人深思的有趣的難題。例如：什么是"先測試后編碼"？我曾經(jīng)同軟件公司和一些IT機構一起工作，在那兒是通過(guò)代碼的行數來(lái)對程序員的績(jì)效加以考核，而測試的績(jì)效則是通過(guò)發(fā)現的缺陷的數量來(lái)考核的。這兩種方法都不能鼓勵減少測試前產(chǎn)生的缺陷的數量。XP使用兩種測試：?jiǎn)卧獪y試和功能測試。單元測試要求在寫(xiě)代碼之前就開(kāi)發(fā)出相應功能的測試方法，并并測試應當是自動(dòng)化的。代碼一完成，它就被立即用有關(guān)測試集加以測試，從而能立即得到反饋。
The most active discussion group on XP remains the Wiki exchange (XP is a piece of the overall discussion about patterns). One of the discussions centers around a lifecycle of Listen (requirements)
Pair programming. One of the few software engineering practices that enjoys near-universal acceptance (at least in theory) and has been well measured is software inspections (also referred to as reviews or walkthroughs). At their best, inspections are collaborative interactions that speed learning as much as they uncover defects. One of the lesser-known statistics about inspections is that although they are very cost effective in uncovering defects, they are even more effective at preventing defects in the first place through the team‘s ongoing learning and incorporation of better programming practices.
配對編程：軟件（還是直接用Inspection為好？）（也稱(chēng)審查或走查）也是被廣為接受（至少在理論上）和有效度量的少數軟件工程實(shí)踐之一。在最好情況下，Inspection這種協(xié)同交互的檢查能夠加速學(xué)習，同時(shí)發(fā)現缺陷。一個(gè)較少被知道的關(guān)于Inspection的統計數據是盡管它在發(fā)現缺陷方面非常有效，但通過(guò)團隊對于好的開(kāi)發(fā)實(shí)踐持續的學(xué)習和協(xié)作，可以更好的在第一時(shí)間預防缺陷。
One software company client I worked with cited an internal study that showed that the amount of time to isolate defects was 15 hours per defect with testing, 2-3 hours per defect using inspections, and 15 minutes per defect by finding the defect before it got to the inspection. The latter figure arises from the ongoing team learning engendered by regular inspections. Pair programming takes this to the next step -- rather than the incremental learning using inspections, why not continuous learning using pair programming?
一家我工作過(guò)的軟件公司客戶(hù)引用一個(gè)內部研究結果，表明在測試階段發(fā)現一個(gè)缺陷需15小時(shí)，在Inspection階段發(fā)現一個(gè)缺陷則需2－3小時(shí)，而在Inspection之前發(fā)現缺陷只需15分鐘。后面的數據來(lái)自于產(chǎn)生于常規審查的持續的團隊學(xué)習。配對編程將這個(gè)帶入下一步――與其用Inspection來(lái)遞增式學(xué)習，為什么不用配對編程來(lái)學(xué)習呢？
"Pair programming is a dialog between two people trying to simultaneously program and understand how to program better," writes Beck. Having two people sitting in front of the same terminal (one entering code or test cases, one reviewing and thinking) creates a continuous, dynamic interchange. Research conducted by Laurie Williams for her doctoral dissertation at the University of Utah confirm that pair programming‘s benefits aren‘t just wishful thinking (see Resources and References).
"配對編程是兩個(gè)人試圖同時(shí)編程和理解如何更好編程的一種對話(huà)"，Beck寫(xiě)道。讓兩個(gè)人同時(shí)坐在一臺終端前面（一個(gè)人敲代碼或測試用例，一個(gè)人審查和思考）產(chǎn)生一種持續的、動(dòng)態(tài)的交流。Williams在猶他大學(xué)進(jìn)行的博士論文研究證明了配對編程不僅僅是一種美好的想法而且確有實(shí)效。（參見(jiàn)資源和參考）
Collective ownership. XP defines collective ownership as the practice that anyone on the project team can change any of the code at any time. For many programmers, and certainly for many managers, the prospect of communal code raises concerns, ranging from "I don‘t want those bozos changing my code" to "Who do I blame when problems arise?" Collective ownership provides another level to the collaboration begun by pair programming.
代碼共享：項目組中的每個(gè)人都可以在任何時(shí)候修改其他項目成員的代碼，這就是XP中所定義的代碼共享。。對許多程序員以及經(jīng)理而言，，共有代碼的想法會(huì )引起一些疑慮，諸如"我不想讓那些笨蛋改我的代碼"，"出現問(wèn)題我應該怪誰(shuí)？"等等。共享代碼從另一個(gè)層面提供了對配對編程中協(xié)作的支持。
Pair programming encourages two people to work closely together: each drives the other a little harder to excel. Collective ownership encourages the entire team to work more closely together: each individual and each pair strives a little harder to produce high-quality designs, code, and test cases. Granted, all this forced "togetherness" may not work for every project team.
配對編程鼓勵兩個(gè)人緊密協(xié)作：每個(gè)人促使另一個(gè)更加努力以圖超越。共同所有鼓勵整個(gè)團隊更加緊密協(xié)作：每個(gè)個(gè)人和每個(gè)雙人更努力生產(chǎn)高質(zhì)量設計、代碼和測試集。當然，所有這些強迫的"共同"不一定對所有的項目組適用。
Continuous integration. Daily builds have become the norm in many software companies -- mimicking the published material on the "Microsoft" process (see, for example, Michael A. Cusumano and Richard Selby‘s Microsoft Secrets). Whereas many companies set daily builds as a minimum, XP practitioners set the daily integration as the maximum - opting for frequent builds every couple of hours. XP‘s feedback cycles are quick: develop the test case, code, integrate (build), and test.
經(jīng)常集成：每日構造（build）在許多公司已經(jīng)成為規范，模仿有關(guān)"微軟"流程的出版物上的東西。（參見(jiàn)，例如，Michael A. Cusumano和Richard Selby的Microsoft Secrets）許多公司將每日編鏈作為最小要求，XP實(shí)踐者將每日集成作為最大要求，選擇每?jì)蓚€(gè)小時(shí)一次的頻繁編鏈。XP的反饋周期迅速：開(kāi)發(fā)測試集、編碼、集成（編鏈）和測試。
The perils of integration defects have been understood for many years, but we haven‘t always had the tools and practices to put that knowledge to good use. XP not only reminds us of the potential for serious integration errors, but provides a revised perspective on practices and tools.
對于集成缺陷危險的認識已有多年了，但我們并不是總能擁有相應工具和時(shí)間將這些知識好好用起來(lái)。XP不僅提醒我們有可能有嚴重的集成錯誤，而且從實(shí)踐與工具的角度提供了一種新的認識。
40-hour week. Some of XP‘s 12 practices are principles, while others, such as the 40-hour practice, sound more like rules. I agree with XP‘s sentiments here; I just don‘t think work hours define the issue. I would prefer a statement like, "Don‘t burn out the troops," rather than a 40-hour rule. There are situations in which working 40 hours is pure drudgery and others in which the team has to be pried away from a 60-hour work week.
每周只干40小時(shí)：XP有12條實(shí)踐的基本原則，但是有時(shí)候，比如象每周只干40小時(shí)的原則，聽(tīng)起來(lái)更象規則。我同意XP中的觀(guān)點(diǎn)。只是不認為有必要硬性規定工作小時(shí)數。相比起來(lái)，我更喜歡一句類(lèi)似于"不要把部隊燒光"的話(huà)。在一些情況下，工作40小時(shí)太勞累，而在另外一些組里，甚至需要一周60個(gè)工作時(shí)。
Jeffries provided additional thoughts on overtime. "What we say is that overtime is defined as time in the office when you don‘t want to be there. And that you should work no more than one week of overtime. If you go beyond that, there‘s something wrong -- and you‘re tiring out and probably doing worse than if you were on a normal schedule. I agree with you on the sentiment about the 60- hour work week. When we were young and eager, they were probably okay. It‘s the dragging weeks to watch for."
Jeffries提供了關(guān)于加班的更多思索："我們說(shuō)的是加班被定義為我們不想在辦公室的時(shí)候呆在辦公室。而且你不應當加班超過(guò)一周。如果你超過(guò)了，就有什么東西出了問(wèn)題――你過(guò)于勞累，有可能比你按時(shí)下班干的還差。我同意你關(guān)于60工作時(shí)一周的感受。在我們年輕和滿(mǎn)身干勁的時(shí)候，這也許沒(méi)問(wèn)題。值得注意的是拖沓的一周又一周。"
I don‘t think the number of hours makes much difference. What defines the difference is volunteered commitment. Do people want to come to work? Do they anticipate each day with great relish? People have to come to work, but they perform great feats by being committed to the project, and commitment only arises from a sense of purpose.
我不認為一周的工作時(shí)間會(huì )造成大的差別。決定區別的是自愿的貢獻。人們愿意來(lái)工作嗎？他們對每一天都充滿(mǎn)干勁嗎？人們必須來(lái)工作，但是他們通過(guò)投入項目來(lái)創(chuàng )造巨大成就，而投入僅僅產(chǎn)生于目標感。
On-site customer. This practice corresponds to one of the oldest cries in software development -- user involvement. XP, as with every other rapid development approach, calls for ongoing, on-site user involvement with the project team.
現場(chǎng)客戶(hù)：這就對應到了最初軟件開(kāi)發(fā)時(shí)所提出的問(wèn)題――用戶(hù)參與。XP，同其他的快速開(kāi)發(fā)一樣，要求客戶(hù)在現場(chǎng)持續地參與到項目組中。
Coding standards. XP practices are supportive of each other. For example, if you do pair programming and let anyone modify the communal code, then coding standards would seem to be a necessity.
編碼標準：XP實(shí)踐相互支持。例如，如果你進(jìn)行配對編程并讓他人修改共有代碼，那么編碼標準看起來(lái)就是必須的。
On Saturday, 1 January 2000, the Wall Street Journal (you know, the "Monday through Friday" newspaper) published a special 58-page millennial edition. The introduction to the Industry & Economics section, titled "So Long Supply and Demand: There‘s a new economy out there -- and it looks nothing like the old one," was written by Tom Petzinger. "The bottom line: creativity is overtaking capital as the principal elixir of growth," Petzinger states.
在2000年一月一日周六時(shí)候，華爾街日報（周一到周五出版的）用一個(gè)58頁(yè)的版面發(fā)布了一個(gè)千僖年紀念版。在篇首的有關(guān)工業(yè)及金融的介紹里標著(zhù)Tom Petzinger.寫(xiě)的："長(cháng)久的需求與召喚：經(jīng)濟新的增長(cháng)點(diǎn)――顯得同以往不同"。底下的一行 Petzinger 寫(xiě)著(zhù)："創(chuàng )造性正代替‘萬(wàn)金藥‘的資本在成為首要的因素"。
Petzinger isn‘t talking about a handful of creative geniuses, but the creativity of groups -- from teams to departments to companies. Once we leave the realm of the single creative genius, creativity becomes a function of the environment and how people interact and collaborate to produce results. If your company‘s fundamental principles point to software development as a statistically repeatable, rigorous, engineering process, then XP is probably not for you. Although XP contains certain rigorous practices, its intent is to foster creativity and communication.
Petzinger并沒(méi)有談?wù)撋贁堤觳诺膭?chuàng )造性，而是談了以下群體的創(chuàng )造性――從組到部門(mén)。一旦我們撇下天才們的個(gè)體創(chuàng )造，創(chuàng )造性就是環(huán)境的功能，而人們運用并互相協(xié)助而達到我們的結果的能力。如果你的公司認為軟件開(kāi)發(fā)只是一個(gè)統計上的重復試驗，刻板的，技術(shù)性的過(guò)程，那么XP對于您也許并不合適。雖然XP中也有技術(shù)實(shí)踐里的嚴格，但是XP本身是追求"創(chuàng )造"與"溝通"。
Environments are driven by values and principles. XP (or the other practices mentioned in this issue) may or may not work in your organization, but, ultimately, success won‘t depend on using 40-hour work weeks or pair programming -- it will depend on whether or not the values and principles of XP align with those of your organization.
環(huán)境是靠?jì)r(jià)值同規則共同驅動(dòng)的系統。XP（或者其他類(lèi)似的）可能、也可能不適合您的單位，可是，應該澄清的是成功并不是只靠每周40小時(shí)的瘋狂工作或者配對編程，也不是依靠XP之中應用在您單位中的價(jià)值或者是規則。
Beck identifies four values, five fundamental principles, and ten secondary principles -- but I‘ll mention five that should provide enough background.
Beck指出了四個(gè)價(jià)值，五個(gè)基本規則，以及十個(gè)輔助規則--不過(guò)我要提到是這五個(gè)規則。
Communication. So, what‘s new here? It depends on your perspective. XP focuses on building a person-to-person, mutual understanding of the problem environment through minimal formal documentation and maximum face-to-face interaction. "Problems with projects can invariably be traced back to somebody not talking to somebody else about something important," Beck says. XP‘s practices are designed to encourage interaction - developer to developer, developer to customer.
溝通：是的，溝通，可是，這里似乎沒(méi)有新的東西在里面？溝通主要是看人們自己的看法，XP構建的基本是人與人，通過(guò)最簡(jiǎn)潔的文檔，最直接的面對面溝通獲得對任務(wù)環(huán)境的理解。
Simplicity. XP asks of each team member, "What is the simplest thing that could possibly work?" Make it simple today, and create an environment in which the cost of change tomorrow is low.
簡(jiǎn)潔：XP問(wèn)每個(gè)開(kāi)發(fā)組成員："可能實(shí)現的最簡(jiǎn)潔的方法是什么？"。今天所保持的簡(jiǎn)潔，可以為降低明天由于變更所帶來(lái)的費用
Feedback. "Optimism is an occupational hazard of programming," says Beck. "Feedback is the treatment." Whether it‘s hourly builds or frequent functionality testing with customers, XP embraces change by constant feedback. Although every approach to software development advocates feedback -- even the much-maligned waterfall model -- the difference is that XP practitioners understand that feedback is more important than feedforward. Whether it‘s fixing an object that failed a test case or refactoring a design that is resisting a change, high-change environments require a much different understanding of feedback.
反饋：Beck說(shuō)："對于編程而言，樂(lè )觀(guān)主義是一種冒險。"，"而反饋則是相應的解決良藥。"無(wú)論是用反復的構建或者頻繁的用戶(hù)功能測試，XP都能不斷地接收到反饋。雖然每次對軟件開(kāi)發(fā)策略進(jìn)行研討時(shí)，我們都會(huì )說(shuō)及反饋--即使是非常有害的瀑布模型--不同的是XP的實(shí)踐者認為反饋比起前饋(feedforward)來(lái)更為重要。無(wú)論是對測試失敗的代碼進(jìn)行修改或者是對用戶(hù)拒收的軟件從新返工，開(kāi)發(fā)環(huán)境的快速變化要求開(kāi)發(fā)人員對反饋有更好的認識。
Courage. Whether it‘s a CMM practice or an XP practice that defines your discipline, discipline requires courage. Many define courage as doing what‘s right, even when pressured to do something else. Developers often cite the pressure to ship a buggy product and the courage to resist. However, the deeper issues can involve legitimate differences of opinion over what is right. Often, people don‘t lack courage -- they lack conviction, which puts us right back to other values. If a team‘s values aren‘t aligned, the team won‘t be convinced that some practice is "right," and, without conviction, courage doesn‘t seem so important. It‘s hard to work up the energy to fight for something you don‘t believe in.
勇氣：無(wú)論您是使用CMM方法或者是XP的方法，方法使用的本身是要求勇氣的。許多地方將勇氣定義為做某件事情的權利，即使被迫去做其他的事情。開(kāi)發(fā)人員經(jīng)常借口壓力而發(fā)出帶有許多缺陷的產(chǎn)品，并對此加以堅持。然而，更進(jìn)一步的應該包括其他的正確的不同的東西進(jìn)來(lái)。通常，人們并不是缺少勇氣，而是缺少一種讓正確實(shí)踐獲得承認的理由，而且，也不堅信這點(diǎn)，勇氣不像看起來(lái)那么重要。而如果你對之沒(méi)有信心，那么是很難盡力工作的。
"Courage isn‘t just about having the discipline," says Jeffries. "It is also a resultant value. If you do the practices that are based on communication, simplicity, and feedback, you are given courage, the confidence to go ahead in a lightweight manner," as opposed to being weighted down by the more cumbersome, design-heavy practices.
"勇氣并不只是方法"，Jeffries說(shuō)道，它是一種最終的價(jià)值。如果你在一種基于"溝通"，"簡(jiǎn)潔"，"反饋"的模式下工作，你將獲得勇氣，越往前信賴(lài)就越不重要。
Quality work. Okay, all of you out there, please raise your hand if you advocate poor-quality work. Whether you are a proponent of the Rational Unified Process, CMM, or XP, the real issues are "How do you define quality?" and "What actions do you think deliver high quality?" Defining quality as "no defects" provides one perspective on the question; Jerry Weinberg‘s definition, "Quality is value to some person," provides another. I get weary of methodologists who use the "hacker" label to ward off the intrusion of approaches like XP and lean development. It seems unproductive to return the favor. Let‘s concede that all these approaches are based on the fundamental principle that individuals want to do a good, high-quality job; what "quality" means and how to achieve it -- now there‘s the gist of the real debate!
優(yōu)質(zhì)的工作：好，如果你們中有贊成劣質(zhì)工作的話(huà)，那么請舉手離開(kāi)這兒吧。不論你是一個(gè)Rational Unified Process，CMM，或是XP的贊成者，其本質(zhì)的觀(guān)點(diǎn)"你怎樣定義質(zhì)量"與"什么樣的活動(dòng)會(huì )贏(yíng)得高質(zhì)量"，定義"無(wú)缺點(diǎn)"質(zhì)量是這個(gè)問(wèn)題的一個(gè)方向。Jerry Weinberg的定義是"質(zhì)量是對多數人有益"
One area in which XP (at least as articulated in Beck‘s book) falls short is management, understandable for a practice oriented toward both small project teams and programming. As Beck puts it, "Perhaps the most important job for the coach is the acquisition of toys and food." (Coaching is one of Beck‘s components of management strategy.)
對于針對小型項目以及編程而言，在XP（至少是Beck的書(shū)中）里對管理的欠缺是可以理解的，。就如Beck寫(xiě)的，"對于教練(coach)來(lái)說(shuō)，或許最重要的工作就是獲得玩具同食物"（指導是Beck的管理戰略中的一個(gè)組成部分）
With many programmers, their recommended management strategy seems to be: get out of the way. The underlying assumption? Getting out of the way will create a collaborative environment. Steeped in the tradition of task-based project management, this assumption seems valid. However, in my experience, creating and maintaining highly functional collaborative environments challenges management far beyond making up task lists and checking off their completion.
同許多的程序員一樣，他們推薦的管理策略像是：躲避。下面的假定呢？躲避會(huì )建立一個(gè)協(xié)作的環(huán)境，在傳統的基于任務(wù)的管理里，這個(gè)假定是有效的。然而，根據我的經(jīng)驗，創(chuàng )造并維持一個(gè)協(xié)作的環(huán)境會(huì )挑戰管理遠離編制任務(wù)列表以及檢查。
| Figure 1 -- Historical lifecycle change costs.  Figure 2 -- Comtemporary lifecycle change costs. |
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從他的早期的著(zhù)作開(kāi)始，就不斷向那些軟件工程中的一些"古訓"發(fā)出挑戰。從19世紀70年代中期的結構化方法，以至后來(lái)的那些更復雜的方法，他們都基于如圖1所示的那個(gè)"事實(shí)"，在整個(gè)80年代，我必須了解、使用、討論、實(shí)施這些方法。
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卻給我們提了一個(gè)問(wèn)題，那些在70年代和80年代也許還能起到效果的方法，他們的經(jīng)費開(kāi)銷(xiāo)狀況（如圖1）現在已經(jīng)發(fā)生了變化（如圖2），也就是說(shuō)，維護的成本（也可以等價(jià)為不斷發(fā)生的變化）降低了，而不是越來(lái)越高。實(shí)際上，圖2所示的開(kāi)銷(xiāo)情況在當今是否是事實(shí)其實(shí)并不重要，重要的是我們必須認識到，如果圖1的現象還在繼續重演的話(huà)，我們只有死路一條，因為當今時(shí)代變化實(shí)在太快了（也就是說(shuō)維護的成本將是一個(gè)天價(jià)）。
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軸通常用來(lái)表示在開(kāi)發(fā)周期的后期發(fā)現錯誤后需要花費的改錯成本?？墒?，這正驗證了一個(gè)假設，即后期所有需要做的開(kāi)動(dòng)均來(lái)自前期的一個(gè)錯誤，比方說(shuō)一個(gè)設計缺陷。從這一點(diǎn)來(lái)看，傳統方法太依賴(lài)于在軟件生命周期的早期"不出錯"。但是在當今瞬息萬(wàn)變的環(huán)境中，我們不能完全預防住那些我們預測不到的東西--即由應用需求不斷增長(cháng)而帶來(lái)的變化，并且這種變化在早期不可能遇見(jiàn)并加以預防。因此，雖然我們要盡可能在早期做出某些應付變化的預防措施，但是更重要的是我們要減少后期改變所帶來(lái)的開(kāi)銷(xiāo)。正如 Alistai Cockburn 所指出的，需要高成本的圖1所示的那種改正缺陷方法，正好從節省開(kāi)支的角度給了一些實(shí)用的方法（如配對編程）一個(gè)好的理由。
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雜志中，我打算把討論定位于項目或應用軟件層次上的變化--對類(lèi)似操作系統、編程語(yǔ)言、數據庫、組件等的討論不在討論之列。（關(guān)于軟件結構的靈活性，可以參考ADS雜志1999年6月的那期）另外，讓我們進(jìn)一步做個(gè)簡(jiǎn)化，即假定軟件的用戶(hù)需求已經(jīng)確定。
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.
我們的目標是既能快速不斷的發(fā)布新功能，同時(shí)又要讓軟件的設計易于更改。即使是在快速發(fā)布這個(gè)目標下，仍然需要在"快速發(fā)布但Bug叢生"和"面面俱到但曠日持久"之間進(jìn)行取舍。因此，讓我再簡(jiǎn)化一下我們要討論的問(wèn)題，我們假定我們已經(jīng)在設計、編碼和測試這三者之間取得了合理的平衡。
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?
在上面這些簡(jiǎn)化的基礎上，還留有一個(gè)尾巴：我們在設計時(shí)對于未知的未來(lái)要看多遠？現在的設計已經(jīng)實(shí)現了我們現在想到的一些功能。具有預見(jiàn)性的設計可以使未來(lái)的需求更快的獲得實(shí)現，也就是說(shuō)預見(jiàn)性設計方法在以現在的時(shí)間換取未來(lái)的時(shí)間，如果一點(diǎn)點(diǎn)現在的時(shí)間可以換來(lái)未來(lái)節約大量時(shí)間，當然是劃算的。但是這種建設怎么才能成為現實(shí)呢？也許未來(lái)出了問(wèn)題就整個(gè)重新設計一遍也不慢，那又何必現在瞎猜呢？
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.
這就是我們?yōu)槭裁匆岢鲋貥嫷脑?。重構，Martin Fowler說(shuō)過(guò)，是不改變軟件對外表現但是重整內務(wù)的一種改進(jìn)。XP方法的支持者在變化的環(huán)境中實(shí)踐了連續的、增量式的重構方法。如果變化是不斷演化的的，那就不可能存在什么一步到位的設計方法。說(shuō)白了，如果變化不可預測--正如當今社會(huì )的情況--過(guò)多的在設計時(shí)考慮以后可能的變化，完全是一種浪費。
 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給出的是互聯(lián)網(wǎng)時(shí)代到來(lái)之前的情況。由于變化的速度慢（圖中由天平的支點(diǎn)比較靠左來(lái)表示），早期的預測多一些是合理的。但是在圖4中，由于變化速度變快樂(lè )，設計時(shí)預測太多是得不償失的，這種情況正是現在許多系統所面臨的。
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.
在一個(gè)長(cháng)期項目中，檢驗一個(gè)設計是否具有很好的靈活性是通過(guò)變化需求，同時(shí)看看原設計能否很容易的實(shí)現新變化的需求。這種傳統的"先設計，再維護"策略的最大問(wèn)題在于軟件系統存在非常大的熵（極易變化，沒(méi)有規律）。一個(gè)系統隨著(zhù)時(shí)間的推移，維護、改錯、打補丁、增強功能等工作會(huì )使系統的熵越來(lái)越大?，F在由于外部環(huán)境變化加快，情況正越來(lái)越糟。不過(guò)，現在的重構技術(shù)也不是第一個(gè)試圖解決這個(gè)問(wèn)題的方法。早在所謂的"黑暗時(shí)期"（circa 1986），Dave Higgins 就寫(xiě)過(guò)一本名為"Data Structured Software Maintenance"的書(shū)，該書(shū)指出了由于隨著(zhù)時(shí)間的推移變化的累計影響不斷增大，維護所需要的開(kāi)銷(xiāo)也將越來(lái)說(shuō)龐大，Higgins 提出了一種新的設計方法（the Warnier/Orr Approach）用于阻止系統的熵增大所帶來(lái)的負面影響，該方法的思想是在維護過(guò)程中有系統的對程序進(jìn)行重新設計。
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 的方法首先為程序改如何設計設定一種模式（雖然那時(shí)還沒(méi)有模式這個(gè)提法），然后在細致的代碼設計與"好"的模式之間建立一種映射，程序員即根據這種映射關(guān)系來(lái)理解系統并修改程序，使修改的結果更接近于那個(gè)模式。使用 Higgins 這個(gè)方法可以通過(guò)維護抵消系統誰(shuí)時(shí)間而熵增大的趨勢。Higgins 說(shuō)："該方法的目標并不是重寫(xiě)整個(gè)系統，而只是重寫(xiě)那些根據需要必須增強的部分。"
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.
雖然這種原始的"重構"技術(shù)并沒(méi)有被廣泛的實(shí)踐檢驗，其思想與現在的重構還是相通的，只不過(guò)現在的需求變化更快、更大。不過(guò)有兩個(gè)東西驅動(dòng)、提高了現代的重構技術(shù)：一是更好的程序設計語(yǔ)言和開(kāi)發(fā)工具；二是更快的變化需求。
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（快速原型開(kāi)發(fā)）方法中還有另一種應付變化的辦法：代碼拋棄思想。這個(gè)思想認為環(huán)境和需求變化太快，因此我們唯一的辦法只能是快速編寫(xiě)新代碼，并且也快速的拋棄老代碼。我們認為這不是長(cháng)久之計。
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)，或者說(shuō)與設計模式的使用密切相關(guān)。Erich Gamma, Richard Helm, Ralph Johnson, 和 John Vlissides合著(zhù)的《 Design Patterns: Elements of Reusable Object-Oriented 》一書(shū)為設計模式做出了奠基性的工作。正如Larry Constantine 和Ed Yourdon 所倡導的結構化設計一樣，設計模式對當代的面向對象技術(shù)程序設計做出了巨大的貢獻，為開(kāi)發(fā)人員帶來(lái)了福音。通過(guò)設計模式，程序的結構的比以往更為有效。
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)在面對高速變化環(huán)境時(shí)的適應能力方面的差別是客觀(guān)的話(huà)，初始設計的質(zhì)量則顯的尤為重要。通過(guò)提供過(guò)去已被證明是有效的模式，設計模式(Design patterns)提供了一種提高初始設計質(zhì)量的方法。
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.
現在，也許你會(huì )問(wèn)，為什么還需要一本獨立講重構的書(shū)呢？難道我們不可以只使用設計模式來(lái)重新設計嗎？可以，也不可以。正如所有的開(kāi)發(fā)人員(包括管理者)都知道，修改原有的程序代碼是一件棘手的事。development folklore年刊上有一句話(huà)，"if it ain‘t broke,don‘t fix it".然而，正如Fowler所提到的，"程序也許還沒(méi)有‘壞掉‘，但卻造成了潛在的危害." 害怕對那些還能"工作"的代碼重新構造實(shí)際上只會(huì )加劇代碼性能的衰退。同時(shí)，Fowler也清楚的認識到："在軟件重構之前，需要找到安全的做法……我把這些安全的步驟寫(xiě)進(jìn)了目錄"。Fowler所寫(xiě)的<>,不僅編錄了如何對以前的（差的）代碼和以后的（基于模式設計的較好）的代碼進(jìn)行重構的方法，而且也包含了代碼分割重構的步驟。這些步驟減少了在重構過(guò)程中出現差錯的機會(huì )。
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"方法來(lái)描述重構，也就是說(shuō), 添加新的功能與重構是兩種不同的行為。在本質(zhì)上，重構不改變軟件可見(jiàn)的外部功能，它只是增強了軟件的內部結構。當有新的功能需要添加時(shí)，第一步常是對軟件進(jìn)行重構，使添加更簡(jiǎn)化。事實(shí)上，這種添加的新功能為重構提供著(zhù)推動(dòng)力。
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）式的再設計，"沒(méi)有重構，程序設計會(huì ) 腐爛"，Fowler寫(xiě)到," 結構性的缺陷會(huì )帶來(lái)累積效應 "。歷史上，我們對軟件維護的方法是"quick and dirty"(快速但不徹底的?)，致使一些初始設計工作做的好的項目，隨著(zhù)時(shí)間推移，也會(huì )"退化"（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 顯示了沒(méi)有重構時(shí)的情況：因為軟件是如此的不可靠，升級維護費用變的讓人望而卻步，于是巨型(monumental)設計(或替換)成了唯一選擇，項目的風(fēng)險，至少是投入上，變的越來(lái)越大。圖 5也顯示，在80年代，軟件的生存期大約要10年，而在今天需求的快速變化加劇了軟件的腐爛。舉個(gè)例子，許多90年代初一窩蜂做出來(lái)的C/S應用軟件在今天比80年代留下來(lái)的大型機軟件的維護費用還要高的多。
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和重構思想吸引我的一點(diǎn)是他們能夠清楚認識到所要考慮實(shí)施問(wèn)題的邊界條件(boundary conditions).例如，Fowler寫(xiě)了一章"Problems with Refactoring".其中首要的問(wèn)題就是數據庫的重構。正如書(shū)的副標題所示，Fowler的目標是為了提高代碼質(zhì)量。為此，我咨詢(xún)了一些在數據重構（或者用其他的術(shù)語(yǔ)）方面有較深研究的人。以下關(guān)于數據重構部分由Ken Orr所寫(xiě)。
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 要我講一講重構時(shí)，我問(wèn)他重構究竟意味著(zhù)什么。對我來(lái)說(shuō)，把它歸納為以下簡(jiǎn)單的幾點(diǎn)：
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.
在過(guò)去幾年中，Jim和我一起工作，共同研究各種系統方法學(xué)(systems methodologies)，發(fā)現所有的方法學(xué)與重構思想(refactoring philosophy)有著(zhù)一致的地方。70年代，我們建立了一種基于數據結構的方法學(xué)。其主要思想是：在知道了人們的需求后，逆向工作，設計一個(gè)僅含必需數據的數據庫，然后再確定更新數據庫必需的輸入數據，產(chǎn)生需要的輸出數據。
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.
從輸出結果逆向工程到數據庫再到輸入來(lái)建構系統的方法被證明是一種非常有效和有效率的系統開(kāi)發(fā)方法。幾乎在關(guān)系數據庫開(kāi)始流行的同時(shí)，這種方法也發(fā)展了起來(lái)。使我們能夠建立起運作良好，規范化的數據庫。除此之外，這種思想也適用于創(chuàng )建最小系統(minimal systems).事實(shí)上，我們的一個(gè)客戶(hù)在重建一個(gè)系統時(shí)已經(jīng)使用了這種方法并取得了成功。該客戶(hù)從輸出入手，通過(guò)逆向工程設計了一個(gè)滿(mǎn)足最小輸入需求的最小數據庫。
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 ）。這是一個(gè)大的突破。開(kāi)發(fā)人員開(kāi)始逐漸認識到建立最小系統有著(zhù)巨大的優(yōu)勢：系統更小因而可以更快的實(shí)現；功能單一更能適應變化。
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?)
然而，創(chuàng )建最小系統并不符合許多分析員和程序員們的想法，不管有多遙遠，他們總認為自己可以超前思考并預見(jiàn)到未來(lái)的需求。我認為這源于軟件難于維護的原因。維護一個(gè)大的系統是如此的困難并充斥著(zhù)問(wèn)題，以致于許多分析員和程序員寧愿在系統開(kāi)發(fā)的前期花費大量的精力來(lái)設計一個(gè)"完善"的系統，以求一勞永逸。然而事實(shí)證明，預測未來(lái)是徒勞的。不論我們有多聰明，思想有多超前，總會(huì )有一些不曾預料到的需求出現。（有多少人能夠在10年前就將基于internet的電子商務(wù)作為未來(lái)的需求寫(xiě)入自己的軟件）
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.
最后，維護如此困難的原因之一在于，當改變數據庫設計時(shí)，其他的問(wèn)題都會(huì )接踵而來(lái)。在大多數開(kāi)發(fā)人員看來(lái)，一旦設計好數據庫并在此基礎上開(kāi)始了編碼以后，再去改變數據庫的設計幾乎是不可能的。在某種程度上，設計數據庫就好比建造系統的地基：一旦你把混凝土灌了進(jìn)去，你就沒(méi)辦法再去改變它。因此，除非不可避免，大型系統中的數據庫極少會(huì )發(fā)生大的改動(dòng)。人們不能把重新設計數據庫僅僅當成系統維護的普通一部分。否則的話(huà)，對系統進(jìn)行大的改動(dòng)會(huì )變的難以想象的困難。
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和我永遠都不會(huì )承認一旦系統開(kāi)始運行就不能再改變數據庫設計的觀(guān)點(diǎn).我們認為,如果你想使系統保持最精簡(jiǎn)的狀態(tài),就必須要把所要做的變化或新的功能引入到系統中并重復基本的開(kāi)發(fā)過(guò)程,使新的需求和舊的需求融合在一起而成為一個(gè)新的系統.你可能會(huì )說(shuō)我們所作的就是數據重構,可我們從來(lái)不那么說(shuō).
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.
這么做的好處是顯而易見(jiàn)的.首先,開(kāi)發(fā)一個(gè)新系統和維護或對舊系統統進(jìn)行較大改造的區別并不是很大.這就意味著(zhù)管理一個(gè)項目和培訓工作將大大減少.同時(shí),也將減少開(kāi)發(fā)時(shí)間,這是因為我們對變化的處理方式不同，一個(gè)是‘built in‘(建立在變化之上),另一個(gè)是‘a(chǎn)dding 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.
在過(guò)去的幾年里，我們建立了一種方法（結構化系統設計方法或Warnier-Orr法）并且培訓了數以千計的系統分析員和編程人員。即便我們在定義了足夠詳細的各種說(shuō)明后有可能用CASE工具實(shí)現大部分工作，但開(kāi)發(fā)過(guò)程仍需要大量的手工工作。
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.
為了縮短開(kāi)發(fā)時(shí)間，南美的一組系統開(kāi)發(fā)人員在80年代年開(kāi)發(fā)出了數據重構自動(dòng)化工具。由Breogán Gonda 和 Nicolás Jodal領(lǐng)導的公司開(kāi)發(fā)了一種名叫GeneXus的工具，這正是我們在70年代所構想要的。他們創(chuàng )建的方法使我們在輸入數據結構以后，系統能夠自動(dòng)為你創(chuàng )建規范的數據庫并產(chǎn)生瀏覽、更新和輸出數據的代碼。
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.
這就使事情簡(jiǎn)單了，這種工具使得當用戶(hù)的需求或系統的要求改變后只需要修改原有的定義，重新編譯，就能夠重新設計數據庫以適應新的需求，并產(chǎn)生僅僅受數據庫修改影響而需要改變的代碼。這就是基于數據的閉環(huán)的重構過(guò)程。
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使我們認識到重構能構給我們帶來(lái)的真正的東西。就我的經(jīng)驗而言，這使開(kāi)發(fā)人員從對未來(lái)需求的擔憂(yōu)中解脫出來(lái)，從而能夠使開(kāi)發(fā)人員僅僅定義他們所知道的并快速的實(shí)現所定義的所有內容。因此，當系統的需求更改以后，他們只須簡(jiǎn)單的加入那些修改，重新編譯，就可以得到一個(gè)新的、完全集成的、滿(mǎn)足新的需求的最小系統。
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.
重構正在逐漸變成一個(gè)時(shí)髦的詞語(yǔ)。與所有的時(shí)髦的東西一樣，既有好的一面，也有壞的一面。好的一面是：如果能夠正確的實(shí)施，重構使我們有可能快速構建健壯的系統。壞的一方面是：我們不得不重新考慮如何進(jìn)行開(kāi)發(fā)。原先采用的所有開(kāi)發(fā)和管理策略需要重新考慮。我們必須了解交互式的、增量的開(kāi)發(fā)方法；我們還必須習慣于使我們能夠成功的模式化的開(kāi)發(fā)方法和使用工具來(lái)完成系統開(kāi)發(fā)工作中那些復雜的工作（數據庫設計和代碼生成）。
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使開(kāi)發(fā)產(chǎn)生革命性的變化。90年代，對象和OO方法也使開(kāi)發(fā)產(chǎn)生革命性的變化。這些技術(shù)都沒(méi)有像達到期望的效果。但現在，像GeneXus這樣的工具切切實(shí)實(shí)的做到了80年代人們所期望的東西。確實(shí)有可能在給定系統需求后自動(dòng)進(jìn)行數據庫設計，生成一種實(shí)際工作的商用關(guān)系型數據庫（Oracle, DB2, Informix, MS SQL Server, and Access），并產(chǎn)生能夠瀏覽、更新和輸出數據庫中數據的不同語(yǔ)言（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.
新的系統開(kāi)發(fā)方法能夠使我們有更多的時(shí)間和用戶(hù)交流，分析用戶(hù)的需求，讓用戶(hù)選擇不同的交互界面，這在只憑自己來(lái)完成所有事情的時(shí)侯是不可能的。但是并不是所有人都喜歡這一開(kāi)發(fā)方法。一個(gè)是因為這將很大程度上撥開(kāi)開(kāi)發(fā)過(guò)程的神秘面紗。另一個(gè)是因為這也給快速開(kāi)發(fā)增加了壓力。
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時(shí)代已經(jīng)不可能再建立簡(jiǎn)單、精簡(jiǎn)的系統的時(shí)侯，那么告訴他們Internet是速度和服務(wù)的天下，告訴他們重構不僅僅是在21世紀建立這樣系統的最好方法，也是唯一的方法。
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.
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顧問(wèn)組工作時(shí)，為OO（面向對象）的開(kāi)發(fā)制訂了一套工作方法。IBM認為不管白貓黑貓，抓的到老鼠就是好貓。Cockburn 深入接觸許多開(kāi)發(fā)小組，寫(xiě)下了他們認為導致項目成功或者失敗的關(guān)鍵之處。結果讓人大吃一驚。以下內容是由 Cockburn寫(xiě)的，基于他的含有極少方法論的"實(shí)戰工作"書(shū) 。
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的研究組里，開(kāi)發(fā)小組要向以前成功的小組"道歉"，因為他們沒(méi)有遵守一道正式的工序， 因為他們沒(méi)有用一個(gè)高科技的CASE工具，又或者"僅僅"因為他們坐在一起，討論他們下步 該怎么做。 同時(shí)，一些失敗的小組覺(jué)得非常迷惑，盡管他們使用了正式的工序，他們還是 失敗了--也許是遵守這些工序還遵守的不夠好？后來(lái)我開(kāi)始碰到一些成功的小組，他們宣稱(chēng) 正是因為沒(méi)有陷于花里胡哨的過(guò)程和可發(fā)布性，而是大家坐在一起，從而使得他們可以 更容易的加以討論并且經(jīng)常交換測試后的軟件，最終才得以成功。
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.
盡可能在你的范圍內，用面對面的溝通來(lái)代替寫(xiě)文檔，從而可以減少對寫(xiě)好了的工作產(chǎn)品的依賴(lài)，并 增大發(fā)布系統的可能性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.
越是經(jīng)常發(fā)布正在運行著(zhù)并且經(jīng)過(guò)測試的系統片段，就越能讓你減少對寫(xiě)好的"約定"標記的依賴(lài)，越能增大最終發(fā)布系統的可能性
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.
應當以人性的方式加以溝通。即使是對內向的程序員來(lái)說(shuō)，采用不拘禮節的面對面的交流，都比采用寫(xiě)在紙上的文檔進(jìn)行溝通效果要好。從成本和時(shí)間上來(lái)看，寫(xiě)文章總比在白板上討論耗費更多的時(shí)間，而且溝通的效果也更差。
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.
那些寫(xiě)好的而且評審過(guò)的需求和設計文檔，只是"承諾"了要做什么，我們可以將其作為項目進(jìn)度的標志 使用。有很多進(jìn)度標志在最初設立時(shí)是好的。然而，更準確的進(jìn)度標志應該是運行測試后的代碼。因為這不是預先承諾的標志，而是真正完成的標志。
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?
最近，一個(gè)銀行的IT部決定小試一下以上結果。他們啟動(dòng)一個(gè)小項目，使用簡(jiǎn)單的把三個(gè)人放在一個(gè)房間里的方法，讓他們自生自滅。令人驚奇的是，這個(gè)小組及時(shí)的、優(yōu)秀的發(fā)布了系統。銀行的管理層覺(jué)得有點(diǎn)困惑。一定不會(huì )這么簡(jiǎn)單的吧？
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:
當然不是如此簡(jiǎn)單。另外一個(gè)采訪(fǎng)了所有其他項目后得到的結論是：不同項目有不同的需要。這是非常明顯的不依賴(lài)于方法論的（不知道怎的）。當然，如果你的項目只需要3到6個(gè)人，只要讓他們在一個(gè)房間里就可以了。但如果你有45或者100個(gè)人，這就沒(méi)用了。如果你要通過(guò)食物藥品管理部門(mén)的過(guò)程檢驗，你就不能這樣開(kāi)始。如果你想把我用火箭發(fā)射到火星上去，我建議千萬(wàn)不要嘗試。我們必須記住團隊的大小和項目的需求這類(lèi)因數：
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.
根據收集到的有關(guān)因素總結出的結論如圖Figure 6所示。它顯示了影響選擇不同方法論的三個(gè)因數：溝通難度（由成員的數量決定），系統關(guān)鍵程序，以及項目的優(yōu)先級。
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軸上的部分（通常的只是開(kāi)發(fā)組）。如果是一個(gè)分布的開(kāi)發(fā)項目，因為面對面溝通的機會(huì )減少，向右移動(dòng)一格。
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軸上，確認系統損壞的影響：舒適程度下降，明顯的經(jīng)濟損失，根本性的經(jīng)濟損失（比如破產(chǎn)），或者喪命。
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？）反映了各種項目的不同重點(diǎn)，所耗費的是否是上市時(shí)間（就象在第一層），效率和兼容性(隱藏的第二層)，或者法律責任（隱藏的第三層）.網(wǎng)格中的格子決定了在相似溝通難度和安全需求下的項目的類(lèi)型（例如C6），你可以用來(lái)選擇方法論。
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.
這個(gè)網(wǎng)格顯示了項目的特性，對選擇一個(gè)方法論很有用。我自己在項目的大小和復雜程度改變的時(shí)候，用來(lái)改變我的方法論。當然還有其他的因素，但這三個(gè)用來(lái)決定選擇什么方法論是很好的。
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.
假定現在要選擇項目的方法論。得益于上面所提到的對有關(guān)項目的訪(fǎng)談，你可以把建立一個(gè)最輕量級的方法論，想象成按照網(wǎng)格中的格子工作，在這里，盡量提高人和人之間的交流，運行測試后的代碼是最基本的進(jìn)度標志。結果是一個(gè)簡(jiǎn)單的，符合人的習慣的（意味著(zhù)更讓人愉快的，反對壓抑人的）高效率的方法論。在網(wǎng)格上指定這個(gè)方法論到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.
重復這些所有的格子，產(chǎn)生一個(gè)輕量級的方法的家族，根據他們對人們的信心，溝通，和發(fā)布運行代碼的頻率。我叫這個(gè)家族為Crystal Light方法論族。這個(gè)家族用顏色（在圖上沒(méi)畫(huà)）分成不同的豎直的條紋：2-6個(gè)人的項目的方法論叫 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.
垂直方向間的切換在方法學(xué)上被稱(chēng)為強化。一個(gè)短生命期的2到6個(gè)人的項目應該使用強化了的Crystal Clear或其派生方法來(lái)管理。使我驚喜的是，在這樣的 項目中幾乎看不到增加需求和按時(shí)完成項目之間的矛盾。
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出自一本即將出版的書(shū)，現在網(wǎng)上已經(jīng)有草稿。在《Surviving Object-Oriented Projects》一書(shū)的方法論一章中描述了Crystal Orange的輪廓。
Having worked with the Crystal Light methods for several years now, I found a few more surprises.
在采用Crystal Light方法多年以后，現在我發(fā)現了更多的驚喜。
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.
第一個(gè)驚喜是，一個(gè)開(kāi)發(fā)隊伍成功（不僅僅是幸存）并不需要太多的管理和控制。大部分開(kāi)發(fā)人員都樂(lè )于專(zhuān)心工作和寫(xiě)出好的軟件，他們會(huì )使用自己的理解能力和溝通能力去 完成這一切。這和Jim做出的關(guān)于自適應軟件開(kāi)發(fā)的結論完全一致(參見(jiàn)"資源和參考"，第15頁(yè))。你需要比你預計的要少得多的控制，尤其是當你希望能盡快發(fā)布軟件時(shí)，越 少就越好。
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交換項目管理的心得時(shí)，我們意識到我們都觀(guān)察到了成功的項目管理中的一個(gè)關(guān)鍵要素：開(kāi)發(fā)人員能理解有關(guān)人員的工作并加以溝通。他們能通過(guò) 許多簡(jiǎn)單、低技術(shù)含量并且廉價(jià)的方法完成這一切。通常這并不需要引入什么特別的工具來(lái)管理。
Oh, but it is necessary to introduce two more things into the project: trust and communication.
不過(guò)項目中還是需要兩個(gè)關(guān)鍵要素：信任和溝通。
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.
在一個(gè)項目中，缺乏信任比選擇了錯誤的方法學(xué)更要命。從某種程度上講，只要你能加強信任和溝通，你就一定能受益于Crystal Clear，XP（極限編程 ？）或別的輕量級開(kāi)發(fā)方法。
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?
第二個(gè)驚喜是當我們定義Cystal Light方法的時(shí)候它就和XP一致了。我把Crystal Clear設計成我所能想象的最不官僚的方法學(xué)。隨后XP在 同一領(lǐng)域出現并展露鋒芒，在它面前Clear仿佛成了重量級的開(kāi)發(fā)方法！這是怎么一回事？
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發(fā)現了方法學(xué)的控制面板上的另一個(gè)開(kāi)關(guān)：紀律。在某種程度，如果一個(gè)開(kāi)發(fā)小組能增強內部的紀律性并保證行動(dòng)的一致性，方法學(xué)可以變得更加 輕巧。Crystal Light衍生的方法學(xué)給予開(kāi)發(fā)者最多的個(gè)性化。XP則要求每個(gè)人都遵守嚴格的有紀律的實(shí)踐：
In other words, Crystal Clear illustrates and XP magnifies the core principle of light methods:
換一句話(huà)說(shuō)，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.
在一定程度上，如果開(kāi)發(fā)隊伍的交流得到了改善，發(fā)布的頻率得到提高，那么就可以減少中間產(chǎn)品的工作量，從而能更快地完成項目。
XP and Crystal Clear are related to each other in these ways:
XP和Crystal Clear有如下關(guān)聯(lián)：
Although there are differences in Crystal Clear and XP, the fundamental values are consistent -- simplicity, communications, and minimal formality.
盡管Crystal Clear和Xp之間存在很多差異，但是它們的基本價(jià)值觀(guān)是一致的--簡(jiǎn)單、交流和盡量減少形式化。
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，請看"相關(guān)資源與引用"部分列出的Alistair Cockburn的網(wǎng)站，在。如果你想深入了解 Crystal Orange，你可以參閱《Surviving Object-Oriented Projects》一書(shū)，同樣有關(guān)信息在"相關(guān)資源與引用"部分也已列出。
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 都描述了他們的輕量級方法和經(jīng)驗。但在前面描述Chrysler的 C3 項目時(shí)，我間接的提到，擴展使用類(lèi)似XP或者甚至是RAD的方法都存在著(zhù)困難。在我們 對eAD的訂閱者所做的所有調查以及所有軟件組織的行為調查中，一般說(shuō)來(lái)，快速的響應 速度，減少發(fā)布時(shí)間是一個(gè)關(guān)鍵的開(kāi)始。但這并不是說(shuō)只有首次發(fā)布才是關(guān)鍵的。雖然 Amazon.com 因為更早進(jìn)入網(wǎng)上書(shū)店市場(chǎng)而擁有優(yōu)勢，但它為了維持它的領(lǐng)導地位，必須 持續不斷的適應市場(chǎng)條件----這意味著(zhù)軟件的持續更改。
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.
快速發(fā)布.快速修改.頻繁變更.通過(guò)這三者的驅動(dòng)，加上更好的軟件工具，迫使我們重新 思考傳統的軟件工程實(shí)踐----并不是放棄它們，而是對其重新加以思考。例如，XP 并沒(méi)有 要我們拋棄好的軟件工程實(shí)踐。相反，它要求我們去深入地思考，在 當今軟件發(fā)布環(huán)境下，小型協(xié)作團隊能夠高效運作所需的最低環(huán)境要求有哪些。
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 觀(guān)察發(fā)現，XP（至少按照Beck和Jeffries所定義的那樣）的實(shí)現至少需要三個(gè) 環(huán)境特征：界面修改不會(huì )帶來(lái)昂貴的的代價(jià)，更密切的交流和自動(dòng)的回歸測試。實(shí)際上 XP 不是問(wèn)"我該如何降低變更帶來(lái)的成本"，而是要求一個(gè)低更改成本的環(huán)境，然后說(shuō)"我們將這樣工作"。例如， C3項目使用面向對象數據庫GemStone，而不是去使用傳統關(guān)系數據庫（以及 和多個(gè)外部組打交道）。
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.
有些人也許會(huì )說(shuō)這種方法是欺騙，確實(shí)如此。例如，西南航空公司在創(chuàng )建動(dòng)力室時(shí)，使用 同一種類(lèi)型的飛機（波音737）來(lái)降低成本。如果湍流和改變都是標準的，那么正確 的問(wèn)題可能就是：我們如何創(chuàng )建一個(gè)導致最低變更成本（和時(shí)間）的環(huán)境？西南航空公司在擴 張時(shí)，沒(méi)有遺留的飛機存貨。對于美國航空公司來(lái)說(shuō)，這個(gè)問(wèn)題的答案也許會(huì )不同，但是 它仍然是個(gè)重要的問(wèn)題。
There are five key ideas to take away from this discussion of XP and light methods:
在這個(gè)關(guān)于XP和輕量方法的討論中，我們能得到如下五個(gè)主要觀(guān)點(diǎn)：
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?
極端的規則。在寫(xiě)這篇文章的過(guò)程中，我曾經(jīng)收到12月20日發(fā)行的商業(yè)周刊雜志。其中有 一個(gè)封面故事，"極端零售"，關(guān)于"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.
重構，設計模式，對單元測試的充分理解，配對編程----這些都不是黑客們的工具。它們是開(kāi)發(fā)者 們?yōu)榱私鉀Q產(chǎn)品快速發(fā)布，同時(shí)又能保持較少的缺陷和靈活性時(shí)探索出的新方法。關(guān)于質(zhì)量，Beck說(shuō)，"只有兩種情況下是有價(jià)值的：‘優(yōu)秀‘或者‘極其優(yōu)秀‘，這取決于其對軟件產(chǎn)品生存的影響程度"，以及 "執行測試直到它們通過(guò)（100％正確）"。你也許可以指責XP的實(shí)踐者是受到了蒙蔽，但是他們決不是那種不重視質(zhì)量的黑客。
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.
對于傳統方法的支持者來(lái)說(shuō)，縮短發(fā)布時(shí)間是質(zhì)量的敵人。然而，我看過(guò)一些開(kāi)發(fā)速度 很慢而且質(zhì)量非常差的軟件，就象我看過(guò)的另一些開(kāi)發(fā)速度很快但質(zhì)量低下的軟件一樣。雖然在時(shí)間 和質(zhì)量間存在一些明顯的聯(lián)系，但我認為這個(gè)聯(lián)系比我們一般所想象的要的復雜的多。
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.
傳統方法可用于開(kāi)發(fā)那些變化程度不大并可預期最終結果的軟件.然而，商業(yè)世界卻是變化莫測的，并且傳統開(kāi)發(fā)方法已無(wú)法滿(mǎn)現在的快速變化軟件需求的要求。輕量級軟件開(kāi)發(fā)實(shí)踐的創(chuàng )始人Bob Charette認為"由于軟件工程研究所(SEI)這樣組織的官僚化、頑固性，以及諸如CMM的實(shí)踐，使得他們日益脫離當今的軟件開(kāi)發(fā)。
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在他書(shū)中所寫(xiě)的簡(jiǎn)介中指出的一樣，XP中的各個(gè)獨立實(shí)踐，都是從著(zhù)名的，經(jīng)過(guò)很好的測試 的，傳統實(shí)踐中抽取出來(lái)的。這些原則驅動(dòng)著(zhù)實(shí)踐的使用，與一個(gè)特別的實(shí)踐最小集自然的一 體化在一起，使得XP成為一個(gè)解決現代軟件開(kāi)發(fā)問(wèn)題的新方案。
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.
但是我必須以一條警告來(lái)做結束語(yǔ)。所有的這些新實(shí)踐都沒(méi)有很長(cháng)的歷史，它們的成功就象 逸事一樣，沒(méi)有被加以研究和度量。然而我堅信，我們混亂的電子商務(wù)經(jīng)濟需要我們重新審視 如何開(kāi)發(fā)和管理軟件發(fā)布。這些方法雖然很新，但它們提供了有價(jià)值的另一條思路。
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.
明年，我們毫無(wú)疑問(wèn)地可以看到更多關(guān)于XP的出版物，Beck, Jeffries, Fowler和Cunningham 都在相互合作出版更多關(guān)于XP的書(shū)。因此，你將看到更多的關(guān)于實(shí)踐的信息，管理哲學(xué)和項目 實(shí)例等。
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.
最后，一個(gè)關(guān)于如何繼續XP和其他"極端事物"討論的提示：就象我在前面討論中宣布的那樣， 我們創(chuàng )建了一個(gè)eAD論壇。如果你對加入這個(gè)小組感興趣，給我們發(fā)email到 ead@cutter.com， 我們將把你加入這個(gè)討論組，并且會(huì )把登錄信息發(fā)送給你。
聯(lián)系客服
