Original text is copyrighted by Martin Fowler
Martin Fowler
Chief Scientist, ThoughtWorks
原文出处| J体?| 译者：(x)Daimler Huang
对很多粗略接触到 Extreme Programming 的h来说QXP g 宣告?jin)Y件设计的d。不只很多的设计被嘲Wؓ(f) "Big Up Front Design"[译注1]Q连很多技术像UML、富有弹性的E序架构 (framework)Q甚臌模式 (pattern) 都不受重视，或是q似忽略?jin)。事实上QXP内含很多设计理念Q但是它与现有的软g程有着不同的运作方式。XP藉由多种实务技?(practice) 赋予演进式设?(evolutionary design) 崭新的风貌，让演q变成一U实用的设计Ҏ(gu)。它也让设计?(designer[译注2]) 面(f)新的?xi)战(sh)技巧，学习(fn)如何使设计精Q如何用重构来保持一个设计的清楚易懂Q以?qing)如何逐步地套用模式?/P>
(q篇文章是我?XP2000 研讨?x)发表的演说Q它?x)公布在研讨会(x)讲义中?
Planned and Evolutionary Design (l过规划的设计与演进式的设计)
The Enabling Practices of XP (XP有效的实作技?
The value of Simplicity (单的价?
What on Earth is Simplicity Anyway (I竟什么是?
Does Refactoring Violate YAGNI? (重构q反?jin)YAGNI吗？)
Patterns and XP (模式与XP)
Growing an Architecture (发展l构)
UML and XP (UML与XP)
On Metaphor (关于隐喻)
Do you wanna be an Architect when you grow up? (你将来想成ؓ(f)一个Y件结构师吗？)
Things that are difficult to refactor in (很难重构的东?
So is Design Dead? (所以，设计M(jin)吗？)
Acknowledgements (致谢)
Revision History (修订的记?
Extreme Programming (XP) ?xi)战很多软g开发常见的假设。其中最受争议的是极力排斥 up-front designQ而支持一U比较属于演q的方式。批评者说q是退回到?"code and fix" 的开发方式，多只能是一般急就章的E序设计|了(jin)。支持者也常看?XP 对于设计Ҏ(gu) (?UML)、principle(设计准则)、patterns {的排斥。别担心(j)Q仔l注意你的程序代码，你就?x)看到好?design 现出来?/P>
我发现自己正陷于q个争论当中。我的工作着重在囑Ş化设计语a - UML 以及(qing) patternsQ事实上我也写过 UML ?patterns 的书。我如此的拥?XP 是否表示我放弃了(jin)q些理论Q或是将q些反渐q式 (counter-revolutionary) 的概念从脑中清除?jin)?/P>
?.. 我不惌你的?j)(zhn)荡在q两U情境中。简单的说ƈ不是Q接下来的文章就让我来详l说明?/P>
Planned and Evolutionary Design
我将在这文章中说明软g开发的两种设计方式是如何完成的。或许最常见的是演进式设计。它的本质是pȝ的设计随着软g开发的q程增长。设?(design) 是撰写程序代码过E的一部䆾Q随着E序代码的发展，设计也跟着调整?/P>
在常见的使用中，演进式设计实在是d的失败。设计的l果其实是一堆ؓ(f)?jin)某些特D条件而y妙安排的军_所l成Q每个条仉?x)让E序代码更难修改。从很多斚w来看Q你可能?x)批评这h本就没有设计可言Q无疑地q样的方式常?x)导致很差劲的设计。根据Kent的陈qͼ所谓的设计 (design) 是要能够让你可以长期很简单地修改软g。当设计 (design) 不如预期Ӟ你应该能够做有效的更攏V一D|间之后，设计变得来糟Q你也体?x)到q个软g混ؕ的程度。这L(fng)情Ş不仅使得软g本n难以修改Q也Ҏ(gu)产生难以q踪和彻底解决的 bug。随着计画的进行，bug 的数量呈指数地成长而必花更多成本去解冻Iq就?"code and fix" 的恶梦?/P>
Planned Design 的做法正好相反，q且含有取自其它工程的概c(din)如果你打算做一间狗屋，你只需要找齐木料以?qing)在心(j)中有一个大略的形象。但是如果你惌Z栋摩天大|照同L(fng)做法Q恐怕还?sh)到一半的高度大楼垮?jin)。于是你先在一间像我太太在波士市(jng)区那L(fng)办公室里完成工程图。她在设计图中确定所有的l节Q一部䆾使用数学分析Q但是大部分都是使用建筑规范。所谓的建筑规范?yu)是?gu)成功的经?(有些是数学分? 制定出如何设计结构体的法则。当设计囑֮成，她们公司可以将设计图交l另一个施工的公司按图施工?/P>
Planned Design 同L(fng)方式应用在Y件开发。Designer 先定出重要的部䆾Q程序代码不是由他们来撰写，因ؓ(f)软gq不是他?"建造[译注3]" 的，他们只负责设计。所?designer 可以利用?UML q样的技术，不需要太注重撰写E序代码的细节问题，而在一个比较属于抽象的层次上工作。一旦设计的部䆾完成?jin)，他们可以将它交l另一个团?(或甚x(chng)另一家公? ?"建?。因?designer 朝着大方向思考，所以他们能够避免因为策略方面不断的更改而导致Y件的失序。Programmer 可以依循设计好的方?(如果有遵循设? 写出好的pȝ?/P>
Planned design Ҏ(gu)从七○年代出玎ͼ而且很多人都用过它了(jin)。在很多斚w它比 code and fix 渐进式设计要来的好，但是它也有一些缺点存在。第一个缺Ҏ(gu)当你在撰写程序代码时Q你不可能同时把所有必d理的问题都想清楚。所以将无可避免的遇C些让人对原先设计产生质疑的问题。可是如?designer 在完成工作之后就转移到其它项目，那怎么办？Programmer 开始迁p计来写程序，于是软g开始趋于乱。就找?designerQ花旉整理设计Q变更设计图Q然后修改程序代码。但是必面临更短的时程以及(qing)更大的压力来修改问题Q又是q开端?/P>
此外Q通常q有软g开发文化方面的问题。Designer 因ؓ(f)专精的技术和丰富的经验而成Z?designer。然而，他们忙于从事设计而没有时间写E序代码。但是，开发Y件的工具发展q速，当你不再撰写E序代码Ӟ你不只是错失?jin)技术潮?hu)所发生的改变，同时也失M(jin)对于那些实际撰写E序代码的h的尊敬?/P>
建造?(builder[译注3]) 和设计者之间这U微妙的关系在徏{界也看得到Q只是在软g界更加凸显而已。之所以会(x)如此强烈是因Z个关键性的差异。在建筑界，设计师和工程师的技术有清楚的分野；在Y件界比较分不清楚了(jin)[译注2]。Q何在高度注重 design 的环境工作的 programmer 都必d备良好的技术，他的能力_?designer 的设计提?gu)疑，其是?designer 对于新的发展工具或^台越来越不熟(zhn)的状况下?/P>
现在q些问题?sh)许可以获得解决。也许我们可以处理h与h之间的互动问题。也许我们可以加?designer 的技术来处理l大部䆾的问题，q且订出一个依照准则去做就_改变设计囄程。但是仍然有另外一个问题：(x)变更需求。变更需求是软g目中最让我感到头痛的问题(sh)(jin)?/P>
处理变更需求的方式之一是做有弹性的设计Q于是当需求有所更改Q你可以轻易的变更设计。然而，q是需要先见之明去猜测来你可能会(x)做怎样的变更。一w留处理易变性质的设计可能对于将来的需求变更有所帮助Q但是对于意外的变化却没有帮?(甚至有害)。所以你必须对于需求有_的了(jin)解以隔离易变的部份。照我的观察Q这是非常困隄?/P>
部䆾有关需求的问题应该归咎于对需求的?jin)解不够清楚Q所以有Z注于研究需求处理，希望得到适切的需求以避免后来对设计的修改。但是即使朝q个方向d一h法对症下药。很多无法预料的变更起因于瞬息万变的商场Q你只有更加心(j)处理需求问题来应付无法避免的情c(din)?/P>
q么说来Qplanned design 听v来像是不可能的Q务。这U做法当然是一U很大的?xi)战。但是，跟演q式设计 (evolutionary design) 普遍?code and fix 方式实作比较hQ我不觉?planned design ?x)比较差。事实上Q我也比较喜?planned design。因为我?jin)?planned design 的缺点，而且正在L更好的方法?/P>
The Enabling Practices of XP
XP 因ؓ(f)许多原因而备受争议，其中之一是它主张演q式设计 (evolutionary design) 而不?planned design。我们也知道Q演q式设计可能因ؓ(f)特定的设计或是Y件开发趋于p行不通?/P>
想了(jin)解这些争论的核心(j)Q就是Y件研发异动曲Uѝ曲U的变化说明Q随着目的进行，变更所需要的成本呈现指数的增加。这L(fng)曲线总一句话来表C：(x)在分析阶D花一块钱所作的变更Q发行之后要花数千元来补救。讽刺的是大部分的计M然没有分析过E而以非标准的方式q行Q但是这U成本上的指数关p还是存在着。这U指数曲U意味着演进式设计可能行不通，它同时也说明着Z?planned design 要小?j)翼地规划Q因ZQ何的错误q是?x)面对同L(fng)问题?/P>
XP 的基本假设是它可以将q种指数曲线拉^Q这hq式设计p得通了(jin)。XP 使曲U更q缓q能q用q种优势。这是因?XP 实作技巧之间的耦合效果Q换句话_(d)不用那些能够拉qY件开发曲U的实作技巧来工作Q这条曲U也不会(x)向q缓。这也是争论的来源，因ؓ(f)评论家不?jin)解q其间的关系。通常q些批评是根据评论家自n的经验，他们q没有实行那些有效的实作技巧，当他们看到结果不如预期，对于 XP 的印象也是q样?jin)?/P>
q些有效的实作技巧有几个部䆾Q主要是 Testing ?Continuous Integration。如果没?testing 提供保障Q其它的 XP 实作技巧都不可行。Continuous Integration 可以保持团队成员?sh)息同步Q所以当你有改变的部份，不必担心(j)与其它成员资料整合会(x)有问题。同时运用这些实作技巧能够大大媄(jing)响开发曲Uѝ这让我再次惌v?ThoughtWorks 导入 testing ?continuous integration 之后Q明昄改善?jin)研发成果。改善的E度好到令h怀疑是不是?XP 所d的，必须要用到所有的实作技巧才能大q改善效率。[译注4]
Refactoring hcM的成效。那些曾l采?XP 的原则来对程序代码进行refactoring 的h发现Q这么做要比无章法或是特D方式的 restructuring 明显的更有效率。那也曾l是 Kent 指导我适当?refactor 得到的难忘经验，也因么一ơ巨大的转变?sh)(j)我以q个主题写了(jin)一本书?/P>
Jim Highsmith 写了(jin)一很的文章 "summary of XP"Q他?planned design ?refactoring 攑֜天秤的两端。大部䆾传统的做法假设构想不变，所?planned design 占优ѝ而当你的成本来不允许变更Q你p們于采?refactoring。Planned design q不是完全消失，只是这两种做法互相搭配q用取得q。对我来_(d)在设计进?refactoring 之前Q总觉得这个设计不够健全?/P>
Continuous integration、testing ?refactoring q些有效的实作方法让 evolutionary design 看似很有道理。但是我们尚未找出其间的q炏V我怿Q不论外界对 XP 存有什么印象，XP 不仅仅是 testing、coding ?refactoring。在 coding 之前q有 design 的必要。部份的 design ?coding 之前准备Q大部䆾?design 则发生在实作每一详列的功能之前。MQ在 up-front design ?refactoring 之间可以扑ֈ新的q?/P>
The value of Simplicity
XP 大声疑֑的两个口h "Do The Simplest Thing that Could Possibly Work"(只做最单可以正常运作的设计) ?"You Aren't Going to Need It"(是 YAGNI - 你将不会(x)需要它)。两w是XP实务中简单设计的表现形式?/P>
YAGNI 一词时常被讨论Q它的意思是现在不要Z(jin)来可能用到的功能加入Q何程序代码。表面上听v来好象很单，问题则出在像 framework、重用组件、和Ҏ(gu)化设计Q这些东西本来就很复杂。你事先付出额外的成本去打造它们，希望E后这些花贚w赚回来。这个事先弹性设计的x(chng)被认为是软g设计有效率的关键部䆾?/P>
但XP的徏议是Q在处理W一个问题时不要因ؓ(f)可能需要某功能，徏造出Ҏ(gu)的lgl及(qing)框架出来。让整体l构随着需要成ѝ假如我今天惌一个可以处理加法但是不用乘法的 Money cdQ我只?Money cd中徏造加法的功能。就我定下一个阶D也需要乘法的q算Q而且我知道很单，也花不了(jin)多少旉Q我q是?x)留C一阶段再去做它?/P>
其中一个理由是效益。如果我要花旉在明天才需要的功能Q那pC我没有精放在这个阶D应该完成的事情上。发表计画详列目前要完成的事，现在做以后才需要的事情q背开发h员和֮之间的协议。这U做法有让现阶段的目标无法达成的可能。而且q个阶段?stroies[译注5] 是否h风险Q或是需不需要做额外的工作，都是由顾客来军_?- q是可能不包括乘法功能?/P>
q种l济效益上的限制是因为我们有可能出错。就是我们已经定q个功能应该如何q作Q都有可能出?- 其是这时候我们还没有取得详细需求。提前做一仉误的事情比提前做一件对的事情更费旉。而且XP专家们通常怿我们比较有可能会(x)做错而不是做?我心(j)有戚??/P>
W二个支?simple design 的理由是复杂的设计违反光U行q的原理。复杂的设计比简单的设计q要令h难懂。所以随着渐增的系l复杂度Q更加难以对pȝ做Q何修攏V如此，若系l必d入更复杂的设计时Q成本势必增加?/P>
现在很多人发现这L(fng)是无意义的，其实他们那样x(chng)对的。因Z所惌一般的研发q没有被 XP 有效的技巧所取代。然而，当规划式设计和渐q式设计之间的^衡点有了(jin)变化 (也只有当q样的变化发生时)QYAGNI ׃(x)变成好的技巧?/P>
所以结论是Q除非到?jin)往(xin)后的阶段有所需要，否则你不?x)浪费精去增加新的功能。即使不?x)多花成本，你也不?x)q样做，因ؓ(f)q现在加入q些功能q不增加成本Q但是却?x)增加将来做修改时的成本。MQ你可以在套?XP 时明智的遵守q样的方法，或是采取一U能降低成本的类似的Ҏ(gu)?/P>
What on Earth is Simplicity Anyway
因此Q我们希望程序代码能够越单越好，q听h没什么好争论的，毕竟有谁惌复杂呢？但问题来?jin)，I竟 "什么才叫简单呢Q?
?XPE 一书中QKent 对简单系l订?jin)四个评量标准，依序?(最重要排最前面)Q?/P>
通过所有测试?/P>
呈现所有的意图?/P>
避免重复?/P>
最数量的cd或方法?/P>
通过所有测试是一很普通的评量标准Q避免重复也很明，管有些研发人员需要别人的指点才能做到。比较麻?ch)的?"呈现所有的意图"q一，q到底指的是什么呢Q?/P>
q句话的本意是单明?jin)的E序代码。XP 对程序代码的易读性有很高的标准。虽然在 XP 当中Q?巧妙的程序代?(clever code)" q个字眼l常被滥用，不过意图清楚的程序代码，对其他h来说真的是一Uy妙。Josh Kerievsky ?XP 2000 论文中D?jin)一个很好的例子Q检视在 XP 领域可能是大家最熟知?JUnit 的程序代码。JUnit 使用 decorators ?test cases 中加入非必要的功能，像是同步机制?qing)批ơ设定等Q将q些E序代码抽出成ؓ(f) decoratorQ的让一般的E序代码看v来清楚许多?/P>
但是你必L?j)自问，q样做之后的E序代码够简单吗Q我觉得是，因ؓ(f)我了(jin)?Decorator q个 patterns。但是对于不?jin)解的h来说q是相当复杂的。类似的情况QJUnit 使用 pluggable methodQ一U大部分的h刚开始接触时都不?x)觉得简单的技巧。所以，也许我们可以?JUnit Ҏ(gu)l验的h来说是比较简单的Q新手反而会(x)觉得它很复杂?/P>
XP ?"Once and Only Once" 以及(qing) Pragmatic Programmer(书名) ?DRY(Don't Repeat Yourself) 都专注在去除重复的程序代码。这些良好的都有很显著而且惊h的效果。只要依照这个方式，目可以一路顺利的q作。但是它也不能解x(chng)有问题，单化q是不容易达成?/P>
最q我参与一个可能是q度设计的项目，pȝl过 refactor 之后去除部䆾Ҏ(gu)的设计。但是就像其中一位开发者所说的 "重构q度设计的系l要比重构没有设计的要来的容易多? 做一个比你所需要简单一点的设计是最好的Q但是，E微复杂一点点也不是什么严重的事情?/P>
我听q最好的来自 Bob 大叔 (Robert Martin)。他的徏议是不要太在意什么是最单的设计。毕竟后来你可以Q应该，也会(x)再重构。愿意在最后重构，比知道如何做单的设计重要得多?/P>
Does Refactoring Violate YAGNI?
q个主题最q出现在 XP 讨论ZQ当我们审视设计?XP 扮演的角色时Q我觉得很值得提出来讨论?/P>
基本上这个问题v因于重构需要耗费旉却没有增加新的功能。?YAGNI 的观Ҏ(gu)假设你ؓ(f)?jin)眼前的需要做设计而不是未来，q样是互相抵触吗？
YAGNI 的观Ҏ(gu)不要增加一些现阶段不需要的复杂功能Q这也是单设计这Ҏ(gu)巧的部䆾_。重构也是ؓ(f)?jin)满_可能保持pȝ的简单性这个需要，所以当你觉得可以让pȝ变得更简单的时候，p行重构?/P>
单设计不但利用了(jin) XP 的实务技巧，本n也是其中一Ҏ(gu)用的实务技巧。唯有伴随着试Q持l整合，?qing)重构的q用Q才能有效地做出单设计。同Ӟ让研发异动曲U保持^~的基础也就是保持设计的单。Q何不必要的复杂都?x)让pȝ变得难于调整Q除非这个复杂性是你ؓ(f)?jin)所预测的弹性而加入的。不q，Z的预通常都不太准，所以最好还是努力地保持单性?/P>
不管怎样Qh们不太可能第一ơ就能够获得最单的东西Q因此你需要重构来帮助你更接近q个目标?/P>
Patterns and XP
JUnit 的例子让我不得不惛_ patterns。XP ?patterns 之间的关pd微妙Q也常常被问赗Joshua Kerievsky 认ؓ(f) patterns ?XP 被过分轻视，而且他所提出的理׃相当令h信服Q我不想再重提。不q值得一提的是，很多人都认ؓ(f) patterns g?XP 是有冲突的?/P>
争论的本质在?patterns 常被q度滥用。世上有太多传奇性的 programmerQ第一ơ读到四人帮?32 行程序代码阐q?16 U?patterns q样的事情还记忆Ҏ(gu)[译注6]。我q记得有一晚与 Kent 喝着醇酒一赯Z文?"Not Design patterns: 23 cheap tricks (不要用设计模式－23 个简单的诀H?"。我们认为那不过是以 if 条g式来取代 strategy q个 pattern |了(jin)。这L(fng)W话有个重点Qpatterns 被滥用了(jin)。但q不表示 patterns 是不_的，问题在于你要怎么q用它?/P>
其中一论Ҏ(gu)单设计的力量自然?x)将目导?patterns。很多重构的例子明确地这么做Q或者甚至不用重构，你只要遵从简单设计的规则׃(x)发现 patternsQ即使你q(sh)知道 patterns 是什么。这L(fng)说法也许是真的，不过它真的是最好的方式吗？当然如果你先对于 patterns 有个大略的了(jin)解，或者手Ҏ(gu)一本书可以参考，?x)比自己发明新?patterns 要好些。当我觉得一?pattern 快Q现的时候，我必定会(x)ȝ?GOF 的书。对我来_(d)有效的设计告诉我?pattern 值得付出代h(hun)d?fn)－那就是它?gu)的技术。同样地像 Joshua 所的，我们需要更熟?zhn)于如何逐步地运?patterns。就q一点而言QXP 只是与一般?patterns 的方式不同而已Qƈ没有抹煞它的价倹{?/P>
但是从讨论区一些文章看来，我觉得很多h明显地认?XP q不鼓励使用 patternsQ尽?XP 大部分的提倡者也都是之前 patterns q动的领D。因Z们看C(jin)不同?patterns 的观点吗Q或是他们已l将 patterns 融入思考而不必再ȝ解它Q我不知道其它h的答案是什么，但是Ҏ(gu)来说Qpatterns 仍然是非帔R要的。XP 也许是开发的一U流E，?patterns 可是设计知识的骨qԌ不管是哪U流E这些知识都是很有用的。不同的程使用 patterns 的方式也׃同，XP {到需要时才?patterns 以及(qing)透过单的实作逐步导入 patterns。所?patterns 仍然是一U必获得的关键知识?/P>
我对于采?XP 的h使用 patterns 的徏议：(x)
q旉学习(fn) patterns?/P>
留意使用 patterns 的时?(但是别太??/P>
留意如何先以最单的方式使用 patternsQ然后再慢慢增加复杂度?/P>
如果用了(jin)一U?pattern 却觉得没有多大帮助－不用怕，再次把它L?/P>
我认为XP应该要更加强调学?patterns。我不确定它要怎么?XP 的实务技巧搭配，不过怿 Kent ?x)想出办法来的?/P>
Growing an Architecture
软g架构是指什么呢Q对我来_(d)架构q个字眼代表pȝ核心(j)lg的概念，也就是难以改变的部䆾Q剩下的都必d造在q基上?/P>
那么当你使用演进式设计时Q架构又扮演着什么样的角色呢QXP 的批评者再一ơ地声称 XP 忽视架构Q因?XP 使用的方法是快地写E序Q然后相信重构会(x)解决所有设计的问题。很有趣圎ͼ他们说得没错Q这有可能是 XP 的缺炏V无疑地Q最U极?XP 专家Q像 Kent Beck, Ron Jeffries, ?Bob MartinQ尽其所能地避免预先l构性的设计。在你知道真的要用到数据库之前，不要加入数据库，先用案来代替，在之后的阶段再用重构加入数据库?/P>
我常被认为是一个胆的 XP 专家Q这Ҏ(gu)不同意。我认ؓ(f)一个概括性的初始架构有它的用处在。像是一开始要怎么应用分层，如何与数据库互动 (如果你需要的?Q要使用哪种方式d理网站服务器?/P>
基本上，我认些就是近q来我们所研究?patterns。尤其当你对 patterns 的认识越深，你就?x)越熟(zhn)要怎么d用它们。不q，关键性的差异是在于这些初期架构的军_是可以更改的Q只要团队认Z们早期的判断有误Ӟ应该要有勇气去修正它们。有我讲?jin)一个项目的故事Q就在项目快要发表时Q决定了(jin)不再需?EJBQƈ且要它们从pȝ中移除。这是一个相当大规模的重构，不过最后还是完成了(jin)。这些有效的实务技巧不仅让事情变得可能Q而且很值得d?/P>
如果以不同的方式来做qg事呢Q如果你军_不采?EJBQ将来会(x)难以加入吗？你是否要在试q各U方式却发现依然Ơ缺什么，然后才?EJBQ这是一个牵涉很多因素的问题。不使用复杂的组件当然可以增加系l的单度Q而且可以让事情进展比较快Q但有时候从pȝ中抽掉某个部份会(x)比加入它要容易多?jin)?/P>
所以我从评估架构可能的样子开始。假如你看到会(x)有多个用者用到大量的资料，一开始就直接使用数据库。若你看到很复杂的商业逻辑Q就套用 domain model。你?x)怀疑是否偏ȝ单的Ҏ(gu)，q当然不?YAGNI 的精。所以你要有所准备Q在发现所使用的结构没有帮助时快化你的结构?/P>
UML and XP
在我投n?XP 领域之后Q由于我?UML 的关p让我遇C个挥之不L大的问题Q这两者不是不兼容吗？
当然有些不兼宏VXP 昄不重?diagram。虽然台面上大家?"好用q" 有共识，但是实际上却?"实际上采?XP 的h不画蓝图"。这U印象因为如 Kent q些Z?fn)惯作图的现象而强化了(jin)。事实上我也从来没看q?Kent d使用固定的标记法M软g蓝图?/P>
我觉得这U情形来自两个因素，其一是有得Y件蓝图有用，而有Z觉得有用。难难在觉得蓝图有用的Z是真正必d手做的hQ而必d手做的h却不觉得有其必要性。事实上我们应该接受有h喜欢用，而有Z喜欢用?/P>
另一U情形是软g蓝图常引入繁重的程中，q些程耗时费力却不见得有用Q甚臌?sh)(x)生坏处。我认ؓ(f)应该教导Z如何使用蓝图却不落入q样的陷阱，而不是像那些提倡者仅仅消极的?"必要时才??/P>
所以，我对于有效用蓝囄是：(x)
首先别忘?sh)(jin)你画这些图的目的，主要的h(hun)值在于沟通。有效的沟通意味着选择重要的部份而忽略不重要的部份。这L(fng)选择也是有效q用 UML 的关键。不必把全部?class 都画出来Q画出重要的好。对于每?class 也只昄关键?attribute ?operationQ而不是全部显C出来。也不要为所有的 use case 和步骤画循序?.. 除非你已l有完整的想象。有一个用蓝囄通病是Z通常希望详细完整的把图表现出来。其实程序代码就是提供完整信息的最x(chng)源，同时E序代码本n也是保持信息同步最单的方式。因为图形的巨细靡遗是一目了(jin)然的敌h?/P>
蓝图的用途是在开始撰写程序代码之前探讨设计内宏V印象中L觉得q样的动作在 XP 是不合法的，但ƈ不是q样。很多h都说如果你遇到棘手的问题Q就值得先做些设计。但是当你进行设计时Q?/P>
保持短?/P>
不要做得太详l?只挑(xi)重要的做)?/P>
把结果当作是草图Q而不是定案?/P>
最后一点值得深入探讨。当你做预先式设计，无可避免的会(x)发现一些错误，而且是在撰写E序代码的时候才发现。如果你适时变更设计Q它?yu)׃是问题。麻?ch)的是如果你认定设计已经定案Q没有从 coding q程学到l验而跟着先前的设计将错就错?/P>
变更设计不代表一定要更改蓝图。画q些蓝图来帮助你?jin)解设计Q然后就把图扔开Q这么做是非常合理的。这些图能够帮上忙就有它的h(hun)g(jin)。它们不必永q存在，最有用?UML 囑Ş也不?x)是收藏品?/P>
不少实行 XP 的h使用 CRC 卡，q与 UML q不冲突。我常常交互q用 CRC 卡和 UMLQ我也L依照手上的工作选择最有用的技巧。UML 囑Ş的另一个用途是持箋(hu)修订的文件。它一般的形式Q就是在 case tool 中看到的模型。最初的x(chng)是留着q样的资料有助于建构pȝ。事实上却常常没什么用?/P>
保持囑Ş的更新太花时_(d)最后常无法与程序代码同步?/P>
它们隐含?CASE tool ?thick binderQ让人忽略它?/P>
所以要希望q种持箋(hu)修订的文件有用，׃q些看到的问题(sh)手：(x)
只用一些改h不至于让得痛苦的图?/P>
把图攑֜昄的地斏V我喜欢d墙上Q鼓励大家一起动手修攏V?/P>
(g)讨这些图是不是有人在用，没用的就擦掉?/P>
使用 UML 的最后一个问题是文g的交接，像是不同团队的接手。XP 的想法是文g像说故事，所以文件的价值由֮来决定。于?UML 又派上用场，所提供的图形可以帮助沟通。别忘(sh)(jin)E序代码本np含了(jin)所有详l的信息Q图形的作用只是提供概观以及(qing)标示重要的部份?/P>
On Metaphor
好吧Q我也许该坦?- 我一直没有抓?metaphor 的精。它有用Q而且?C3 目中运用得很好Q但是ƈ不表C我知道怎么用它Q更不用说要解释怎么用了(jin)?/P>
XP 实务技巧中?Metaphor 是徏立在 Ward Cunningham's 为系l命名的做法上。重Ҏ(gu)惛_一个众所周知的词汇，以这样一个字来比L个范畴。这个代表系l的名字?x)套用?class ?method 的命名上?/P>
我以不同领域的观忉|模型，利用 UML 和它的前w与领域专家一起徏立了(jin)一个命名系l。我发现你必d心(j)Q你要保持最_的注释，而且要当?j)别让技术性的问题?sh)知不觉的?jing)响这个模型。但是一旦你完成q个工作Q你可以ؓ(f)各种领域建立一l词汇，q些词汇是大安能了(jin)解ƈ且可用来与研发h员沟通的。这U模型无法与 class 设计完美的吻合，但是_l整个领域一个通用的代名词?/P>
目前我找不到M理由说明Zq样的一个字汇无法成Z个比喻，像 C3 q个成功的例子；我也不觉得以pȝZ扑ֈ在该专业领域的一个词汇有什么坏处。同时我也不?x)放弃可以运作自如的为系l命名的技巧?/P>
Z常批?XP 乃是Z觉得一个系l实在是臛_需要一个大概的设计。XP 专家则以 "是 metaphor 啊！" 来响应。但是我q是没有看到一个对?metaphor 令h信服的解释。这?XP 的缺憾，必须?XP 专家来理出头l?/P>
Do you wanna be an Architect when you grow up?
q几q来 "software architect (软g设计?" 来热门，q是一个就我个言难以接受的名词。我太太是结构工E师Q工E师和徏{师之间的关pL... 有趣的。我最喜欢的一句话是：(x)建筑师对三种 B 是好的，灯(chng)、灌木丛、和鸟。因为徏{师dq些丽的图画，但却要工E师保证能做出来。结论是我避?software architect 一词，毕竟如果q我的太太都不能重我的专业Q我又怎么能对其他人有所期望呢？
对Y件来_(d)architect 一词可以代表很多事情?软g界很多词都可以代表很多事? q通常W合一句话Q我不仅是一个程序员Q我q是一个设计师[译注2]。还可以q一步解译成Q我现在是一个设计师 - 我对于完成所有程序来说太重要?jin)。然后这个问题就变成Q当你要展现技术领导的时候，你是不是该把自己与烦(ch)琐的E序撰写分清楚？
q个问题引v众多的不满。我看到Z对于再也无法担Q设计角色q样的想法感到生气。我最常听刎ͼ(x)?XP 没有设计师的挥洒I间?/P>
p计本w的角色来说Q我不觉?XP 不重视经验或好的设计。事实上多位 XP 的提倡?- Kent Back、Bob Martin、当然还?Ward Cunningham - 都是我从而学?fn)设计的对象。然而这也代表着他们的角色从大家既有的印象中开始{变成为技术领D?/P>
我将以一?ThoughtWorks 的技术领D?Dave Rice Z。Dave 参与?jin)很多个研发周期Qƈ且非正式的指g?50 人的目。他担Q指导的角色意味着要花很长的时间与E序员(sh)ؓ(f)伍。当E序员需要帮助，他就介入Q否则就留意着看谁需要协助。他的位有一个明昄特征Q担M位长期的思考工作者，他可以在M形式的办公环境适应良好。他曄与发行部l理 Cara ׃n办公室一D|间。而在最后几个月Q他更是搬到工程师们工作的开攑ּI间 (像 XP 组喜欢的开攑ּ "战斗I间")。这么做对他很重要，他可以知道事情的q展Qƈ适时伸出援手?/P>
知道 XP 的hp够了(jin)解我描述的是 XP "教练" 的清楚角艌Ӏ的，?XP 玩的文字游戏中提到领导技术就是在描绘 "教练" q个角色。其意义是很清楚的：(x)?XP 技术的领导特质是透过教导E序员和帮助他们做决定而呈现。这是一U需要良好h际管理和技术ƈ重的技巧。Jack Bolles ?XP2000 _(d)(x)孤单的大师有Ҏ(gu)?x)?jin)Q合作和教导是成功的关键?/P>
在研讨会(x)的晚会(x)上，我和 Dave 在谈话时?XP 有了(jin)些对立的意见。当我们讨论C前的l验Q我们的Ҏ(gu)有相当的cM。我们都偏好 adaptiveQiterative developmentQ也认ؓ(f)试是重要的。所以我们都对他反对的立场感到疑惑。然而他提到 "最后我要的是程序员照着设计忙于重构"。事情一下子明朗h。后?Dave 又对我说 "如果我不信Q我的E序员，我何必要用他们呢Q?Q观念上的隔阂就更加清楚?jin)。在 XP 里头Q有l验的研发h员所能做的最重要的一件事是量所有技术传l给新手。不同于一个决定所有重要事情的建筑师，你有一个能够教导研发h员如何做重大军_的教l。就?Ward Cunningham 指出Q这么做不只是增q了(jin)新手的能力，寚w目的好处更大于一个孤立无援的h所能做的。[ 译注7]
Things that are difficult to refactor in
我们能用 refactoring 来处理所有设计方面的军_吗？或者，有些问题太普遍而且难以在将来加入设计中Q此ӞXP 的正l做法是所有需求都可以L的在需要的时候增加，所?YAGNI L能够适用。我猜是不是有例外？有一个不错的Q被讨论到的例子是Y件的国际化。这是不是一U现在应该立卌行，否则以后再加入时?x)觉得痛苦的事情Q?/P>
我能L的想象一些事情就是这U情形。事实上我们仍然掌握太少的信息。如果你必须陆箋(hu)加入一些功能，如国际化Q而你知道那需要多工夫。你比较不容易意识到在你真正需要他之前Q你要花多少旉加入它，q且要长旉的维护它。你也比较不Ҏ(gu)察觉C怽可能做错?jin)，所以到头来q是需要做?refactoring?/P>
有一部䆾能够?YAGNI 辩护的理由是有些预先做的功能可能最后ƈ不需要，或者它q不如预期的l果。不做这些所省下的力气比?refactoring 来更Ҏ(gu)为符合需要所用的力气要少?/P>
另外一个要想的问题是你是否真的知道怎么做。如果你有很多次做Y件国际化的经验，你会(x)知道该用什么模式来作。那L(fng)情Ş下你应该?x)把它作好。这时你所加入的预留的l构可能?x)比你头一ơ处理这U问题要好。所以我的想法是Q如果你知道怎么做，你就要考虑现在做和来做，两种情Ş之间不同的成本。反q来_(d)如果你没有处理过那样的问题，不仅是你无法正确判断需要的成本Q你也比较不可能把事情作好。这U情形，你就要选择来再做。如果你q是执意做了(jin)Q而且到苦果Q可能会(x)比不做的情况更糟。当你的l员更有l验Q你对相关领域有更多认识Q你寚w求也?x)更了(jin)解。通常到这时你回头看才?x)发C情有多简单。提早加入的设计比你惌中要隑֤?jin)?/P>
q个问题?sh)?stories 的顺序密切相兟뀂在 Planning XP 一书中QKent 和我公开的指出我们的歧见。Kent 偏向于只让商业h(hun)D一个因素媄(jing)?stories 的顺序。在短暂的意见不合之?Ron Jeffries 也同意这U想法。我仍保持怀疑。我怿在商业h(hun)值和技术风险之间能扑ֈq炏V基于这L(fng)理由让我提早Y件国际化做准备以降低风险。但是这U做法也只有当第一阶段发行需要将软g国际化才能成立。尽快达C个阶D늚发行是非帔R要的。Q何原来不需要而后来必d加的复杂性都值得在第一阶段发行之后才开始。发行之后运作中的程序有强大的力量，它抓住顾客的注意Q增加信Lq且是一个学?fn)的好机会(x)。就是在初ơ发行之后会(x)有更多的事情要做Q还是要所有努力将W一阶段日期往(xin)前推?/P>
So is Design Dead?
没什么原因，只是设计的本质已l改变。XP 的设计追求以下的技巧：(x)
持箋(hu)保持清爽的程序代码，简单越好?/P>
重构的技巧，所以当你觉得必要的时候都可以有信?j)的动手?/P>
h patterns 的知识：(x)不只是照它的解法Q更要感觉何时可以应用，或是如何导入 patterns?/P>
知道如何设计说l必要的Z(jin)解[译注8]Q用E序代码、或是图形、或上述所有的工具Q交谈?/P>
以上?xi)出来的技巧看来都挺吓人，但是要成Z个优U的设计师本来很难。XP 也不是要让它变得单，臛_我就不觉得。但是我?XP 让我们对有效率的设计有全新的看法Q因为它让渐q式设计听v来是可行的方式。而且我也很支持演q?- 否则谁知道我?x)变成什么呢Q?/P>
Acknowledgements[译注9]
q去q些q我从很多好朋友w上偷学C好的想法，很多都已l记不v来。但是我记得?Joshua Kerievski 那里偷到的好东西。我也记?Fred George ?Ron Jeffries l我很好的徏议。我当然也不能忘?Ward ?Kent 不断有好的想法?/P>
我也感谢曄提出问题和指出打字错误的朋友。同时感?Craig Jones 提醒我好几个漏掉?“a”?/P>
Revision History
以下是这文章重大的修改记录Q?/P>
2001 q?2 月：(x)?growing an architecture、the role of an architect、和 where things that are difficult to add with refactoring {段落做修改?/P>
2000 q?7 月：(x)原始文g?XP 2000 发表Qƈ刊蝲?MartinFowler.com |页?/P>
[译注1] 一U在着手进行程序代码的撰写之前Q就先按照既定的E序分析、设计、制图、撰写文件等{耗时费力的工作方式?/P>
[译注2] 在台湾你觉得 “程序设计师”、“Y件设计师??“Y件工E师?有什么不同吗Q相信大部分的h觉得都是同一U角艌Ӏ但是从英文字意比较容易区?“programmer”、”designer”、”architect”等{不同的角色。这L(fng)语言文化差异性，也是我在内文中留下不原文的原因。在部䆾字句中，留下原文q不影响阅读的顺畅，但是可以避免文意因ؓ(f)译所造成的模p或扭曲?/P>
[译注3] 在徏{业应该是称?“施工h员?比较I而在软g业应该是 “programmer?比较恰当。但是这两者都?“builder”?/P>
[译注4] 关于q一点，译者也提供一个实际的l验Q也是译q篇文章的过E。我和一位朋友一L(fng)译这文章，而且因ؓ(f)都先看过 XP Distilled 一文，所以决定采?XP 12 个有效的实务技巧其中的 Continuous Integration、Pair Programming、Small Releases、Refactoring、Coding Standards、Collective Code Ownership {等技巧。因?XP Distilled 一文的l验我们首先对于部䆾译名词提出彼此的统一版本Q这是一U?Coding Standards。我们同旉对这文章进行翻译，不同的hq行同一工作进度就不会(x)相同Q每译几个D落将q度寄给Ҏ(gu)Q这是 Small Releases。当我收到朋友寄来的部䆾Q我对照两方的差异文章针对译意的正确性和辞句的通畅做初步的整理和修正，q就?Continuous Integration。我整理q的部䆾再寄回给朋友q行(g)查，如果发现不妥的部份，p行讨论或修改Q这是 Refactoring。从头到q程中，我们都收到彼此的译版本Q也拥有整理q的版本Q对于每个部份也都清楚了(jin)解，W合 Collective Code Ownership 的精。最后，因ؓ(f)我们刚好是两个hQ不巧又可以冠上另一个技巧Pair Programming。所以，我们使用?XP 一半的Ҏ(gu)Q对于工作上有帮助的Ҏ(gu)。但q不是非得每一Ҏ(gu)巧都利用到。我惻I更重要的一Ҏ(gu)QXP q不是只能用在Y件研发，我们的翻译过E不也借来用了(jin)Q?/P>
[译注5] Story 是一U类?use case 的描q?/P>
[译注6] 按照原文的意思就是以 32 行的E序代码而能够表现出 16 U?patternsQ这L(fng)传奇性功力实在不是经验及(qing)见识薄的译者所能想象，所以我们只能按照原文翻译，而无法对q句话提出左证。如果读者见q作者提到的例子Q很感谢(zhn)提供相兌料给我?/P>
[译注7] q一点也是译者对于台湾Y件环境非常忧?j)的问题Q大安能体?x)中国h的一U不知道能不能说是重大缺点的民族?fn)?“藏U”。我在不同的Z(x)从文章中以及(qing)朋友的口中听CU想法，要提升团队的整理效率Q一U最单的Ҏ(gu)是技术落后的成员教育提升C技术领先的成员相同的水q뀂这L(fng)x(chng)实在是一U非常有用而且深刻的体认，更是一U感叏V在台湾能够在口头上同意q种做法Q而实际上更能够进而实践这U精的人有多少Q？有些人都担心(j)自己的技术被人窥透之后，个hC恐将遭到取代Q更遭的是可能有老板真的?“狡兔死走狗烹?的在榨取l验的传承之后，有贡献却成本高的成员(sh)各种方式DQ这实在是让人忧?j)又灰?j)的现象啊Q译者相信，再困隄技术只要是你能?jin)解Q就已经存在?jin)竞争对手，如果不能nҎ(gu)员的技术水q_时迅速提升，只有{着被快速超，更可能被淘汰。译者也实践着 XP q方面的_Q虽然译者所拥有的技术知识非常粗，但是只要同事朋友需要我的协助，我L知无不言Q言无不。译者要向流星许愿，希望能够扑ֈ来多的同cR?/P>
[译注8] 有效的沟通也是译者常遭遇的问题(sh)一Q有些h无法以不同的方式Z情下Ҏ(gu)Q有些h对于门外汉还是满口专业术语，有些Z能观察顾虑到听者是不是已经?jin)解所阐述的精髓。这些都不是有效的沟通。我们似乎还?sh)够重视人际沟通这门学问，如何以对方能懂的方式说给Ҏ(gu)听，真是不容易呢Q译者只是发出感叹，却也亟需要培L通能力，才不?x)让׃的同事摇头?/P>
[译注9] 译者之一的我 (Daimler) 也要搭个风车，感谢朋友 (S.H.Chen) 在百忙之中抽IZ我完成这文章的译Q这位朋友在软g工程斚w的知识给我的帮助非常关键。翻译本w就存在不少争议Q应该按照句子逐字译Q还是要考虑依据本国文字的用语习(fn)惯做适当的调_(d)以求字句的通顺Q真的让人难以取舍抉择。我 (Daimler) 是比较們于在不扭曲原著作文意的原则下Q对句子做适当的重l和调整。但是这个动作本w就存在着非常大的危险Q我对于原文是否有够的认识Q我对于本国文字的造诣是否?qing)格Q希望这文章对于国内读者能有所帮助Q至是效率上的帮助。更期盼来自各方的指教?/P>