大师打个喷嚏，我们都要重感冒

charon 说的也有些道理，我现在虽然自己学会了 TDD，也清楚了 TDD 的目的，但是对于推广 TDD 也没有多少把握（还是不要强制吧，那样只会流于形式）。推广 TDD 还存在着相当大的社会学问题。所以我会自己去做些尝试，在自己还没有足够的经验前不会随便向别人推销 TDD 的。
charon 对 XP 的怀疑和我读《测试驱动开发》前对 XP 的怀疑很接近，我的怀疑也是两条：
1、TDD 的普适性，是否同时对高手和初学者都有帮助？初学者能否很容易适应这种开发方式？高手是否都喜欢这种开发方式。
2、现场用户的难以获得。

这两条可以说是影响 XP 广泛采用的最大障碍了。TDD 对于个人来说可以说是一种好的开发习惯，但是要强制推广为集体行为就很难说了。我其实更愿意采用 TDD 方式来开发一些开源的项目。

你这个问题根本和体系结构无关的，并且对于这类问题，XP有spike，可以叫做技术攻关吧，把基本思路搞定，然后TDD前进，这个问题和任何软件工程的问题无关，是一个计算机科学或者技术的问题，TDD不能把你不会的东西变会了，也从来没有让你不用你已经知道的东西。

