|
Doug Rosenberg及Kendall Scott对于XP的质疑
原文(摘自文章集锦)繁体中文
介绍
终极制程(Extreme Programming (XP))提供一些有用的概念。我们相信强调测试及他们的指引原理是有重大的价值；这些原理在软件开发程序的发展上非常有用。但是不管如何；暧昧的主张(dubious
claims)、明显的缺乏可达成性(scalability)、动听但是问题重重的口号及极端的(Xtremist)姿态几乎掩盖了良好的本质。
Doug曾经在OTUG(Object Technology User Group)中有过广泛的讨论。其中有些是相当有用的，有些则是愚蠢的，有些仍有问题亟待回答。Kendall花了相当长的时间详读Wiki网站上的文章。下面大多数的探讨XP的结构及程序(ritual)是依据这些交谈及研究。
--------------------------------------------------------------------------------
暧昧的主张
Kent Beck及其主要的追随者曾经定位XP是一种『轻量级(lightweight)』程序；这个开发程序可以产出较高品质；以及在一个更及时性的基础上；然后由更细节的程序所组成。（XP人(XPers
)偏向归因这些所使用的术语如大设计(Big Design)<译注1>，我们在这整篇文章中也使用这个术语。）然而在这个『程序』的核心有一个相当大的漏洞：分析基本上以被抛出(tossed)。
让我们看看一些主张；XP追随者把跳过大设计的分析中『笨重(cumbersome)』的成分做了合理化。
--------------------------------------------------------------------------------
每周改变的需求
依据XP人的说法，处理那些变动的需求在需求的前置(upfront)分析至少有两个主要的缺点：
大设计寻求控制改变的机制，经由早期获得及一般性的一次解决所有的需求及架构。实际上多数的大设计方法有详细的结构承担必然发生的外部变动，但这些机制往往似乎是或多或少在程序中属于次要的。
大设计视任何不确定情况是一种危机。如果有一些事情是我们不知道的，我们无法推理它们。
这些由Doug所接收到记录的言词，经与OTUG联系，其答复是：「你说前置(up-front)『 撷取需求(capture requirements)』，但坦白的说真的吓到我了，因为我从几哩外闻到『瀑布式』。」
甚至，XP阵营的感觉是客户对于其在项目中相要的只有一点点的概念。有一个信徒甚至宣称「一开始客户不可能了解他们真正所想要的。」甚至当客户当初指出他们的需求，他们在几周之后坚持改变这些需求，而有时是每天的改变。因此，在跳入程序撰写之前尝试冻结需求是没有意义的。
我们同意需求分析及撷取是充满困难及不确定性。但Doug曾经在许多业态中做过多个项目，其中他的客户或多或少控制避免如此的优柔寡断。不，在你开始构建你的系统之前你无需撷取所有个别的需求，但我们坚持某层次的前置分析可以解省你一路上许多时间。
有时在开始撰写程序代码之前要求客户精炼(refine)他们所了解的并指出他们想要的是有用的，客户希望从开发团对中获得一些训练(discipline)：而同时要求客户提出一些训练也是全然合理的。如果客户真的对他们所想要的没有任何概念；当他们看到一些可执行的东西；雏形（以实际的程序代码建立的）是一个很好的技术可以帮助客户获得清晰的了解他们所想要的。那是与客户合作的一种良好分析的工作同时可以帮助客户精炼他们所了解的。
确实有这种情况；当开始撰写程序之后客户的需求改变了。我们假涉有任何的可能性，这些改变在下一构建循环中获得控制。若那是不可能的时候，你应当尽你最大的能力去做。许多XP技术在「尽你最大的能力去做」大概是相当的有价值的。
有人问Daug「如果你后来发现客户的需求已被曲解而修正需要从设计的基础改变你会怎么办？」真正的问题是，这种情况发生的频率有多高，而我们需要多辛苦事先避免产生这种情况？而这正是嘲笑『分析』程序为其本身付出太多时间。我们作分析以避免这种情况的产生。
--------------------------------------------------------------------------------
使用案例(use case)太复杂
XP建议你以『使用者故事』撷取需求。这是相对使用案例；XP人一般的感觉是使用案例只能在详尽的细节架构使用者的需求，在长长的格式中有太繁重的东西要去填入。引用Wiki网页诚实的传达XP群体对于使用案例感觉：「我的目标是维持介于企业(business)与开发之间策略权力(political
power)的平衡。我曾看过的使用案例的应用太过复杂且正式(formal)以致于商业一方不想去接触使用案例。这导致开发一方询问所有的问题并写下来所有的回答并且承担所有结果的责任。商业一方简化成只坐在桌子的另一边并指指点点的。」
这是我们看这件事的方式。
一个使用案例是一系列的活动；其中一个活动者(actor)在一个系统中执行以达成特定的目标。关于其定义并没有特别的复杂，或太过正式。
使用案例是最有效说明使用者的观点；其中是以动词词组表达活动。这表示使用者需要有一个清晰的了解这一系列的活动是他期望依循的，那确实意味着客户是主动的参与使用案例的细节。如果所了解的不是这些，那么使用案例是太复杂需要精炼--你知道，就像程序代码迫切需要重整(refactoring)。
在我们的经验中，『分析瘫痪(paralysis)』在关连到使用案例塑模(modeling)至少可能有三种发生的理由：
团队花费几周的时间构建精心制作精致的使用案例模式而无法据以设计。
团队空转于忧心是否使用任何或所有的UML构词(constructs)『include』、『extends』及/或『uses』。
团队浪费时间在长及复杂的使用案例样版（有趣的是，我们似乎或多或少同意XP人这方面的观点。）。
XP信徒显然指熟悉导致分析瘫痪的一类使用案例。我们说如果你以使用案例连接(in conjunction with)频繁的雏形法推导(derive)，并且/或从旧有(legacy)文件（特别的，使用者手册）挖掘使用案例，而你仍高度全时间聚焦于你的客户，你非常有机会在你开始做之前指出你所需要做的，同时结果将是显著的一路安全的走下去。
--------------------------------------------------------------------------------
修复的成本曲线是平缓的
Kent Beck曾经宣称改变程序代码中的臭虫的成本与改变设计臭虫的成本一样的，因为程序代码是设计。我们在后面会说明这个理论的基础上的愚蠢，但同时我想要指出由于Xtremists从图形吹嘘其分析，那是
导因为果(circular reasoning)。
其推论如下。如果我们在撰写程序之前并未作分析及设计，那么没人可以断言在我们开始撰写程序设计之前修复错误是比较便宜的--因为没有「在我们开始撰写程序之前」这件事情。迅速的，修复的成本曲线从对数变(logarithmic)成线性(linear)。
让我们稍微重新叙述：
我们可以是软件开发为一持续系列的撰写程序、测试程序代码、拆解(ripping)程序代码、重新测试程序代码、重新撰写程序代码、重新测试程序代码如此不断的循环。
这些都是相同的动作，加上一些分析及设计交杂持续进行。因此，程序代码变动的成本是线性的与你何时发现需要改变没有关系。这类的导因为果的声音对我们而言就像...嗯，就像有人在推销一些东西。
直接的比较这些循环论法(circular arguments)是我们的经验；我们的经验中有许多错误瘫痪项目的方式是「我认为那是红色的（或可能是津贴），而你认为是蓝的（或可能是扣项）。」此种不明确说明的假设进入程序代码并且被证明其本身是潜伏的臭虫。当这些不明确的假设进入架构本身，我们主要看到的是诅咒并且重写（及重测试）的动作。
我们并不相信任何宣称任何事可以使得这项工作免费的。拆解并重写绝不可能是免费的。如果拆解并重写是『常态』的，也不可能是免费或便宜的。可能使得曲线异乎寻常的平坦，但仍然不视线性的。我仍未看到任何证明Barry
Boehm所做的研究是虚假的，他的研究显示当你从分析移动到发行产品之间修正一个错误的成本是以指数递增。重复宣称成本曲线是不可思议的平缓并不能成为事实。
--------------------------------------------------------------------------------
明显缺乏可达成性(Scalability)
让我们看看为什么XP相关一个项目时似乎不像可以达成并且成功；其中这些条件似乎尚未出现。
--------------------------------------------------------------------------------
Pair Programming
在理想的XP项目当中，开发者是成对的工作，而且也不是静态的成对：依据哪些事要做而谁知到怎么做，人们可能变换伙伴一天好几次。这个想法；当然；是立基于格言「两个头脑比一个好(two
heads are better than one)」。就其本身而论，尝试去遵守这个原理是非常恐怖的。
但当你无法在一段有意义的时间内让你所有的开发者同在一个地方；在一个『牛栏』内（假设有一个可用的地方）；会发生甚么事？事实上世上有许多开发者并不是真正喜欢这类的坚强的沟通及社交技能；而这些在XP架构下是很明确需要的；面对这个事实你要怎么办？当每一个人为每一件事情争功时，你如何掌控任何人的应负的责任？
如我们在这本书所描述的，最好的方式包含在高阶及初阶人员之间实作一组检验及平衡，例如；我们建议比较没有经验的人审查系列的图形；这些开发者使用重要的OO专家产品。双人组程序设计显示出这个想法到一定程度，但双人组程序设计同时假设一对一配对总是可行的；而这个简单的说在许多背景中并不是实际可行的。
嗯--可能如果那是称为双人组分析、设计及程序设计，我们将会比较满意...。
关于双人组程序设计并没有任何事是天生邪恶的--还是可能获得一些利益--但双人组程序设计对我们而言看起来是意图补偿分析的缺口；因此强迫两个人检视他们所撰写的每一行程序代码。这类似强迫幼儿园小朋友走向餐厅时两两牵手因为你无法信任他们不会毫无目的的随意漫游。
以另一个方式来看：我们两个一对下棋天生的每一盘棋都一定输给Garry Kasparov，既不是伙伴系统也不是『详尽的测试』可以补偿前置规划的缺口。毕竟，Garry非常小心的规划他的策略。
--------------------------------------------------------------------------------
索引卡
XP一族倡议使用类别-责任-合作卡(Class-Responsibility-Collaboration (CRC))。目前；这些卡被重视并广泛的使用--但只限于相当小的规模。CRC卡的设计确实不是用来撷取特别的细节，而像我们做研究论文在我们发掘内在的知识之前使用都是不错的，它们是保持记录的佼佼者。而你如何期望在有一段距离在开发者之间传递索引卡？
我们客户中之一有位主任建筑师花了许多时间与其它的程序设计师工作。事实上，他花了太多的时间以致于他没有足够的时间给他的新材料他需要做的，这使得他相当愿意参与获得一些他的设计文件。很不幸的，这家公司的开发者位于两岸，因此整个「每一个人在一个大房间中共享索引卡」的想法是有点距离的。使用E-mail传递
模块对他们而言将是较好的方式。同时，我们相信客户在下一版本的产品中使用塑模做更好的工作会是相当成功的， 同时透过提供更可视化于架构及设计他们将能够明显的降低他们的延迟次数。
我们看过非常少的开发成果而没有一些颇为严肃的议题需要除里。尤其是快速成长的公司；其中新项目的大小较之刚开始时更是快速的成长。我们建议使用一个好的可视化塑模工具把开发的工作放在显著强壮的基石上而不是做一串苏散四处漂浮的索引卡。
--------------------------------------------------------------------------------
缺乏责任性
XP拥户者坚持大设计趋于只是让人们；理论上；有特别的知识及技巧以执行确定的任务（你知道；这个团队必须包括类别库及一个架构设计师及一个技术撰写者等等）。于此，XP说「每一个人做每一件事，」以直接响应对于『大设计占便宜的事实是有些个别的人比别人较有资格做某些设计决策』的认知。但现在我们会相信开发者将都会立即变的热衷于必须真的以让新人可以独立了解的方式写下东西吗？（同时；不管如何；有好的设计者执行设计有甚么错吗？）
事实上，如我们将在在本文后面探讨的，XP拥护者宣称适当的重整(refactoring)程序代码是或多或少自我文件化(self-documenting)，而所有其它的文件形式太不可信赖而值得存在。这是他们对于『口头的传统(oral
tradition)』太过于聚焦的部分合理化，同时他们认为保持东西是如此重度的依赖让所有的关键信息被维护在同一个地方。毕竟；程序代码外部及所有这些索引卡；并没有变成任何文件上的东西，对不对？但那只是没有务实的思考这是将为任何项目工作；而有更多的开发者聚在一个房间之内。不错；沟通管道的数量在人们加入项目时以指数方式增加，同时；我们在本书中倡议一个相当简易(minimalist)的方式，但XP的方式只是太过简易而无法在所有的项目中可用。
--------------------------------------------------------------------------------
一个XP替代方案：『聪明制程(Smart Programmers(SP))』
一般而言，多数我们的客户对于这种没有大小限制(scale)的解决方式没有太多的兴趣。不管如何；如果小规模(small-scale)解决方式是你所想要的，这里有一个Doug曾经经历过的；这是本文中的一个目的我们称之为『SP』。
如果你是靠自己的力量经营一家没有太多可冒险的资本的公司SP是非常有用的。它的基础理论是所有程序设计师中5％（或更少）做95％（或更多）的工作，而且只有只有这些（5％）程序设计师值得聘请。
SP的本质如下：
只需聘请前面5％执行的人是你个别认识的，或你信任的前5％的人员。
让一个主任架构师(chief architect)非常小心的规划软件工作单元架构；如此单元（即UML包裹）之间有极小的耦合性(coupling)。
让主任架构师比对SP成员的特殊专长及经验。
让所有的SP程序设计师在家工作，在家中他们不会受干扰，除非他们明确的要求在一个共通的工厂中工作。
限制状况报告为半页，并透过E-mail每周传送一次。
让你的SP成员当他们认为他们已完成时导入渐进式建立测试。
限制(restrict)SP开发者在需要的时候只能透过E-mail或电话沟通。绝不要把所有的程序设计师同时带进一个房间内；除了在整合测试时，以及只有在他们的程序代码是完全的含入。
现在，你可以以这种方式建立非常大量的程序而只使用非常小的团队。Doug的经验指出生产力水准更高过于XP所举出的克赖斯勒薪资专案。
此外；生产力将比XP所产生的更高。不管如何，尝试让主任架构师跳过分析及前置规划，或做了一个坏的聘请的决定，你会在你手中产生一个灾难。我们绝不会麻烦的使之形式化或甚至命名，SP技术因为其没有大小限制及没有错误的限度。就我们来看像XP可能也如此装腔作势。
<译注2>
--------------------------------------------------------------------------------
响亮但问题重重的口号
如果你想要的是一个立即让你难忘强而有力的口号，XP正是指引你一条路。毕竟，就如XP的训练现在已经很清楚，「软件也是...很难花费时间在没有意义的事情上，」这类的主题很容易变成一种口号。让我们看看一些XP人呼喊整体重新整合相关的关键惯用语(phrase)。
--------------------------------------------------------------------------------
只有四件关于软件重要的事情
这是最大的一个，XP存在的理由。这四件事是甚么？撰写程序、测试、倾听及设计（从前的重整(refactoring)）。
喔，同时别忘掉：「这里所有的都是关于软件，任何人告诉你的与此不同都只是在推销东西。」
就如我们之前指出的，『分析』并没有使得时间缩减。（这可能是Beck在OTUG有些事情与某件事情：「我以真正的名称称呼分析：说谎。」）更重要的，既使，博学多闻的人知道关于软件恰巧有七件重要的事。（我们不想在此分享，但在我们的书中可以找到，如果先前你不是很有知识）
尽管；严肃的如此热烈的宣称软件开发只有四种元素是有意义的；是极端的超越现实，甚至还有些事情称之为XP。
--------------------------------------------------------------------------------
原始程序代码就是设计
我们承认从这个得到相当大的刺激(kick)，这不是最不重要的因为我们曾写个一个笑话「使用案例(use case)不是需求」；而在我们的书中有类似的。在Wiki的首页上中的评论像「当你重整，你是在进行细节的设计」，这就像我们将在另一本书中做的那至少有一个章节说明针对驳斥这类的废话。
重整是一种极为迷人的主题，我们希望在Martin Fowler的书中证实。我们确认那将提供我们许多有用的技术以改善我们的程序代码。但设计是设计，而撰写程序是撰写程序，把他们视为相同的一件事是愚蠢的。UML之神（好吧，三个其中之二，不管如何）基本上忽略初步的设计是很不好的，现在我们必须处理Xtremist狂热的扭曲细节设计的概念而超越所有的认知。
每次我们看到争论我们喜欢总结如「改变程序代码是那么的便宜；不管我们是否从设计做起。」我们都会感到胃痛。这正是我们要尝试指出是甚么导致的种感觉及去唠叨这件事。
在XP，『甚么(what)』描述是从使用者故事撷取。我们关心的是项目团队如何处理跨越『甚么』及『如何(how)』之间的差距。可见的理由之一是在XP中渐进式发展(increments)是如此的微小，对每一个渐进式发展阶段，介于『甚么』及『如何』之间的差距不仅必须跨越设计层次；那是很难满足的；同时包括程序代码层次。这表示设计错误及程序代码错误将被混杂(intermixed)。
不可避免的时间将花费在修复程序代码错误以便让程序可以执行及测试，而测试将暴露设计错误。设计一经改变，所有花费在修复程序代码错误及测试程序修复部分的精神及时间都将浪费，因为程序代码现在要被诅咒(ripped
out)并取代。在新的程序代码当中也将有新的程序代码错误，而前面的步骤还会再重复。这看起来还是OK，因为程序设计师在程序设计中『获得乐趣』。
使用哪种方式并不是说无法达成--但对我们而言，哪似乎要完成工作需要浪费许多精力及时间。
如果我们没有尝试尽我们的可能做最好的事，所有的时间（而这应包括我们撰写程序代码之前），我们都是马马虎虎。如果我们认为马马虎虎的工作是OK，只要我们快速的工作（「喔，没关系，我们随后可以修改」），我们得到的是一堆垃圾。软件不是与其它的努力(endeavors)在这个观点上有不可思议的差异，不管你有多好的重整浏览器。
在你开始撰写程序代码之前只要证实设计是正确的，你对于项目审查会有最佳的概念，最好的是在初步层次(preliminary level)（以便确保没有人朝向错误的方向快速前进）及细节层次。然后你才开始撰写程序并曾测试获得回馈。
--------------------------------------------------------------------------------
做可能达成的最简单的事情
这个口号说你应该简化、简化、简化。 避免倾向与把你不真正需要的材料构筑入你的程序总是一件好事。但是，我们关心的是那很可能是尽力鼓励开发者把Scotch影带、泡泡糖、橡皮筋杂七杂八的东西随意放置在程序代码中；这种程序是由为充分小心的花时间定义一个坚固的架构所逐渐形成的。
我们最近有一个经验；其中我们经由反转工程(reverse engineering)的工具吸收一些『已完成(as-built)』的Java程序代码并且发现有些方法其名称向bugFix37。很不幸的，任何创造这个方法的人是做可以达成的最简单的事，那只是相当字面上的意义。（我们只能从它的搭挡程序设计师听到回响，欢兴鼓舞的说「嘿，我们正期待做可以达成的最简单的事，不是吗？」）按照纪录，这个有问题的项目不是以XP所建立的，但那是以没有正式的分析及设计所构筑的。
XP其它的指导原理并没有帮助如：如果你认为你可能并不需要的，你并不需要。这类事情有助于鼓励这类与世隔绝(insular)的相法；这种想法导致软件并没有解决任何位于外界人认为值得解决的问题。我们引用Ron
Jeffries的话来加强这个概念：「一个开发者真正需要开始认真工作是直到她已开发她自己的内在品质的意识(sense)，我不期望我的符合你的；我真正希望我们与他们有足够的接触；我们可以与他们讨论并使用我们不同的意识选择一个解决今日满足我们两者内在的尺寸的问题。」悲哀的，在XP除了程序代码每件事都是可视的，我们剩余的期望只是品质保证。
我们还认为一个系统的品质最好是经由耦合性（愈疏松愈好）、内聚力（愈紧密愈好）及完整性的衡量来反应，加上思考像每一类别加权(weighted)方法及子类别投入的数量作为好的衡量。参阅我们的书第5及8章关于至方面的作法(metrics)的更进一步信息。
--------------------------------------------------------------------------------
Xtremist 故做姿态
从另一方面而言，XP人喜欢广泛的争辩关于是否『勇气(courage)』或『进取心(aggressiveness)』是比较正确的说明就处理这些麻烦(pesky)的付钱的人而言他们所处的位置。
从另一方面而言，XP人倾向迷失在新鲜的空气及说一些事如：「XP大师(Master)了解的如此深刻以致于他们无法被了解」
XP的花言巧语让我们觉得那是结合相当高程度的傲慢并且试图模糊使得变得很奇怪。
--------------------------------------------------------------------------------
准备、射击、瞄准
就如统一开发程序(Unified Process)描述的四个阶段（反复(iteration)、精细制作(elaboration)、建构(construction)及转换(transition)）；这些在在项目的每一个反复中执行，XP说的是「故事(stories)、测试(testing)、撰写程序代码(coding)及设计(design)」。强烈的与大设计比较；统一开发程序符号表示法(symbolizes)，XP方法论提供『微量渐进式发展(nanoincrement)』，它的基础是不超过一周的渐进式开发，甚至是短到一天。更快、更快、更快！
我们不反对找到软件开发程序更快速的方法--只要这种方式产生的结果不是「准备、射击、瞄准」。<译注3>
由于拒绝花任何一些有意义的时间指出在开始『生产』之前应做甚么，并且坚持在一个进行中的基础下『以小的方式(in the small)』做大的工作(great
work)；从某种角度当烟幕消散时将神奇的产生整个系统被矫正，XP人似乎认为他们已找到银色子弹(silver bullet)<译注4>以反击大设计的假设：偏向于在细节部分陷入泥沼。
这是一个很明显的短视(short-sighted)方式。我们可以以分析及设计到一个非常可接受的层次降低失败的风险而无须把身体连同洗澡水抛弃。早期进入程序代码撰写并不代表没有风险；这个风险只是不同的本质（在某些情况可能更难以捉摸）。我们应该尝试最小化项目整体的风险层次，而不是部分的风险。
当Doug七年前开始教授OOAD，最通常的失败点是在 训练研讨会(training workshop)；总是发生在从需求层次（使用案例）系统行为观点移动到一个细节设计层次（循序图/合作图）行为观点所做的努力。
尝试跳过这个阶段--在这本书中我们称之为跳过『甚么-如何(what-how)』的差距--从一个纯需求(pure requirements)观点到一个细节设计观点是异常的困难。人们总是发现的是经由增加动态模式（坚实的分析(robustness
analysis)）的『初始设计(preliminary design)』观点，他们持续能够让团队通过这个转换点。
我们仍然能够平衡渐进式开发的利益（可能使用一些较大的渐进式程序），严格的测试及其它可能被证明有用的技术，如双人组程序设计。以这种方式，我们保证我们不止将会总是拥有一个执行的方案(functioning
program)，同时我们可以让最好的开始是『一开始就朝正确的方向』，同时减少对以这种劳力密集(labor-intensive)方式重做及重测试的需要。
--------------------------------------------------------------------------------
文件是无用的
一个真正的Xtremist相信程序代码不只是设计同时是文件。『无情的重整(Merciless refactoring)』（另一个XP用语）将一直一直一直产生完全干净的程序代码；既使是最没有经验的开发者也能够达成。一个信徒杜撰了一个名词『极端的清澈(Extreme
Clarity)』，其中他定义为「一个程序的属性就像程序代码展示每一个人需要知道的系统所有东西；立即上手；一目了然；非常的准确(accurate
to six places)」
我们没有强辩这不是一个我们想要的结果。而就非程序代码(non-code)文件而言，维持与想象中的快速撰写程序代码机制同步的可能性不是真的吗？而口头的沟通比在多数项目中写下来的作用好不是真的吗？总而言之，「所有的文件要被怀疑是过期及主观的偏见」这些声音对我们而言就像一个无理的对文件的恐惧。
事实上，在一个开发成果的背景，够格的技术撰写者知道一些相关程序代码的东西将通常能够赶上开发者及分析者并且维持到目前为止。同时，有效的口头沟通是关键性的重点，但不能免除把数据写下来--为外部的人、为新人、为未来的参考者、为某些目前可能不是很明显的原因。就主观的偏见而言，嗯，所有的写下的都有某种的偏见，但软件文件设想是传达是甚么(what
is)，而不是可能是甚么(what could be)，同时如果那不如此做，不是媒体的错误。
除了口头沟通任何事物的缺乏表示撰写程序代码的人必须回答问题。
依据历史观点，在近半世纪被无数次用作为『工作保障(job security)』的机制。在太多的案例中，这些人把文件放在他们的脑袋中（或者是团对把文件放在他们集体的脑袋中）在维护程序设计师出现时已是过去式了。
这里有一个Doug的故事
「我有一个程序设计师为我工作，负责我们的数据流图编辑。他的进度常常延迟。我们开会讨论这种情况。他说--我引用他的话而我记得非常清楚：『你不能让我更快，你不能让别人来帮助我，你不可以解雇我』他很有信心的说，因为所有的设计文件都在它的脑袋中。我非常震惊于他的说法，第二天我解雇了他。这是我做的决定中最好的一个。我以一个人取代他，这个人所写的程序代码非常好，而且随时把他所做的记入文件中。」
不管如何，为后人记录图表并不是十分重要的事。检视(reviewing)图表--并据以设计--在撰写程序代码之前是十分重要的事。如果你能让团队中的高级程序设计师检视（并修正）系列的图表中将要撰写程序代码的情节(scenarios)，同时你在撰写程序代码之前已查核(verify)架构（静态模式）可以支持所有的情节，你将有一个比较轻松的撰写程序及测试的时光，同时你将使得后续要做的拆开程序代码、重新撰写程序代码及重新测试的工作降至最低。
而这里有从Beck所说的：「多数的人表达他们的恐惧；就是把CRC卡转换成数据库（Notes或Access）、Excel，或某些该死的项目管理程序。」因此我们现在看到XP人把客户视为不确定（考虑他们的需求时）并且恐惧（就持续追踪将要发生的事）。我们期待XP信徒(XPites)证实他们的『怀疑』如此XP可以假设拥有传说中的FUD(恐惧(Fear),不确定(Uncertainty),怀疑(Doubt))三位一体，如以往对微软的观感一般。
--------------------------------------------------------------------------------
询问程序代码
我们很高兴的承认程序设计还是有某一程度的『艺术』的成分加上『科学』的元素这个观点；这个观点是我们更想要聚焦的。但有些Xtremists的说法倾向于让像我们这类非信仰的人觉得XP或多或少有个人崇拜的现象。举例来说：
「重组系统结构(Restructure the system)的基础是系统告诉你的系统想要被如何结构化。」
「程序代码要简化。」
「系统驾驭(ridding)我更甚于我驾驭系统。」
「程序代码异味(smell)是你程序代码当中某部分变糟的暗示(hint)。使用这个异味追踪问题。」
「询问程序代码。」
这个概念；很显然；是只要程序代码实现，便假设有一个神秘的沟通力量，而建立者义不容辞的倾听；小心的听；这个声音...你会非常想睡...啊，抱歉。
这些说法其根本是就Kent Beck而言所有的内容就是程序代码，整个程序代码，除了程序代码以外没有别的。设计代表『幻想(visions)』，分析代表『幻想的幻想(visions
of visions)』，而方法论就是整体代表『幻想的幻想的幻想(visions of visions of visions)』 ，以及「当...幻想成真只会恶化问题』。只要开发者的思考是简化的--另一种说法--只要他们能够只写他们的程序代码而无须所有愚笨的前置材料--他们将「没有压力的工作、没有恐惧的工作并喜爱他们的任务及他们自己。」
有人要来一杯Kool-Aid吗？
--------------------------------------------------------------------------------
结论
XP人喜欢抱怨是如何的没有其它的事。例如，当Doug在OTUG开始指出前置分析是多么好的事情，他得到不只一封的电子邮件询问「你写多少的程序代码，无论如何？」这意涵他写的程序不够多；在Xtremists的眼中不是够格的『真正程序设计师』；
拥有像水一样多的概念却说他不懂得UML的『扩充(extends)』建构式(construct)（我们的书的读者，忠实的OTUG人，已经到这个胡说八道的故事），但这不是重点。重点是XP的拥护者有一种龌龊的倾向羞辱我们是比较喜欢不终极(less
extreme)；但仍然高度的可运转(workable)；尽量建立有品质的软件--而那是太差的，因为有一些好的要素(stuff)在其中。
可能有一天我们将看到一个更合理及平衡的开发程序形式。于此之际，我们同意一位在Wiki的仁兄所言「XP最引人注意的特性是它尝试驾驭(ride)；而不是压制(quelling)在任何真正的程序设计师内心中深沈的要求，那就是要求开辟一条大道(urge
to hack)。
于此之际，我想要以一个问题结束这篇文章。
假如你决定在你的项目中使用XP，而在六个月之后，你觉得这种方式并未符合你的期望。而没有写下任何东西--没有架构或设计文件及在开发者脑袋中没有项目的任何知识。你会怎么办？
Doug Rosenburg：dougr@iconixsw.com
Kendall Scott：onSoftDocWiz?@aol.com
--------------------------------------------------------------------------------
<译注1>大设计亦即前置设计(upfont)，相对于XP的其它开发程序；这些其它的开发程序在开始撰写程序代码之前将所有项目架构做完整的设计被XP追随者称之为大设计或前置设计。
<译注2>SP应是作者故意创造用以反讽XP的一个名词。
<译注3>对于这点Kent Beck及Martin Fowler在『Planning eXtreme Programming』一书中第三章有所说明。
<译注4>银色子弹亦即中文的万灵丹。
|
|