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

我觉得关键问题是前面已经提到了的“TDD只能得到局部最优解”。你从200的一个小山头下来，再上另外一个300米的山头，代价巨大。

基本上，像这种渐变的设计模式，出发点非常关键，如果TDD的实际应用者是一个经验丰富的高手，那他会非常得心应手。而对于一个新手，甚至是一个“一直在另一个领域工作的高手来说”，都十分危险。

局部最优解-- 以你的理解方式，迭代开发也是一个问题，瀑布是最好的。

问题的关键是你根本不知道是不是有一个300米的山头，或者要走向的是另外一个300米的山头


我想表达的意思是
1。 XP对客户的需求理解要超过其他方式，因为他非常注重面对面交流，这是人类至今所能认识到的最好的交流方式

2。我们只应该针对现在的客户需求去做设计、分析，譬如如果客户真的确定5年以后是怎么样的，那么这个已经是现在的需求了。传统的方式是就算不知道5年以后是怎么样的，我们也试图通过自己的分析、研究、讨论去设计出一个5年以后可能的构架。在XP中，如何双方的理解不够清楚，或者客户不能提供足够的细节，那么我们不是试图去揣测其中的细节，而是把这些东西延后。

3。在掌握相同现有客户需求的情况下，你的框架和设计是否够好取决于两个方面，一个是你开始的能力，第二个是你采用何种方法逐步修正你的设计，而不是取决于你在一开始花多少时间和精力一下子去完成某些事情，这里的诀窍是把能够搞清楚的搞清楚，不能搞清楚的到能够搞清楚的时候再去决定。


4 XP地设计过程有两个重要的特点：
- 对于不能确定的东西就以比较粗略的方式（比所有的方法都粗）对待，不需要类图、交互图、部署图等等东西。最极端的情况就是隐语。
这个比较粗略的东西是一个概念，是大家的共同认识，并且在不断的交流、反馈和迭代过程中不断地得到修正和完善。这个东东写在只上没什么意义，因为关键是理解和把握的程度。

- 对于能够确定的东西就必须要精确、能够验证，比任何其他方法都要详细。例如User Story必须由acceptance test,详细设计必须有UnitTest验证。类设计图必须有角色扮演的验证，等等等等。而不是写在纸头上或计算机里面的不可验证、难以交流的东东。

所以XP地设计文档看来是很少的，但实际上我们可以看到文档在这两种情况下都不可能起到比XP更好的作用

---------------------------------------------------------------------------
我一直在从事XP的实践、宣传和推广工作，还很少碰到过程序员的抵触，我有一个政府部门客户甚至把我们的开发方法作为他们技术创新的一部分。XP完全是可行的，并且在很多地方很好地运作着。这不是一本XPRefactored可以改变的，所以把这本书打成高分的无疑是根本没有实践过XP，这两个作者可以说对XP一无所知，对XP的基本概念和实践都不清楚，他们如何能够正确评判XP.

最好的批评应该来自XP社团内部，我想这也是我以后需要努力的地方。但是就像Martin说过的，当我们一开始有了OO，我们实在无法找到他的缺点，我们只有更深入、细致、广泛，在更多不同的场合运用XP，才能更好地批评他。

看了各位的帖子，真是受益很多啊；
我想我不干妄说什么；只是想象看到这些帖子
的朋友说一句：看看这些书吧！

我曾在自己的Blog上翻译了一些XP的资料（很简单的那种），突然感觉原来自己根本不懂XP。

就像我看了TDD后发现自己之前从来不知道TDD是个什么东西。

XP的确需要实践；

我对结对编程有过两次深刻的体会；

第一次是查找JDBC与Oracle的连接池问题；资源经常被耗光了；找不到原因的出处；
原因随都知道，没有释放资源；

后来一个老手指点我技术难点，使用Exception打出链接关闭和打开是的堆栈，然后对比那些打开的没有关闭；

其实，这个方法我不知道有没有问题，但我觉得可行；

此时，他作在我旁边，我写代码，一起调试，分析；

最后找出了大部分没有关闭的链接；

从某种角度将，我是认可他的方法并尊敬他，很虚心的写代码。

所以我人为，XP中某些实践需要一定的前提条件；如果
是两个水平一样的人，可能就是另外的样子了；可能自行其事，也可能是结对编程的最佳模式；我指导你写；我写你指导；

另外一次，不是编程，是移植Exchange，其实我俩都不熟悉，但是我得功底身些；我做技术活，他打杂；然后是他作技术，我打杂；有效的保证了一个头脑的高速运转；

to potian:
  后来我又仔细看了一下你的关于XP计划的那个帖子(我在回帖之前并没有仔细看这个，只看了前面的那个,hehe)，发现你对于XP计划的做法类似于martin folwer，而不是kent那一路。属于XP中不那么极端的一派。
  另外，我觉得你必须承认一点，XP方法中，前期需求调研的力度和深度是不如传统方法的，所以下一步工作开始时，掌握的客户需求的深浅也不一样。在没有动手之前，并不存在某种更好的需求调研方法。所以这里只根据花的时间精力来区分客户需求的掌握程度。
  从kent的思路来看，我觉得他会去掉所有不必要的东西，是没有先期的架构设计这个概念的，只有到进展到那一步，发现确实需要那么一个架构时，才引入。我认为这样可能会有一个从没有架构到轻型架构，然后再到某类重型架构的一个过程。问题只在于架构变化的代价。


