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

中国的开发人员缺乏自信心，没有个性是非常严重的。严重程度最明显的表现就是完全不敢质疑大师的观点，甚至不敢质疑这里一些所谓的“高手”的观点。

我推荐了一些大师，有人怀疑我是个死读书的本本主义者（又是一个王明！中国这样的人何其多啊）。其实这些大师只是因为观点和我非常接近所以我尊重他们，我从来不认为我必须在形式上完全照搬他们的做法。我的目的也绝不是鼓励大家去盲从，从昨天崇拜 CMM、崇拜 Rational 三友到今天崇拜 Kent Beck、Martin Fowler（拜倒在一个又一个的偶像脚下，无所作为的犬儒主义）。比如同样读 XP，你读完了明天马上全盘照搬；而我却要再思考很长时间，想清楚 XP 的精神实质究竟是什么，然后只实践我认为真正适合我们的那些做法。

我现在正在读《测试驱动开发》，也是疑问多多。你 Kent Beck 是个老江湖了，在这个行业做了几十年，而我的经验不到十年。适合于你的方法不一定适合于我。如果你说这个秘方可以包治百病，适用于所有场合，那么对不起，我不会再崇敬你。你没有这样说，同时承认 XP 和 TDD 也有其适用和不适用的场合（当然，由于敝帚自珍而略微夸大，这是可以理解的），那么你仍然是一位我可以信赖的良师。

庄表伟同志提出了很多自己的见解，我虽然不能完全同意，但是我很尊重他这种独立思考的精神。

这里引出的一个问题是，究竟什么样的刀适合你要看你现在的能力和经验而定。你现在的能力达不到，小李飞刀的刀你拿来玩只会伤了自己，不如你先拿李逍遥的木剑操练操练。怎么都是我们李家的人啊，呵呵。

xp是一个从实践经验中总结出来的方法，能完全丝毫不差的应用所有的xp方法只有创建者本人，所以说根据自身的实际情况适当的应用xp才是稳妥地，因为我们和xp的创始人所处条件不同。比如结对编程我觉得在我们的项目里就没有必要，因为我们的团队里人员水平差距比较大，结对编程往往变成了结对授课（当然结对老手带新手并不是不可，前提是差距不能带大，如果大部分时间是在解释术语也是新行不通的），而迭代增量的开发就是大大有必要，与其形似而神不似的实施xp还不如沿用自己团队已经熟悉的开发方法

总之一句话：领会精神

敏捷方法我只研究过 XP。XP 我只读过 3 本书：
《解析极限编程》，Kent Beck 著。XP 的总览和主要的原则。
《规划极限编程》，Kent Beck & Martin Fowler 著。如何具体实施 XP 的指南。
《测试驱动开发》，Kent Beck 著。如何具体实施 TDD，如何真正做好单元测试的指南。
这 3 本书里，《测试驱动开发》使我获得了最佳的阅读体验，如果说前两本书让我对 XP 半信半疑的话，那么第 3 本书让我领会了 XP 的精神实质。只要不全盘照搬，XP 还是非常好的东西。以前我认为 XP 实施最大的障碍其实是 TDD 很难有效地开展，往往流于形式，因为大多数开发人员（包括我在内）对于如何作好测试（测什么？不测什么？如何保证测试的质量？）缺乏必要的知识。显然 Kent 也看到了这一点，于是专门写这样一本书来手把手指导我们如何做好 TDD。现在我对 TDD 已经非常熟悉了，因此这方面已经不是很大的障碍了。
《测试驱动开发》这本书对于我来说其实是比任何软件测试工程都更加重要和实用的一本书。过些天（只能在周末了，我只有周末才有时间）我会在测试版写文章来阐述我对 TDD 的一些理解。

potian 前些天说 Kent Beck 的书象春秋，我是读了《测试驱动开发》才有了这种感觉，真的是微言大义。我说 Kent Beck 的思想象是高岗上的空气，多呼吸则使人振奋。但是不是每个人都有能力呼吸的，那些头脑中有些贵恙的人读起来就要多费些工夫了。我可能以后一有空就会找来读一读的，简直就是一个随身携带的制氧机啊，呵呵。

同意楼上两位说的,  先进的技术, 方法很多, 但显然不可能都适合于自已的团队, 项目.  我个人觉得, 等自已团队积累了一定的开发管理经验,  再结合自已困惑的地方,  逐渐转变, 形成适合自已团队的开发模式(有点重构的意思).  也就行了.  能顶会多少好东西, 就用多少.  要不就东施效颦了.

看了TDD,又恰好遇到项目的一个问题，求解两个线段的交集这个问题（甚至n个集合的交集）？开始想到通过判断两个线段起点终点的的位置关系去求解；但后来(隔了两天了)，在纸上画了线段相交的各种情况，发现只需要对线段的起始点进行排序，再做计算，简洁很多。于是我想假如象TDD一小步步的进行测试,能够引导我想到这个方法吗?

说得很好，但下面这点我持不同观点。我认为“真正适合我们的那些做法”靠思考是想不出来的，只能是不断的实践中才能总结真正适合我们的那些做法出来。

其实有时并不是缺少怀疑的精神，而是缺少怀疑的能力，因为水平有限，对于自己不太明白的地方是不敢胡说的。

不过现在能做的，就是不要去盲目的相信它，自己不明白的姑妄存之，等自己的明白与理解了之后再去接受它，可能算是现在的“防传染的”方法吧。

对于上面所说的结对编程，我也有一点感触，可能一开始两个人结对时，因为水平相差太大，效果不好，可是坚持一下，效果还不错，如果时间比较紧的，让新手一方默默观察，你累了时，让他写一些简单的功能也不错，如果时间比较松时，你可以做一些关键性解释，而且有一些问题当你需要将它象别人说明白的时候，自己的整理的思路就很有意义，而且对问题的理解会更深刻。

形成一个团队需要大家都要付出一份额外的代价的，在你不太忙的时候要帮助别人的，不过这样一个团队真的形成，效能就大增了。因为你自己再努力，只能增加自己的效率，如果形成了团队，就是增加每个人的效率的问题了。

每天我们都在说团队精神，那么还是从自己做起吧，个人意见。

不过好象跑题了

大师打个喷嚏，我们给他吃药,呵呵,既然被称之为大师,则有大师之笔,所谓三人行,必有我师,有其哲理可言.所谓高手轻易不言语也,一言则高手也,所以慎言.也就是说大师轻易不打喷嚏,你想人家茅庐待了几十年,说的话都是研究成果呀,无私的给我们分享了,我们还觉得不好,大师说的话也许在我们看来觉得有错误,也许等你到了那个境界去看就会发现原来是当时的自己错了!一家之言也,虽然我从不读书!我喜欢自己杜撰,承认

我的看法和你的一致。TDD相当于寻优中的爬山法，每次一小步，最终到了局部最优点就下不去了，因为怎么改都不如原先的方案好。好像也没有特别的方法可以处理这类情况。TDD最大的好处就是比较快的收敛到局部最优点。最大的问题是没有办法跳出这个地方。XP的那个经典项目C3我认为就是死在这里。
对于算法密集型应用，这个问题更加明显。不把算法想明白就在那儿动手。如果想法上有了重大的进展，很可能除了那些测试用例以外，写的那些程序都已经没有意义了。

我觉得用算法密集型项目来反对TDD不太恰当！

OO不是用来解决算法，而是做问题领域分析的。算法密集项目使用过程分析更加适合。

TDD帮助建立基准测试环境，有了这些测试代码，使得重构代码有了基础。