|
As we have explored in several issues of eAD, the two most pressing issues in information technology today are:
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.
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. 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. 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. 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:
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. 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):
But first, I discuss some XP basics: the dozen practices that define XP. XP - The Basics
|
|
 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從他的早期的著作開始，就不斷向那些軟件工程中的一些"古訓(xùn)"發(fā)出挑戰(zhàn)。從19世紀(jì)70年代中期的結(jié)構(gòu)化方法，以至后來的那些更復(fù)雜的方法，他們都基于如圖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è)問題，那些在70年代和80年代也許還能起到效果的方法，他們的經(jīng)費(fèi)開銷狀況（如圖1）現(xiàn)在已經(jīng)發(fā)生了變化（如圖2），也就是說，維護(hù)的成本（也可以等價(jià)為不斷發(fā)生的變化）降低了，而不是越來越高。實(shí)際上，圖2所示的開銷情況在當(dāng)今是否是事實(shí)其實(shí)并不重要，重要的是我們必須認(rèn)識(shí)到，如果圖1的現(xiàn)象還在繼續(xù)重演的話，我們只有死路一條，因?yàn)楫?dāng)今時(shí)代變化實(shí)在太快了（也就是說維護(hù)的成本將是一個(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軸通常用來表示在開發(fā)周期的后期發(fā)現(xiàn)錯(cuò)誤后需要花費(fèi)的改錯(cuò)成本?？墒牵@正驗(yàn)證了一個(gè)假設(shè)，即后期所有需要做的開動(dòng)均來自前期的一個(gè)錯(cuò)誤，比方說一個(gè)設(shè)計(jì)缺陷。從這一點(diǎn)來看，傳統(tǒng)方法太依賴于在軟件生命周期的早期"不出錯(cuò)"。但是在當(dāng)今瞬息萬變的環(huán)境中，我們不能完全預(yù)防住那些我們預(yù)測(cè)不到的東西--即由應(yīng)用需求不斷增長而帶來的變化，并且這種變化在早期不可能遇見并加以預(yù)防。因此，雖然我們要盡可能在早期做出某些應(yīng)付變化的預(yù)防措施，但是更重要的是我們要減少后期改變所帶來的開銷。正如 Alistai Cockburn 所指出的，需要高成本的圖1所示的那種改正缺陷方法，正好從節(jié)省開支的角度給了一些實(shí)用的方法（如配對(duì)編程）一個(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雜志中，我打算把討論定位于項(xiàng)目或應(yīng)用軟件層次上的變化--對(duì)類似操作系統(tǒng)、編程語言、數(shù)據(jù)庫、組件等的討論不在討論之列。（關(guān)于軟件結(jié)構(gòu)的靈活性，可以參考ADS雜志1999年6月的那期）另外，讓我們進(jìn)一步做個(gè)簡化，即假定軟件的用戶需求已經(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.
我們的目標(biāo)是既能快速不斷的發(fā)布新功能，同時(shí)又要讓軟件的設(shè)計(jì)易于更改。即使是在快速發(fā)布這個(gè)目標(biāo)下，仍然需要在"快速發(fā)布但Bug叢生"和"面面俱到但曠日持久"之間進(jìn)行取舍。因此，讓我再簡化一下我們要討論的問題，我們假定我們已經(jīng)在設(shè)計(jì)、編碼和測(cè)試這三者之間取得了合理的平衡。
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?
在上面這些簡化的基礎(chǔ)上，還留有一個(gè)尾巴：我們?cè)谠O(shè)計(jì)時(shí)對(duì)于未知的未來要看多遠(yuǎn)？現(xiàn)在的設(shè)計(jì)已經(jīng)實(shí)現(xiàn)了我們現(xiàn)在想到的一些功能。具有預(yù)見性的設(shè)計(jì)可以使未來的需求更快的獲得實(shí)現(xiàn)，也就是說預(yù)見性設(shè)計(jì)方法在以現(xiàn)在的時(shí)間換取未來的時(shí)間，如果一點(diǎn)點(diǎn)現(xiàn)在的時(shí)間可以換來未來節(jié)約大量時(shí)間，當(dāng)然是劃算的。但是這種建設(shè)怎么才能成為現(xiàn)實(shí)呢？也許未來出了問題就整個(gè)重新設(shè)計(jì)一遍也不慢，那又何必現(xiàn)在瞎猜呢？
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)槭裁匆岢鲋貥?gòu)的原因。重構(gòu)，Martin Fowler說過，是不改變軟件對(duì)外表現(xiàn)但是重整內(nèi)務(wù)的一種改進(jìn)。XP方法的支持者在變化的環(huán)境中實(shí)踐了連續(xù)的、增量式的重構(gòu)方法。如果變化是不斷演化的的，那就不可能存在什么一步到位的設(shè)計(jì)方法。說白了，如果變化不可預(yù)測(cè)--正如當(dāng)今社會(huì)的情況--過多的在設(shè)計(jì)時(shí)考慮以后可能的變化，完全是一種浪費(fèi)。
 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.
