回帖整理： 关于TDD引发的流行方法的思考
原帖：实施TDD时的常见问题， 下面的东西是与张逸兄在回帖中的讨论引发的一些牢骚。
说实话，以我一个中国人的习性， 不太看好ThoughtWorks这方面的工作； 当然， 最后可能主要是一些财主在经历一些失败的方法试验后逐渐采取轻量级的做法， 这样TW最后也够吃了。我想小型组织可能更多还是会继续采取更灵活的方式，但是灵活决不能等于混乱，这中间在过去是很难界定的；我想大家都混乱过， 好多事情也是一点一点明白的， 这方面也多亏了这些咨询公司的宣传^^
注意， 我上面说的， 似乎与敏捷的一贯印象中不同： 敏捷最开始似乎是适用于小型团队的。 但是一些事情看看Fowler这1年来的发言就很好理解了。 另外，一些所谓敏捷的小型团队， 在更古老的时间段里， 采取的是更重型的方法，那可不敏捷对他们来说就"敏捷"了。我习惯在观察事情的时候观察它的来龙去脉： 敏捷也许并非滋生于草根的一种方法， 而是对重型方法的反思(同时是一些第三方组织针对急于增加灵活性的霸王龙的敲门砖）, 所以恐怕它更多思考、针对和改善的， 不是混乱的中国开发组织要解决的问题。
对于国内的小型组织，和那些以前很混乱的中型组织(无论几级CMM，咱只论实际表现)， 更多的不应该是被敏捷和敏捷的口号吸引，同时由于感觉到对方法的需要， 在重型方法和轻量级方法中选择后者； 更多的， 可能还是观察这些方法中有助于规范化， 有助于结束混乱的本质要素， 逐步在组织中实行起来。
其实随着大家越来越有经验， 我想各种不同的方法都会逐渐的找到自己的位置， 哪怕过去的蛮干都会得到进化以新的面目出现而变为某些场景下的正确选择。在这个问题上， 关键是何时大家能够变得足够成熟， 同时成熟的技术人员的数量， 突破一个临界点。 关于TDD， 无论程序员懒还是实施得不理想， 很大一方面的原因是很可能该方法的宣传和使用，再次犯了“即使不能包治百病， 也至少比以往的狗皮膏药更加益寿延年”这样一概而论的毛病。
我的体会是，确实存在着大面积的情况和场景， 测试先行是毫无益处和道理的； 我也碰到过一些场景， 不先写好测试， 根本没法干。 问题是不是所有的场景都非常极端： 要么纯属没事找事， 要么非用不可。 但是我敢肯定， 绝对存在着没事找事所以才别扭的情况。 增加或砍掉一个步骤， 对流程进行调整， 并非只是一个工作量的问题， 而是这些变化往往本身就会引进新的不易察觉的混乱和弊端(比如一些烂摊子没有解决自身问题的情况下引进CMM而变得更烂也是如此)；有些时候解决问题的方法是除虫， 有些时候则也许是根本不合适。
人是相当敏感的动物， 当大家都感觉不对劲的时候，什么惰性啦习惯啦， 都会借机浮出水面； 可是从上面看去， 我们却认识不到这些事情很可能是因为各种程度的使用不当造成的。哪怕是程序员太懒， 但是犯懒的诱因， 恐怕往往还是因为感到不顺利了； 人自身的挫折感， 和一些隐性的不正常， 往往很难被发现， 却带来极其负面的影响； 而到底哪儿不对， 也是一个相当难回答的问题。TDD虽然我基本不能算了解， 我还是敢说， 掌握不掌握TDD本身没什么大不了；如果是一个适合TDD的场景， 现学现卖都会有好处； 对有实力的组织， 完全可以去请ThoughtWorks之类的第三方公司介入。
如何界定不同场景， 找出合适的方法选取的条件特征与判断依据， 才是真正复杂的地方； 有时也许一个项目的不同部分， 就可以被认为是不同的场景； 甚至有时候，这种场景的识别必须做到相当细粒度的级别。麻烦在于， 难道我们要聘请两个咨询公司吗? 或者跟某公司说， 你TM别忽悠我了， 多在我的项目上花点工作量， 赏金Double； 那么又只剩大中型公司能负担这些个成本了。 但即使对于大财主，更关键的是，一方面， 你想找合格的评估者而社会上很少； 另一方面， 也许只有咱们自己具有了相当的能力， 才能做出合理的评估，因为没人比自己位置更合适。 而后者是致命的： 等到我们自己有足够的经验， 我们已经付出了太多的代价。
所以在根本上， 我认为现在广泛存在的问题， 这些都很难去解决； 对于前几年搞那个方法， 这几年推这个方法的一些家伙来说， 我觉得实在很难去信任。我不认为比如Fowler不知道我所说的这些东西， 但是在宣传上， 他们一定不能把这种多样性和复杂度展现出来（就好比MS从来没告诉n年前的我ASP.NET有这么多东西Under the hood）； 当别人能雇得起他们的时候， 由于他们比较有经验， 通过比较好的掌舵， 可能一些宣传中的承诺得以实现； 问题是对于那些雇不起的呢?
也许真正的症结在于缺人和缺乏用人的机制： 国家(甚至美国)和一些机构的报告里不也提到， IT业缺乏高级人才吗? 很多人对这样的话可能看看就过去了； 或者有人觉得， 我这么牛的人还没被人请走， 要真缺人哥们早年薪三五十万以上， 政府放什么屁哪? 还嫌IT的人不够多， 骗小孩子来抢哥们饭碗不成? 但关键是， 咱是不是牛人， 到底由谁来认定? 一个是也许太多的人自我感觉良好， 或者至少是牛人还不够多； 一个就又要说到我上次提到的建立行业内共享的人才选拔的机制和市场了。
解决了达到一定高度的技术人员数量不够，且不能合理的在社会上分配等问题， 也许我们会发现当前讨论的靠不同方法来改善软件构建的效率与质量， 纯属牛头不对马嘴； 只是因为没有抓住问题成因，让一些投机者钻了空子， 四处兜售脑白金罢了。 可能我这么说， 又会损害到一些组织的利益了；另外， 也许我太悲观。 但是简单的说出这个项目TDD， 那个项目DDD， 恐怕不像想象中那么容易吧。
只是人家雄心壮志的给大象治鼻炎，给老虎治牙痛， 什么小白兔啦长颈鹿啦是不是也要跟着掺和一下子呢?
说实话，以我一个中国人的习性， 不太看好ThoughtWorks这方面的工作； 当然， 最后可能主要是一些财主在经历一些失败的方法试验后逐渐采取轻量级的做法， 这样TW最后也够吃了。我想小型组织可能更多还是会继续采取更灵活的方式，但是灵活决不能等于混乱，这中间在过去是很难界定的；我想大家都混乱过， 好多事情也是一点一点明白的， 这方面也多亏了这些咨询公司的宣传^^
注意， 我上面说的， 似乎与敏捷的一贯印象中不同： 敏捷最开始似乎是适用于小型团队的。 但是一些事情看看Fowler这1年来的发言就很好理解了。 另外，一些所谓敏捷的小型团队， 在更古老的时间段里， 采取的是更重型的方法，那可不敏捷对他们来说就"敏捷"了。我习惯在观察事情的时候观察它的来龙去脉： 敏捷也许并非滋生于草根的一种方法， 而是对重型方法的反思(同时是一些第三方组织针对急于增加灵活性的霸王龙的敲门砖）, 所以恐怕它更多思考、针对和改善的， 不是混乱的中国开发组织要解决的问题。
对于国内的小型组织，和那些以前很混乱的中型组织(无论几级CMM，咱只论实际表现)， 更多的不应该是被敏捷和敏捷的口号吸引，同时由于感觉到对方法的需要， 在重型方法和轻量级方法中选择后者； 更多的， 可能还是观察这些方法中有助于规范化， 有助于结束混乱的本质要素， 逐步在组织中实行起来。
其实随着大家越来越有经验， 我想各种不同的方法都会逐渐的找到自己的位置， 哪怕过去的蛮干都会得到进化以新的面目出现而变为某些场景下的正确选择。在这个问题上， 关键是何时大家能够变得足够成熟， 同时成熟的技术人员的数量， 突破一个临界点。 关于TDD， 无论程序员懒还是实施得不理想， 很大一方面的原因是很可能该方法的宣传和使用，再次犯了“即使不能包治百病， 也至少比以往的狗皮膏药更加益寿延年”这样一概而论的毛病。
我的体会是，确实存在着大面积的情况和场景， 测试先行是毫无益处和道理的； 我也碰到过一些场景， 不先写好测试， 根本没法干。 问题是不是所有的场景都非常极端： 要么纯属没事找事， 要么非用不可。 但是我敢肯定， 绝对存在着没事找事所以才别扭的情况。 增加或砍掉一个步骤， 对流程进行调整， 并非只是一个工作量的问题， 而是这些变化往往本身就会引进新的不易察觉的混乱和弊端(比如一些烂摊子没有解决自身问题的情况下引进CMM而变得更烂也是如此)；有些时候解决问题的方法是除虫， 有些时候则也许是根本不合适。
人是相当敏感的动物， 当大家都感觉不对劲的时候，什么惰性啦习惯啦， 都会借机浮出水面； 可是从上面看去， 我们却认识不到这些事情很可能是因为各种程度的使用不当造成的。哪怕是程序员太懒， 但是犯懒的诱因， 恐怕往往还是因为感到不顺利了； 人自身的挫折感， 和一些隐性的不正常， 往往很难被发现， 却带来极其负面的影响； 而到底哪儿不对， 也是一个相当难回答的问题。TDD虽然我基本不能算了解， 我还是敢说， 掌握不掌握TDD本身没什么大不了；如果是一个适合TDD的场景， 现学现卖都会有好处； 对有实力的组织， 完全可以去请ThoughtWorks之类的第三方公司介入。
如何界定不同场景， 找出合适的方法选取的条件特征与判断依据， 才是真正复杂的地方； 有时也许一个项目的不同部分， 就可以被认为是不同的场景； 甚至有时候，这种场景的识别必须做到相当细粒度的级别。麻烦在于， 难道我们要聘请两个咨询公司吗? 或者跟某公司说， 你TM别忽悠我了， 多在我的项目上花点工作量， 赏金Double； 那么又只剩大中型公司能负担这些个成本了。 但即使对于大财主，更关键的是，一方面， 你想找合格的评估者而社会上很少； 另一方面， 也许只有咱们自己具有了相当的能力， 才能做出合理的评估，因为没人比自己位置更合适。 而后者是致命的： 等到我们自己有足够的经验， 我们已经付出了太多的代价。
所以在根本上， 我认为现在广泛存在的问题， 这些都很难去解决； 对于前几年搞那个方法， 这几年推这个方法的一些家伙来说， 我觉得实在很难去信任。我不认为比如Fowler不知道我所说的这些东西， 但是在宣传上， 他们一定不能把这种多样性和复杂度展现出来（就好比MS从来没告诉n年前的我ASP.NET有这么多东西Under the hood）； 当别人能雇得起他们的时候， 由于他们比较有经验， 通过比较好的掌舵， 可能一些宣传中的承诺得以实现； 问题是对于那些雇不起的呢?
也许真正的症结在于缺人和缺乏用人的机制： 国家(甚至美国)和一些机构的报告里不也提到， IT业缺乏高级人才吗? 很多人对这样的话可能看看就过去了； 或者有人觉得， 我这么牛的人还没被人请走， 要真缺人哥们早年薪三五十万以上， 政府放什么屁哪? 还嫌IT的人不够多， 骗小孩子来抢哥们饭碗不成? 但关键是， 咱是不是牛人， 到底由谁来认定? 一个是也许太多的人自我感觉良好， 或者至少是牛人还不够多； 一个就又要说到我上次提到的建立行业内共享的人才选拔的机制和市场了。
解决了达到一定高度的技术人员数量不够，且不能合理的在社会上分配等问题， 也许我们会发现当前讨论的靠不同方法来改善软件构建的效率与质量， 纯属牛头不对马嘴； 只是因为没有抓住问题成因，让一些投机者钻了空子， 四处兜售脑白金罢了。 可能我这么说， 又会损害到一些组织的利益了；另外， 也许我太悲观。 但是简单的说出这个项目TDD， 那个项目DDD， 恐怕不像想象中那么容易吧。
只是人家雄心壮志的给大象治鼻炎，给老虎治牙痛， 什么小白兔啦长颈鹿啦是不是也要跟着掺和一下子呢?