这句话很对，但是有一个问题，如果你不去主动沟通，客户是不会主动交待出来的。比如我们厂打算在五年内产量翻番，并且各品牌结构的调整可能更大，有些品牌可能不止翻番。这个东西在某个层面的人群中是个事实，但是大家都不认为这个东西对信息系统的构造有什么影响。

根据我对TDD的理解，它只是解决问题的一种手段，一种思路（也可以叫工具），它可以指导你一步一步接近你的目标。但是，首先你必须对你需要解决的问题本身有一定的了解，目标一定要明确，否则任何方法也搞不定。每次的测试其实就是阶段目标，它可以保证你每一步不会脱离你的目标。至于是否走的正确，那是需要凭你的经验，对问题的理解等其它因素了。

但是一步一步走，可以简化问题、降低失败的风险，并且还可以省去以后单元测试的烦恼。假如你现在没有解决问题的思路，TDD可以让你从最简单的地方开始，而且还可以保证每一步都是百分百满足你的预先想法（设计），然后再逐渐深入，这就是TDD提供给我们解决问题的思路。因此TDD从这一点入手是非常有道理的。

就像爬山，有经验的人他会挑一条好走的路（很可能他以前走过），没有经验的人就只能一步一步走，首先他得挑目前最为好走的路，走了10米，发现稍微往左一点则更好，再往上10米，发现原先走得有问题，你只需要往下退10米，再往上走。根据经验的多少，可以自己挑选跨度：10米、100米等。

那用什么来判定你走的路是否正确？以爬山来说，一般是你自己可以亲眼看到（爬在你前面的人，悬崖，前方无路等）。如果是TDD，它就会以测试来保证，如果测试有误，则需要你解决（回退、修改等），你不用担心这一步是否走的不对，因为它符合你的阶段目标。

XP 有没有隐喻？有。关于 XP Kent 举了一个开车的比喻。关于 TDD Kent 又举了一个井中打水的比喻。不知道有没有人仔细思考过这两个比喻？据我看来相对软件开发来说要比狗窝与大厦的那个比喻贴切的多。也许 charon 天生就是造大厦的料，但是 XP 确实只是为资质中等的普通人而准备的。所以我认为 XP 和 TDD 对于一个初学者逐渐成长是非常有帮助的，而那种先期设计仅存在于少数几个精英的头脑中则是非常难以效仿的。还有一个问题是没有及时的反馈，谁相信你的设计就能爬上 300 米的山头，也许爬了 50 米就已经证明你是错的了。

我提所谓的动态规划以及贪心主要想表明，并非每次都取得局部最优解就是目光短浅。

我觉得关于TDD有一点大家都忽略了。或者说轮换的结对编程对TDD的成败起到了一个关键的作用。
kent提到的TDD的每个工作循环中的第五步也是最重要的一步，是通过重构优化设计，消除重复代码。如果不轮换，那么优化的只是你自己这组代码的设计，没有人有时间去浏览整个项目范围内的代码。结对编程通过双向轮换，能够加快浅层代码和频变代码的项目组内沟通速度，能够使这些代码的设计有优化的可能。轮换的PP在这里起到了一个代码评审和知识扩散的作用。但是这个扩散实际上也是有一个时间差的，在确定轮换方式的前提下可以计算出来。但总的来说，如果不否认生存时间越长，代码被其他代码依赖的情况越有可能(当然不一定是线性的)，那么，如果项目组到达一定规模，这种代码知识扩散的时间可能就是不可接受的了。
如果不采用PP，单人轮换因为组数的成倍和轮换方向的单一性，扩散时间会大幅上升，从而进一步限制项目规模. 或者，除非有一个上帝似的人物在那儿确保整个项目范围内的代码重构。
其实学过数学建模的哥们可以给这个东西建一个简单的模型。

我倒不觉得PP对TDD能起到关键作用，最多也就能促进TDD。我的意思就是TDD并不需要和PP结合的那么紧密。其实，我一直认为TDD是一项单独的技术，离开XP也能做得很好。而像XP中的其它一些实践，如：PP，就与XP结合的很紧密。

TDD能让test的反馈与你的构思之间的距离越来越小，它能保证你的代码不会偏离你的终点。当然PP能让人思路更开阔，两人之间的讨论肯定能促进对问题的更深思考，让TDD进行的更加迅速、准确而已。

第5步对TDD确实很重要，不然你就不能达到“整洁能工作的代码”这个TDD目标。除了PP对这一步有很大的促进作用，当然还有很多其它的方法，如：多人讨论、网上搜索和研究资料等。