我認(rèn)為圖3給出的是互聯(lián)網(wǎng)時(shí)代到來之前的情況。由于變化的速度慢（圖中由天平的支點(diǎn)比較靠左來表示），早期的預(yù)測(cè)多一些是合理的。但是在圖4中，由于變化速度變快樂，設(shè)計(jì)時(shí)預(yù)測(cè)太多是得不償失的，這種情況正是現(xiàn)在許多系統(tǒng)所面臨的。
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è)長期項(xiàng)目中，檢驗(yàn)一個(gè)設(shè)計(jì)是否具有很好的靈活性是通過變化需求，同時(shí)看看原設(shè)計(jì)能否很容易的實(shí)現(xiàn)新變化的需求。這種傳統(tǒng)的"先設(shè)計(jì)，再維護(hù)"策略的最大問題在于軟件系統(tǒng)存在非常大的熵（極易變化，沒有規(guī)律）。一個(gè)系統(tǒng)隨著時(shí)間的推移，維護(hù)、改錯(cuò)、打補(bǔ)丁、增強(qiáng)功能等工作會(huì)使系統(tǒng)的熵越來越大。現(xiàn)在由于外部環(huán)境變化加快，情況正越來越糟。不過，現(xiàn)在的重構(gòu)技術(shù)也不是第一個(gè)試圖解決這個(gè)問題的方法。早在所謂的"黑暗時(shí)期"（circa 1986），Dave Higgins 就寫過一本名為"Data Structured Software Maintenance"的書，該書指出了由于隨著時(shí)間的推移變化的累計(jì)影響不斷增大，維護(hù)所需要的開銷也將越來說龐大，Higgins 提出了一種新的設(shè)計(jì)方法（the Warnier/Orr Approach）用于阻止系統(tǒng)的熵增大所帶來的負(fù)面影響，該方法的思想是在維護(hù)過程中有系統(tǒng)的對(duì)程序進(jìn)行重新設(shè)計(jì)。
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è)計(jì)設(shè)定一種模式（雖然那時(shí)還沒有模式這個(gè)提法），然后在細(xì)致的代碼設(shè)計(jì)與"好"的模式之間建立一種映射，程序員即根據(jù)這種映射關(guān)系來理解系統(tǒng)并修改程序，使修改的結(jié)果更接近于那個(gè)模式。使用 Higgins 這個(gè)方法可以通過維護(hù)抵消系統(tǒng)誰時(shí)間而熵增大的趨勢(shì)。Higgins 說："該方法的目標(biāo)并不是重寫整個(gè)系統(tǒng)，而只是重寫那些根據(jù)需要必須增強(qiáng)的部分。"
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.
雖然這種原始的"重構(gòu)"技術(shù)并沒有被廣泛的實(shí)踐檢驗(yàn)，其思想與現(xiàn)在的重構(gòu)還是相通的，只不過現(xiàn)在的需求變化更快、更大。不過有兩個(gè)東西驅(qū)動(dòng)、提高了現(xiàn)代的重構(gòu)技術(shù)：一是更好的程序設(shè)計(jì)語言和開發(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（快速原型開發(fā)）方法中還有另一種應(yīng)付變化的辦法：代碼拋棄思想。這個(gè)思想認(rèn)為環(huán)境和需求變化太快，因此我們唯一的辦法只能是快速編寫新代碼，并且也快速的拋棄老代碼。我們認(rèn)為這不是長久之計(jì)。
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.
重構(gòu)(Refactoring)與構(gòu)造 (factoring)，或者說與設(shè)計(jì)模式的使用密切相關(guān)。Erich Gamma, Richard Helm, Ralph Johnson, 和 John Vlissides合著的《 Design Patterns: Elements of Reusable Object-Oriented 》一書為設(shè)計(jì)模式做出了奠基性的工作。正如Larry Constantine 和Ed Yourdon 所倡導(dǎo)的結(jié)構(gòu)化設(shè)計(jì)一樣，設(shè)計(jì)模式對(duì)當(dāng)代的面向?qū)ο蠹夹g(shù)程序設(shè)計(jì)做出了巨大的貢獻(xiàn)，為開發(fā)人員帶來了福音。通過設(shè)計(jì)模式，程序的結(jié)構(gòu)的比以往更為有效。
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 所顯示的設(shè)計(jì)（designing）與重構(gòu)(refactoring)在面對(duì)高速變化環(huán)境時(shí)的適應(yīng)能力方面的差別是客觀的話，初始設(shè)計(jì)的質(zhì)量則顯的尤為重要。通過提供過去已被證明是有效的模式，設(shè)計(jì)模式(Design patterns)提供了一種提高初始設(shè)計(jì)質(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.
現(xiàn)在，也許你會(huì)問，為什么還需要一本獨(dú)立講重構(gòu)的書呢？難道我們不可以只使用設(shè)計(jì)模式來重新設(shè)計(jì)嗎？可以，也不可以。正如所有的開發(fā)人員(包括管理者)都知道，修改原有的程序代碼是一件棘手的事。development folklore年刊上有一句話，"if it ain‘t broke,don‘t fix it".然而，正如Fowler所提到的，"程序也許還沒有‘壞掉‘，但卻造成了潛在的危害." 害怕對(duì)那些還能"工作"的代碼重新構(gòu)造實(shí)際上只會(huì)加劇代碼性能的衰退。同時(shí)，F(xiàn)owler也清楚的認(rèn)識(shí)到："在軟件重構(gòu)之前，需要找到安全的做法……我把這些安全的步驟寫進(jìn)了目錄"。Fowler所寫的<>,不僅編錄了如何對(duì)以前的（差的）代碼和以后的（基于模式設(shè)計(jì)的較好）的代碼進(jìn)行重構(gòu)的方法，而且也包含了代碼分割重構(gòu)的步驟。這些步驟減少了在重構(gòu)過程中出現(xiàn)差錯(cuò)的機(jī)會(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"方法來描述重構(gòu)，也就是說, 添加新的功能與重構(gòu)是兩種不同的行為。在本質(zhì)上，重構(gòu)不改變軟件可見的外部功能，它只是增強(qiáng)了軟件的內(nèi)部結(jié)構(gòu)。當(dāng)有新的功能需要添加時(shí)，第一步常是對(duì)軟件進(jìn)行重構(gòu)，使添加更簡化。事實(shí)上，這種添加的新功能為重構(gòu)提供著推動(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.
與重量級(jí)的再設(shè)計(jì)相反，重構(gòu)可以被認(rèn)為是增量（incremental）式的再設(shè)計(jì)，"沒有重構(gòu)，程序設(shè)計(jì)會(huì) 腐爛"，F(xiàn)owler寫到," 結(jié)構(gòu)性的缺陷會(huì)帶來累積效應(yīng) "。歷史上，我們對(duì)軟件維護(hù)的方法是"quick and dirty"(快速但不徹底的?)，致使一些初始設(shè)計(jì)工作做的好的項(xiàng)目，隨著時(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 顯示了沒有重構(gòu)時(shí)的情況：因?yàn)檐浖侨绱说牟豢煽浚?jí)維護(hù)費(fèi)用變的讓人望而卻步，于是巨型(monumental)設(shè)計(jì)(或替換)成了唯一選擇，項(xiàng)目的風(fēng)險(xiǎn)，至少是投入上，變的越來越大。圖 5也顯示，在80年代，軟件的生存期大約要10年，而在今天需求的快速變化加劇了軟件的腐爛。舉個(gè)例子，許多90年代初一窩蜂做出來的C/S應(yīng)用軟件在今天比80年代留下來的大型機(jī)軟件的維護(hù)費(fè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和重構(gòu)思想吸引我的一點(diǎn)是他們能夠清楚認(rèn)識(shí)到所要考慮實(shí)施問題的邊界條件(boundary conditions).例如，F(xiàn)owler寫了一章"Problems with Refactoring".其中首要的問題就是數(shù)據(jù)庫的重構(gòu)。正如書的副標(biāo)題所示，F(xiàn)owler的目標(biāo)是為了提高代碼質(zhì)量。為此，我咨詢了一些在數(shù)據(jù)重構(gòu)（或者用其他的術(shù)語）方面有較深研究的人。以下關(guān)于數(shù)據(jù)重構(gòu)部分由Ken Orr所寫。
When Jim asked me to put together something on refactoring, I had to ask him what that really meant. It seemed to me to come down to a couple of very simple ideas:
當(dāng)Jim 要我講一講重構(gòu)時(shí)，我問他重構(gòu)究竟意味著什么。對(duì)我來說，把它歸納為以下簡單的幾點(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.
在過去幾年中，Jim和我一起工作，共同研究各種系統(tǒng)方法學(xué)(systems methodologies)，發(fā)現(xiàn)所有的方法學(xué)與重構(gòu)思想(refactoring philosophy)有著一致的地方。70年代，我們建立了一種基于數(shù)據(jù)結(jié)構(gòu)的方法學(xué)。其主要思想是：在知道了人們的需求后，逆向工作，設(shè)計(jì)一個(gè)僅含必需數(shù)據(jù)的數(shù)據(jù)庫，然后再確定更新數(shù)據(jù)庫必需的輸入數(shù)據(jù)，產(chǎn)生需要的輸出數(shù)據(jù)。
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.
從輸出結(jié)果逆向工程到數(shù)據(jù)庫再到輸入來建構(gòu)系統(tǒng)的方法被證明是一種非常有效和有效率的系統(tǒng)開發(fā)方法。幾乎在關(guān)系數(shù)據(jù)庫開始流行的同時(shí)，這種方法也發(fā)展了起來。使我們能夠建立起運(yùn)作良好，規(guī)范化的數(shù)據(jù)庫。除此之外，這種思想也適用于創(chuàng)建最小系統(tǒng)(minimal systems).事實(shí)上，我們的一個(gè)客戶在重建一個(gè)系統(tǒng)時(shí)已經(jīng)使用了這種方法并取得了成功。該客戶從輸出入手，通過逆向工程設(shè)計(jì)了一個(gè)滿足最小輸入需求的最小數(shù)據(jù)庫。
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.
新系統(tǒng)只有老系統(tǒng)三分之一的數(shù)據(jù)元（data elements ）。這是一個(gè)大的突破。開發(fā)人員開始逐漸認(rèn)識(shí)到建立最小系統(tǒng)有著巨大的優(yōu)勢(shì)：系統(tǒng)更小因而可以更快的實(shí)現(xiàn)；功能單一更能適應(yīng)變化。
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)建最小系統(tǒng)并不符合許多分析員和程序員們的想法，不管有多遙遠(yuǎn)，他們總認(rèn)為自己可以超前思考并預(yù)見到未來的需求。我認(rèn)為這源于軟件難于維護(hù)的原因。維護(hù)一個(gè)大的系統(tǒng)是如此的困難并充斥著問題，以致于許多分析員和程序員寧愿在系統(tǒng)開發(fā)的前期花費(fèi)大量的精力來設(shè)計(jì)一個(gè)"完善"的系統(tǒng)，以求一勞永逸。然而事實(shí)證明，預(yù)測(cè)未來是徒勞的。不論我們有多聰明，思想有多超前，總會(huì)有一些不曾預(yù)料到的需求出現(xiàn)。（有多少人能夠在10年前就將基于internet的電子商務(wù)作為未來的需求寫入自己的軟件）
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.
最后，維護(hù)如此困難的原因之一在于，當(dāng)改變數(shù)據(jù)庫設(shè)計(jì)時(shí)，其他的問題都會(huì)接踵而來。在大多數(shù)開發(fā)人員看來，一旦設(shè)計(jì)好數(shù)據(jù)庫并在此基礎(chǔ)上開始了編碼以后，再去改變數(shù)據(jù)庫的設(shè)計(jì)幾乎是不可能的。在某種程度上，設(shè)計(jì)數(shù)據(jù)庫就好比建造系統(tǒng)的地基：一旦你把混凝土灌了進(jìn)去，你就沒辦法再去改變它。因此，除非不可避免，大型系統(tǒng)中的數(shù)據(jù)庫極少會(huì)發(fā)生大的改動(dòng)。人們不能把重新設(shè)計(jì)數(shù)據(jù)庫僅僅當(dāng)成系統(tǒng)維護(hù)的普通一部分。否則的話，對(duì)系統(tǒng)進(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和我永遠(yuǎn)都不會(huì)承認(rèn)一旦系統(tǒng)開始運(yùn)行就不能再改變數(shù)據(jù)庫設(shè)計(jì)的觀點(diǎn).我們認(rèn)為,如果你想使系統(tǒng)保持最精簡的狀態(tài),就必須要把所要做的變化或新的功能引入到系統(tǒng)中并重復(fù)基本的開發(fā)過程,使新的需求和舊的需求融合在一起而成為一個(gè)新的系統(tǒng).你可能會(huì)說我們所作的就是數(shù)據(jù)重構(gòu),可我們從來不那么說.
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.
這么做的好處是顯而易見的.首先,開發(fā)一個(gè)新系統(tǒng)和維護(hù)或?qū)εf系統(tǒng)統(tǒng)進(jìn)行較大改造的區(qū)別并不是很大.這就意味著管理一個(gè)項(xiàng)目和培訓(xùn)工作將大大減少.同時(shí),也將減少開發(fā)時(shí)間,這是因?yàn)槲覀儗?duì)變化的處理方式不同，一個(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.
在過去的幾年里，我們建立了一種方法（結(jié)構(gòu)化系統(tǒng)設(shè)計(jì)方法或Warnier-Orr法）并且培訓(xùn)了數(shù)以千計(jì)的系統(tǒng)分析員和編程人員。即便我們?cè)诙x了足夠詳細(xì)的各種說明后有可能用CASE工具實(shí)現(xiàn)大部分工作，但開發(fā)過程仍需要大量的手工工作。
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.
為了縮短開發(fā)時(shí)間，南美的一組系統(tǒng)開發(fā)人員在80年代年開發(fā)出了數(shù)據(jù)重構(gòu)自動(dòng)化工具。由Breogán Gonda 和 Nicolás Jodal領(lǐng)導(dǎo)的公司開發(fā)了一種名叫GeneXus的工具，這正是我們?cè)?0年代所構(gòu)想要的。他們創(chuàng)建的方法使我們?cè)谳斎霐?shù)據(jù)結(jié)構(gòu)以后，系統(tǒng)能夠自動(dòng)為你創(chuàng)建規(guī)范的數(shù)據(jù)庫并產(chǎn)生瀏覽、更新和輸出數(shù)據(jù)的代碼。
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.
這就使事情簡單了，這種工具使得當(dāng)用戶的需求或系統(tǒng)的要求改變后只需要修改原有的定義，重新編譯，就能夠重新設(shè)計(jì)數(shù)據(jù)庫以適應(yīng)新的需求，并產(chǎn)生僅僅受數(shù)據(jù)庫修改影響而需要改變的代碼。這就是基于數(shù)據(jù)的閉環(huán)的重構(gòu)過程。
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使我們認(rèn)識(shí)到重構(gòu)能構(gòu)給我們帶來的真正的東西。就我的經(jīng)驗(yàn)而言，這使開發(fā)人員從對(duì)未來需求的擔(dān)憂中解脫出來，從而能夠使開發(fā)人員僅僅定義他們所知道的并快速的實(shí)現(xiàn)所定義的所有內(nèi)容。因此，當(dāng)系統(tǒng)的需求更改以后，他們只須簡單的加入那些修改，重新編譯，就可以得到一個(gè)新的、完全集成的、滿足新的需求的最小系統(tǒng)。
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òu)正在逐漸變成一個(gè)時(shí)髦的詞語。與所有的時(shí)髦的東西一樣，既有好的一面，也有壞的一面。好的一面是：如果能夠正確的實(shí)施，重構(gòu)使我們有可能快速構(gòu)建健壯的系統(tǒng)。壞的一方面是：我們不得不重新考慮如何進(jìn)行開發(fā)。原先采用的所有開發(fā)和管理策略需要重新考慮。我們必須了解交互式的、增量的開發(fā)方法；我們還必須習(xí)慣于使我們能夠成功的模式化的開發(fā)方法和使用工具來完成系統(tǒng)開發(fā)工作中那些復(fù)雜的工作（數(shù)據(jù)庫設(shè)計(jì)和代碼生成）。
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使開發(fā)產(chǎn)生革命性的變化。90年代，對(duì)象和OO方法也使開發(fā)產(chǎn)生革命性的變化。這些技術(shù)都沒有像達(dá)到期望的效果。但現(xiàn)在，像GeneXus這樣的工具切切實(shí)實(shí)的做到了80年代人們所期望的東西。確實(shí)有可能在給定系統(tǒng)需求后自動(dòng)進(jìn)行數(shù)據(jù)庫設(shè)計(jì)，生成一種實(shí)際工作的商用關(guān)系型數(shù)據(jù)庫（Oracle, DB2, Informix, MS SQL Server, and Access），并產(chǎn)生能夠?yàn)g覽、更新和輸出數(shù)據(jù)庫中數(shù)據(jù)的不同語言（COBOL, RPG, C, C++, and Java）的代碼（原型和結(jié)果）。
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.
新的系統(tǒng)開發(fā)方法能夠使我們有更多的時(shí)間和用戶交流，分析用戶的需求，讓用戶選擇不同的交互界面，這在只憑自己來完成所有事情的時(shí)侯是不可能的。但是并不是所有人都喜歡這一開發(fā)方法。一個(gè)是因?yàn)檫@將很大程度上撥開開發(fā)過程的神秘面紗。另一個(gè)是因?yàn)檫@也給快速開發(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.
當(dāng)人們告訴你在Internet時(shí)代已經(jīng)不可能再建立簡單、精簡的系統(tǒng)的時(shí)侯，那么告訴他們Internet是速度和服務(wù)的天下，告訴他們重構(gòu)不僅僅是在21世紀(jì)建立這樣系統(tǒng)的最好方法，也是唯一的方法。
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顧問組工作時(shí)，為OO（面向?qū)ο螅┑拈_發(fā)制訂了一套工作方法。IBM認(rèn)為不管白貓黑貓，抓的到老鼠就是好貓。Cockburn 深入接觸許多開發(fā)小組，寫下了他們認(rèn)為導(dǎo)致項(xiàng)目成功或者失敗的關(guān)鍵之處。結(jié)果讓人大吃一驚。以下內(nèi)容是由 Cockburn寫的，基于他的含有極少方法論的"實(shí)戰(zhàn)工作"書 。
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的研究組里，開發(fā)小組要向以前成功的小組"道歉"，因?yàn)樗麄儧]有遵守一道正式的工序， 因?yàn)樗麄儧]有用一個(gè)高科技的CASE工具，又或者"僅僅"因?yàn)樗麄冏谝黄穑懻撍麄兿虏?該怎么做。 同時(shí)，一些失敗的小組覺得非常迷惑，盡管他們使用了正式的工序，他們還是 失敗了--也許是遵守這些工序還遵守的不夠好？后來我開始碰到一些成功的小組，他們宣稱 正是因?yàn)闆]有陷于花里胡哨的過程和可發(fā)布性，而是大家坐在一起，從而使得他們可以 更容易的加以討論并且經(jīng)常交換測(cè)試后的軟件，最終才得以成功。
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:
這些結(jié)論從 1991 到 1999，從香港到美國, 挪威, 和南非,在COBOL, Smalltalk, Java, Visual Basic, Sapiens, 和 Synon都是一貫堅(jiān)持 , 這些結(jié)論的最短描述是：
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.
盡可能在你的范圍內(nèi)，用面對(duì)面的溝通來代替寫文檔，從而可以減少對(duì)寫好了的工作產(chǎn)品的依賴，并 增大發(fā)布系統(tǒng)的可能性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ā)布正在運(yùn)行著并且經(jīng)過測(cè)試的系統(tǒng)片段，就越能讓你減少對(duì)寫好的"約定"標(biāo)記的依賴，越能增大最終發(fā)布系統(tǒng)的可能性
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.
應(yīng)當(dāng)以人性的方式加以溝通。即使是對(duì)內(nèi)向的程序員來說，采用不拘禮節(jié)的面對(duì)面的交流，都比采用寫在紙上的文檔進(jìn)行溝通效果要好。從成本和時(shí)間上來看，寫文章總比在白板上討論耗費(fèi)更多的時(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.
那些寫好的而且評(píng)審過的需求和設(shè)計(jì)文檔，只是"承諾"了要做什么，我們可以將其作為項(xiàng)目進(jìn)度的標(biāo)志 使用。有很多進(jìn)度標(biāo)志在最初設(shè)立時(shí)是好的。然而，更準(zhǔn)確的進(jìn)度標(biāo)志應(yīng)該是運(yùn)行測(cè)試后的代碼。因?yàn)檫@不是預(yù)先承諾的標(biāo)志，而是真正完成的標(biāo)志。
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部決定小試一下以上結(jié)果。他們啟動(dòng)一個(gè)小項(xiàng)目，使用簡單的把三個(gè)人放在一個(gè)房間里的方法，讓他們自生自滅。令人驚奇的是，這個(gè)小組及時(shí)的、優(yōu)秀的發(fā)布了系統(tǒng)。銀行的管理層覺得有點(diǎn)困惑。一定不會(huì)這么簡單的吧？
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:
當(dāng)然不是如此簡單。另外一個(gè)采訪了所有其他項(xiàng)目后得到的結(jié)論是：不同項(xiàng)目有不同的需要。這是非常明顯的不依賴于方法論的（不知道怎的）。當(dāng)然，如果你的項(xiàng)目只需要3到6個(gè)人，只要讓他們?cè)谝粋€(gè)房間里就可以了。但如果你有45或者100個(gè)人，這就沒用了。如果你要通過食物藥品管理部門的過程檢驗(yàn)，你就不能這樣開始。如果你想把我用火箭發(fā)射到火星上去，我建議千萬不要嘗試。我們必須記住團(tuán)隊(duì)的大小和項(xiàng)目的需求這類因數(shù)：
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.
根據(jù)收集到的有關(guān)因素總結(jié)出的結(jié)論如圖Figure 6所示。它顯示了影響選擇不同方法論的三個(gè)因數(shù)：溝通難度（由成員的數(shù)量決定），系統(tǒng)關(guān)鍵程序，以及項(xiàng)目的優(yōu)先級(jí)。
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.
根據(jù)成員數(shù)量確定在X軸上的部分（通常的只是開發(fā)組）。如果是一個(gè)分布的開發(fā)項(xiàng)目，因?yàn)槊鎸?duì)面溝通的機(jī)會(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軸上，確認(rèn)系統(tǒng)損壞的影響：舒適程度下降，明顯的經(jīng)濟(jì)損失，根本性的經(jīng)濟(jì)損失（比如破產(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.
在頂層的不同的飛機(jī)（板塊panel？）反映了各種項(xiàng)目的不同重點(diǎn)，所耗費(fèi)的是否是上市時(shí)間（就象在第一層），效率和兼容性(隱藏的第二層)，或者法律責(zé)任（隱藏的第三層）.網(wǎng)格中的格子決定了在相似溝通難度和安全需求下的項(xiàng)目的類型（例如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.
這個(gè)網(wǎng)格顯示了項(xiàng)目的特性，對(duì)選擇一個(gè)方法論很有用。我自己在項(xiàng)目的大小和復(fù)雜程度改變的時(shí)候，用來改變我的方法論。當(dāng)然還有其他的因素，但這三個(gè)用來決定選擇什么方法論是很好的。
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.
假定現(xiàn)在要選擇項(xiàng)目的方法論。得益于上面所提到的對(duì)有關(guān)項(xiàng)目的訪談，你可以把建立一個(gè)最輕量級(jí)的方法論，想象成按照網(wǎng)格中的格子工作，在這里，盡量提高人和人之間的交流，運(yùn)行測(cè)試后的代碼是最基本的進(jìn)度標(biāo)志。結(jié)果是一個(gè)簡單的，符合人的習(xí)慣的（意味著更讓人愉快的，反對(duì)壓抑人的）高效率的方法論。在網(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.
重復(fù)這些所有的格子，產(chǎn)生一個(gè)輕量級(jí)的方法的家族，根據(jù)他們對(duì)人們的信心，溝通，和發(fā)布運(yùn)行代碼的頻率。我叫這個(gè)家族為Crystal Light方法論族。這個(gè)家族用顏色（在圖上沒畫）分成不同的豎直的條紋：2-6個(gè)人的項(xiàng)目的方法論叫 Crystal Clear ，6-20人的項(xiàng)目的方法論叫 Crystal Yellow , 20-40人的項(xiàng)目的方法論叫 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é)上被稱為強(qiáng)化。一個(gè)短生命期的2到6個(gè)人的項(xiàng)目應(yīng)該使用強(qiáng)化了的Crystal Clear或其派生方法來管理。使我驚喜的是，在這樣的 項(xiàng)目中幾乎看不到增加需求和按時(shí)完成項(xiàng)目之間的矛盾。
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出自一本即將出版的書，現(xiàn)在網(wǎng)上已經(jīng)有草稿。在《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方法多年以后，現(xiàn)在我發(fā)現(xiàn)了更多的驚喜。
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è)開發(fā)隊(duì)伍成功（不僅僅是幸存）并不需要太多的管理和控制。大部分開發(fā)人員都樂于專心工作和寫出好的軟件，他們會(huì)使用自己的理解能力和溝通能力去 完成這一切。這和Jim做出的關(guān)于自適應(yīng)軟件開發(fā)的結(jié)論完全一致(參見"資源和參考"，第15頁)。你需要比你預(yù)計(jì)的要少得多的控制，尤其是當(dāng)你希望能盡快發(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.
更特別的是，當(dāng)我和Jim交換項(xiàng)目管理的心得時(shí)，我們意識(shí)到我們都觀察到了成功的項(xiàng)目管理中的一個(gè)關(guān)鍵要素：開發(fā)人員能理解有關(guān)人員的工作并加以溝通。他們能通過 許多簡單、低技術(shù)含量并且廉價(jià)的方法完成這一切。通常這并不需要引入什么特別的工具來管理。
Oh, but it is necessary to introduce two more things into the project: trust and communication.
不過項(xiàng)目中還是需要兩個(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è)項(xiàng)目中，缺乏信任比選擇了錯(cuò)誤的方法學(xué)更要命。從某種程度上講，只要你能加強(qiáng)信任和溝通，你就一定能受益于Crystal Clear，XP（極限編程 ？）或別的輕量級(jí)開發(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è)驚喜是當(dāng)我們定義Cystal Light方法的時(shí)候它就和XP一致了。我把Crystal Clear設(shè)計(jì)成我所能想象的最不官僚的方法學(xué)。隨后XP在 同一領(lǐng)域出現(xiàn)并展露鋒芒，在它面前Clear仿佛成了重量級(jí)的開發(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:
這大概是因?yàn)锽eck發(fā)現(xiàn)了方法學(xué)的控制面板上的另一個(gè)開關(guān)：紀(jì)律。在某種程度，如果一個(gè)開發(fā)小組能增強(qiáng)內(nèi)部的紀(jì)律性并保證行動(dòng)的一致性，方法學(xué)可以變得更加 輕巧。Crystal Light衍生的方法學(xué)給予開發(fā)者最多的個(gè)性化。XP則要求每個(gè)人都遵守嚴(yán)格的有紀(jì)律的實(shí)踐：
In other words, Crystal Clear illustrates and XP magnifies the core principle of light methods:
換一句話說，Crystal Clear展示了輕量級(jí)方法的核心法則，而XP放大了它：
Intermediate work products can be reduced and project delivery enhanced, to the extent that team communications are improved and frequency of delivery increased.
在一定程度上，如果開發(fā)隊(duì)伍的交流得到了改善，發(fā)布的頻率得到提高，那么就可以減少中間產(chǎn)品的工作量，從而能更快地完成項(xiàng)目。
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à)值觀是一致的--簡單、交流和盡量減少形式化。
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，請(qǐng)看"相關(guān)資源與引用"部分列出的Alistair Cockburn的網(wǎng)站，在。如果你想深入了解 Crystal Orange，你可以參閱《Surviving Object-Oriented Projects》一書，同樣有關(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í)方法和經(jīng)驗(yàn)。但在前面描述Chrysler的 C3 項(xiàng)目時(shí)，我間接的提到，擴(kuò)展使用類似XP或者甚至是RAD的方法都存在著困難。在我們 對(duì)eAD的訂閱者所做的所有調(diào)查以及所有軟件組織的行為調(diào)查中，一般說來，快速的響應(yīng) 速度，減少發(fā)布時(shí)間是一個(gè)關(guān)鍵的開始。但這并不是說只有首次發(fā)布才是關(guān)鍵的。雖然 Amazon.com 因?yàn)楦邕M(jìn)入網(wǎng)上書店市場而擁有優(yōu)勢(shì)，但它為了維持它的領(lǐng)導(dǎo)地位，必須 持續(xù)不斷的適應(yīng)市場條件----這意味著軟件的持續(xù)更改。
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ā)布.快速修改.頻繁變更.通過這三者的驅(qū)動(dòng)，加上更好的軟件工具，迫使我們重新 思考傳統(tǒng)的軟件工程實(shí)踐----并不是放棄它們，而是對(duì)其重新加以思考。例如，XP 并沒有 要我們拋棄好的軟件工程實(shí)踐。相反，它要求我們?nèi)ド钊氲厮伎?，?當(dāng)今軟件發(fā)布環(huán)境下，小型協(xié)作團(tuán)隊(duì)能夠高效運(yùn)作所需的最低環(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 觀察發(fā)現(xiàn)，XP（至少按照Beck和Jeffries所定義的那樣）的實(shí)現(xiàn)至少需要三個(gè) 環(huán)境特征：界面修改不會(huì)帶來昂貴的的代價(jià)，更密切的交流和自動(dòng)的回歸測(cè)試。實(shí)際上 XP 不是問"我該如何降低變更帶來的成本"，而是要求一個(gè)低更改成本的環(huán)境，然后說"我們將這樣工作"。例如， C3項(xiàng)目使用面向?qū)ο髷?shù)據(jù)庫GemStone，而不是去使用傳統(tǒng)關(guān)系數(shù)據(jù)庫（以及 和多個(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ì)說這種方法是欺騙，確實(shí)如此。例如，西南航空公司在創(chuàng)建動(dòng)力室時(shí)，使用 同一種類型的飛機(jī)（波音737）來降低成本。如果湍流和改變都是標(biāo)準(zhǔn)的，那么正確 的問題可能就是：我們?nèi)绾蝿?chuàng)建一個(gè)導(dǎo)致最低變更成本（和時(shí)間）的環(huán)境？西南航空公司在擴(kuò) 張時(shí)，沒有遺留的飛機(jī)存貨。對(duì)于美國航空公司來說，這個(gè)問題的答案也許會(huì)不同，但是 它仍然是個(gè)重要的問題。
There are five key ideas to take away from this discussion of XP and light methods:
在這個(gè)關(guān)于XP和輕量方法的討論中，我們能得到如下五個(gè)主要觀點(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?
極端的規(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.
重構(gòu)，設(shè)計(jì)模式，對(duì)單元測(cè)試的充分理解，配對(duì)編程----這些都不是黑客們的工具。它們是開發(fā)者 們?yōu)榱私鉀Q產(chǎn)品快速發(fā)布，同時(shí)又能保持較少的缺陷和靈活性時(shí)探索出的新方法。關(guān)于質(zhì)量，Beck說，"只有兩種情況下是有價(jià)值的：‘優(yōu)秀‘或者‘極其優(yōu)秀‘，這取決于其對(duì)軟件產(chǎn)品生存的影響程度"，以及 "執(zhí)行測(cè)試直到它們通過（100％正確）"。你也許可以指責(zé)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.
對(duì)于傳統(tǒng)方法的支持者來說，縮短發(fā)布時(shí)間是質(zhì)量的敵人。然而，我看過一些開發(fā)速度 很慢而且質(zhì)量非常差的軟件，就象我看過的另一些開發(fā)速度很快但質(zhì)量低下的軟件一樣。雖然在時(shí)間 和質(zhì)量間存在一些明顯的聯(lián)系，但我認(rèn)為這個(gè)聯(lián)系比我們一般所想象的要的復(fù)雜的多。
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.
傳統(tǒng)方法可用于開發(fā)那些變化程度不大并可預(yù)期最終結(jié)果的軟件.然而，商業(yè)世界卻是變化莫測(cè)的，并且傳統(tǒng)開發(fā)方法已無法滿現(xiàn)在的快速變化軟件需求的要求。輕量級(jí)軟件開發(fā)實(shí)踐的創(chuàng)始人Bob Charette認(rèn)為"由于軟件工程研究所(SEI)這樣組織的官僚化、頑固性，以及諸如CMM的實(shí)踐，使得他們?nèi)找婷撾x當(dāng)今的軟件開發(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在他書中所寫的簡介中指出的一樣，XP中的各個(gè)獨(dú)立實(shí)踐，都是從著名的，經(jīng)過很好的測(cè)試 的，傳統(tǒng)實(shí)踐中抽取出來的。這些原則驅(qū)動(dòng)著實(shí)踐的使用，與一個(gè)特別的實(shí)踐最小集自然的一 體化在一起，使得XP成為一個(gè)解決現(xiàn)代軟件開發(fā)問題的新方案。
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.
但是我必須以一條警告來做結(jié)束語。所有的這些新實(shí)踐都沒有很長的歷史，它們的成功就象 逸事一樣，沒有被加以研究和度量。然而我堅(jiān)信，我們混亂的電子商務(wù)經(jīng)濟(jì)需要我們重新審視 如何開發(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.
明年，我們毫無疑問地可以看到更多關(guān)于XP的出版物，Beck, Jeffries, Fowler和Cunningham 都在相互合作出版更多關(guān)于XP的書。因此，你將看到更多的關(guān)于實(shí)踐的信息，管理哲學(xué)和項(xiàng)目 實(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@, and we will add you to the discussion group and send logon information.
最后，一個(gè)關(guān)于如何繼續(xù)XP和其他"極端事物"討論的提示：就象我在前面討論中宣布的那樣， 我們創(chuàng)建了一個(gè)eAD論壇。如果你對(duì)加入這個(gè)小組感興趣，給我們發(fā)email到 ead@， 我們將把你加入這個(gè)討論組，并且會(huì)把登錄信息發(fā)送給你。
|
|
Test 
Code 
Design. Listen closely to customers while gathering their requirements. Develop test cases. Code the objects (using pair programming). Design (or refactor) as more objects are added to the system. This seemingly convoluted lifecycle begins to make sense only in an environment in which change dominates.