至于体系结构，等到你项目拿到的时候再去花几个礼拜去学习（研究），那是肯定不行的了。总体来说这是一个不断积累的过程，这个时候，你花上几个礼拜去设计的效果和花2、3天思考的结果是一样的，因为如果你只在纸上画来画去是无法深入下去的。事实上绝大多数项目几个小时就够了，这是有套路的，根本就没有多少创新的东西，至于组成部分之间的交互和变迁、发展，这就是迭代和TDD的事情了。(当然模式（套路）在这里非常重要，你更好地参考别人的模式，以及设计、开发团队对同一套模式语言的熟悉和掌握程度）

前面已经说得很明白了，TDD要取代的是前瞻性或深入的分析和设计。那个算法的例子就是想说明问题域分析的脏活必须有人在干。XP中这个脏活基本上由TDD包干了。而且TDD本身也不鼓励花上2-3天去搞定一个架构的技术问题。架构牵涉到的不仅仅牵涉到经验或者技术，更多的是对问题域的理解。一个10万用户的邮件系统的架构和几百万用户的系统架构是有本质区别的，但这类东西的定性只有对甲方的战略需求有足够的了解之后才能够得到。在一再的增添发薪人数之后，c3系统最终不能成功地为86000人发薪水，这个从直接原因上来看是架构问题或技术问题，但更深一层则是项目的初期并没有对企业这方面的战略需求有充分的沟通，作为企业项目的开发者，我认为最重要的一点是了解你的项目存活期在交付之后至少有5年，而不仅仅是应付眼前的需求。TDD或者XP的哲学是够用就好，并不鼓励对战略性需求的充分沟通（在80年代之后的企业级项目实施中，这是一个必修的环节），最终导致选择的架构也是够用就好，这不能不说是一个遗憾。根据需要选择和实施架构并不是太难的事情，问题只在于一旦选择之后，开发的时间越长，应用对架构的依赖性越大，最终替换架构的成本是不可接受的。
为用户推开一扇窗（很多高层并不了解当前在实施的应用项目和企业战略的关系，但是作为实施者应当去启发），不仅仅能够显示出你专业的需求获取和分析水平，更进一步的说，是出于保障项目健康发展的需要。这个才是最关键的。

to charon：
我觉得发生争论最大的原因还是我们都没有限定 XP 或者 TDD 所适用的范围。XP 和 TDD 是有其适用范围的（以后我们再来探讨）。今天很有趣地看到 Kent Beck 给《Questioning Extreme Programming》所做的序言：
http://www.mcbreen.ab.ca/QuestioningXP/
Kent 的态度也是鼓励争论的态度，而且他本人对 Pete McBreen 的评价还是相当高的。

前些天和 Trustno1 聊天时他说他们采用的开发过程就是野球拳，我们的开发过程同样也是野球拳（不知道这是不是就是所谓的自适应软件开发，又落入这些家伙的套路中了，想自创门派实在是太难了）。在 Kent 的书没有被奉为经典前 XP 相对于 CMM、RUP 同样也是野球拳。我看 XP 并没有千秋万代一统江湖的计划（可能也没有这个实力），所以我们还是把它当作待证的假设，何况敏捷方法也不仅仅只有 XP 一种。

我现在看来软件过程其实并不是非常重要的东西（所以你会看到我总是摇摆不定，摆出一副折中的姿态），开发人员之间的沟通，持续的培训才是最重要的。毕竟现在国内的大部分团队对于“如何做”还不是很清楚，现在需要解决好的还是工艺方面的问题。过程？晚点再说也无妨。

哎，跟你说这个叫Spike，TDD不能解决算法问题，任何分析技术也解决不了这个问题，这个问题只能靠你的数学知识。B和C不知道算法，分析10个月也解决不了这个问题的。

战略需求的了解也不可能一蹴而就的，了解了以后，也不是靠分析2-3个礼拜就能解决的，解决这些问题有两个方法，一个是你有构架这样系统的经验，如果没有经验就市进行适当的分析以后开始迭代和试用，因为系统没有运行你就永远不知道问题在那里？既然你没有经验，90%的可能性你花2-3个礼拜得出的设计还是满足不了客户需求的。
至于TDD不允许2-3天或几个小时的构架分析，那你显然是完全误会了，XP的原则是利用现有的信息去完成设计，而不是取到”所有“、“全部“的信息再去分析和设计。不知道你有没有注意到很多XP的鼓吹者都是软件设计和分析的顶尖人物？难道他们都是蒙头干的傻小子？


首先，你多次提到的C3不是因为这个原因是不为所有的员工发薪，主要原因是当初这个项目的目的、为项目决策人的变化，我建议你好好看看C2相关的页面
你说5年，那就是开玩笑了，举个例子，我们3年前帮一个现在中国铜产品老大做的ERP系统，5年前他还是一个不大不小的乡镇企业，你认为我们3年前就应该考虑他可以上市、考虑他的垄断地位？连他们自己都不明白5年后会变成什么样子。要应付这样的变化，我们能做的事情就是迭代，重构，甚至是系统整体的迁移。
还有我们为另外一个国家大型企业做的ERP系统，2年以后全员改制，人员大量精简，管理制度完全变化，你的意思是是我们当时就应该按现有的制度来做？

然，TDD的思路就是扁平这条成本曲线，因为你先前做的设计会因为没有经验、用户需求的变化、双方理解的变化、用户自身的变化而不可避免地不适应新的需求，这样你原先的设计和实现不可避免地要改动，而这样就是完完全全的成本浪费

---------------------------------------------------------
TDD不是万能的，但你对TDD的理解也是非常片面的

很多人认为XP是不做设计的，实际上XP的设计过程是非常讲究和可验证的。谈谈我的一些做法（只涉及到设计部分）

XP项目也做Upfront设计，但是这种设计不会细到把所有的需求都分析、设计完毕，
通常是在对用户系统进行数次调研，有一个比较粗略的调研报告以后到真正第一次计划会议之前做的。
这份报告，但更重要的是参与调研的人员通过和客户交流得到的信息了解了项目的环境、目标、大致范围、
性能要求和大致的功能模块，每一个模块的大致功能需求，、用户实现该系统的目的以后，对整个系统进行
体系分析、层次划分，这里会有很多参照以前实现过的系统结构，模式等等。这样的会议一般会引入较有经
验的咨询顾问、体系构架师、实现过这样系统的技术专家（可能就是其中的开发员）和开发员以及本次开发的所有团队成员参加。

1会议的目的有两个，一个是技术构架方面的，以分层结构举例，我们需要划分不同的层次、每个层次之间的交互方式，
几个核心的体系结构模式和设计模式，确定使用的语言、应用服务器、开发工具、版本控制工具等等。另一个目的是
业务方面的，从这一次会议开始，所有的团队成员都开始慢慢朝一个XP所谓的隐喻靠拢，这个隐喻将在以后的过程中
不断改进、修正，实际上就是整个系统的业务目标。

2在举行计划会议到划分任务这段时间之间，是XP进行设计最频繁的阶段，由于任务的划分同时也意味着程序模块和内部结构的划分
所以这个时候我们最初的体系层次划分将被细化到设计模式一级，我最常用的方法是一块白板、头脑风暴，通常来说这一阶段的
争论是最激烈的，很多设计人员都会提出自己的观点，自己认为比较可以重用或者比较优雅的设计方案。一般来说，我会首先要求
每一个人比较详细地说明他的观点，在白板上画一些图，然后让团队成员自由地向设计者提问，在这个阶段中一些模糊的想法会被
逐渐地越辩越明，而我所要做的事情往往就是提醒他们以前的某些成功或失败的经验、提醒他们目前客户所需要的灵活度以及客户
对我们的最终需求。如果有在场客户的情况，我们会马上询问。如果没有在场客户，那么我们会把分析、设计过程中无法确定的东西
和客户交流。如果是比较熟悉的部下，我会拿出CRC卡让大家参与来验证这个设计是否可行。虽然是在第一步体系划分的前提下进行的，但这个阶段的结果可能直接对整体的体系结构产生影响，因为我们增加了新的认识、我们更多地理解了客户需求、更明确了我们的系统隐喻。

3还有一种非常频繁的设计往往是在几个联系比较紧密或所做的任务比较相似的团队成员之间进行的。一般来说，任何人随时都可以
就他的类设计直接找我参与，我会和他就他自己负责的类结构、几个类之间的关系进行讨论。如果开发员认为是属于类之间的交互，
或者会影响到其它模块，或者属于比较普遍性的类设计问题，那么他可能叫上我，也可能直接和几个相关的人一起讨论这些问题。
同样，可能影响第2步，甚至是第一步（虽然这种情况比较少）。

4除了这些过程以外，基本上该开发员负责的任务的所有相关类、类的变迁、类层次的变化在符合我们体系结构大层次划分的前提下
完全是由TDD来驱动的。TDD驱动的潜移默化会慢慢地“细化“整个类层次、体系结构，也就是一个或多个程序员的重构行为会产生第3步
的情况，第3步会影响到第2部，第2步会影响到第一步，这个影响过程一般来说是缓慢的，随着系统的开发、运行慢慢地发生的。

XP的设计并不是不设计，而是对不确定的东西采用粗放型、设计到满足当前需求，可以开始下一步即可，而这个系统的结构是在TDD的驱动下，随着
用户需求和对早期版本使用经验的不断“输入“，得到不断的重构，每一部都有测试、用户反馈得到保证。

[quote="potian]哎，跟你说这个叫Spike，TDD不能解决算法问题，任何分析技术也解决不了这个问题，这个问题只能靠你的数学知识。B和C不知道算法，分析10个月也解决不了这个问题的。

这个我在前面给出这个粒子的时候有个假设：一个没有学过数列的人(B/C)在一天之内可以得出那个递推公式的直接解析式。
这个假设个人认为是相对正确的，有些分析/设计的获得不在于能不能做，而在于愿不愿意花代价去做。


前面说过了，这个不是技术问题，而是和拥有战略决策权或者了解企业战略的人的沟通。我这里就有一个鲜明的例子，去年我们实施的一个项目中客服部分的稳定运行的客户数容量上限是20万，当时企业录入系统的客户有5万，大家都以为根据当时客户服务中心的情况，到达20万需要很长一段时间。但是现在有26万(从5万到26万实际上只花了半年时间)。并且，非常重要的一点，这个企业内实际上是有若干高层知道这种规划的，问题在于他们并没有认识到(或者有义务认识到)客户规模会对系统架构有影响，而认为系统对规模增长有适应性是很自然的事情。
但是，作为开发者，应当了解这个问题。但是缺乏这样一个沟通的意识。用户毕竟只是用户，有些需求是可以挖掘的，有些也可以引导。这类需求本身并不是直接的可化为用例的，但是却对系统运行的延续性有决定性的作用。关键在于是不是愿意花时间去了解这类需求。


hehe,不鼓励不等于不允许。我在前面也没有提到"所有"，"全部"。
而且，正因为这些人是较为顶尖的人物(虽然我不认为他们是最顶尖的那一批)，他们有他们自己的洞察力和经验，所以有些事情不用深入分析或设计也可以达到目的，所以对于那些事情，他们可以XP。但是，大多数开发者缺乏他们这样的素养，也这么来，就有点@#$%^@!。
但是经验和技术也并不能决定一切。所以他们也会有失败。


C3的信息不仅仅在C2的页面可以看到。C2上的那个wiki实际上只是项目组和关心人员的一个内部讨论。立场决定了观点。网上还有别的对这个项目的看法。搜一下就有。


我觉得你对我说的战略需求有一个误解。并不是所有的战略都会影响到你的系统，比如说垄断地位。但是上市，我不认为3年前他们的高层没有这样的一个战略展望，只不过还没有成为一个事实。
至于国有大型企业是一个颠覆性不可抗力的典型(虽然未必不能预见，按照我国的做法，企业高层的心理准备期是非常长的，但即便可以预见，也无能为力)。就是说项目的甲方乙方都不可能为此做出适当的准备。
但是，不可抗力的存在，并不能成为放弃对可以预见情况的适应性准备。就好像不能因为毁灭性后果的存在，就连系安全带的兴趣都没有。


这个就是认识不同了。TDD难道不会造成浪费？我强调的是前瞻性的深入分析和设计。而且这里所谓的设计也只是不涉及细节的"总体设计"。或者说是对影响项目成败的关键风险点的尽早明确。因为有TDD的手段和哲学而推迟这样的决策点个人认为风险更大。
此外，就设计而言，关键不在于你选什么架构，而在于你选了某个架构以后，转身很难。这个对任何开发方法都一样公平, TDD也不能例外。而这个架构的选择，没有前瞻性或深入的分析就没有一个合理的基础。而且这样的一个分析，我想必然不是XP中的那种浅尝辄止的。[/i]

没有人说不做设计，我应该已经讲得很明白了。或许你在潜意识寻求一种包容所有答案的方法，这当然是没有的。

做了XP，不是说人就失去了所有的能力，你在正常情况下能做的事情，XP不能做了。实际上，你举的例子是否正确处理好，在于设计者的经验和水平。我已经说过了，XP的原则是利用现有的信息，现在能够收集到的信息，而XP的交流决定他比很多方式都要更加深入理解用户的当前需求，而不是相反。所以在这种情况下，同样一个具有经验的分析设计人员比，在XP下作比非XP下做，更有可能设计得更好。

你认为需求是可以深入的“研究“得到的，实际上根本不可能。前瞻性的深入分析和设计只能通过现在得到的信息，所有你“空想、研究”出来的分析和设计结果用户是不一定需要或者是错误的。而错误还是正确的最大程度不是取决于你花的时间和精力，而是取决于你掌握的现有信息和你的能力，取决于你的粗略程度，这里越粗反倒是越精确。

我举的例子是希望你明白5年对现在的企业意味着什么，我不太明白你到底要为用户做什么样的准备，做什么样的设计，才够得上5年，按照我的看法是，这些东西都是空的，没有意义的，也是根本不可能的。


XP充分交流让开发者更快、更深入和用户达成一致，理解用户的需求，能够更快、更好地作出设计、调整设计，XP该粗的时候粗，抽象本来就是粗放的；该细的时候，所有的文档（单元测试、代码、接受测试）都是可以测试的，非常严格。

不过，要理解XP就要实践，我讲半天没做过的人还是不同意，做过的人才会提出中肯的批评和建议。所以我想我不会再讨论下去了。

5年只是一个泛指，意思只在于眼光放长远一点，多为企业考虑一点。可能是我做甲方做惯了，最反感的是频繁(1-2年一次)的系统升级，把短视当作一种公司生存手段。按照我的经验，企业里面越是关键的部分，需求变化的频率越小。
    需求分析不仅仅是"研究"，更多的是通过交流(研究只在于算法型项目)，前面说得很清楚，我想你是误解了。我所认为的方式与XP的不同之处只在于只有在充分的沟通之后才开始总体设计，而XP在于边沟通边设计边编码。
    但是这么做，XP怎么处理一个架构转身问题。当你做到半程的时候，发现由于某个意料不到的需求导致对架构的重大调整，是不是把项目cancel掉，然后认为这个项目是XP成功的又一个体现：因为XP尽早发现了项目的不可行性！！XP所谓浮现的需求，最终也只是平凡的需求，真正浮现出来一个不平凡的，对你原先选择的架构有影响的，结果会比传统的开发策略更糟。
    至于较为充分的前期沟通是不是能够避免这个问题，我想完全避免不可能，但是传统上这是有一整套东西来保障的，绝对不是可能不可能的问题，不然，XP出来之前，以及现在那么多没有使用XP技术的项目是怎么完成的？难道都是那么不成功？不同之处在于，这个前期沟通只服务于确定项目中风险比较大的因素，确定项目的大致范围，以及选择架构。现代的企业项目开发方式也早已经过了细致严格的需求说明和详细的设计阶段，本身也强调在总体方向把握下与用户在开发过程中的沟通互动，这一点，连我们这个制造企业的老板都知道（今天上午又给我好好上了一课）。所以沟通并不是XP的优势。
    测试也不是XP的优势，难道不是XP就不强调测试？XP本身是全有或者全无的实践，即便如此，我觉得还是择其善者而行之。按照目前国内企业的情况，任何一个在企业内实施的项目，真正的XP是不可能的(即便我们现在在搞的那个项目实施费用就上千万的项目，我们仍然说服不了老板派发现场客户，当然，实施方可能把我当作现场客户，但我知道我并不是，我只是起到实施方和真正用户之间的沟通协调而已)。我不理解你所谓的XP实施是哪种，或者你只是开发产品型软件，而不是实施项目的？那样的话，就另外一回事情了。至于别的，比如结对编程，我最喜欢的这个概念，我觉得除了外企以外，好像少有软件公司这么做的。
   XP的优点在我的角度来看是它的简单化、短视化处理。可能成本也会低一点，对于那些急就章，有着严格时间压力的项目，很有卖点。(我们这类企业这种项目每年都会有1-2个)
   其实这种讨论本来就不存在什么结果，完全属于立场(企业立场还是开发商立场，当然，也存在一些站在我们这个立场的开发商)和认识问题。就此打住也是好的。

另外一点，不要曲解我的意思。我自始至终没有说过XP不做设计，只说过XP不做"深入的"设计.
去掉了这个形容词，意思大变。