为什么敏捷没有成功： 关于敏捷的一点思考 (2)
续上一篇 为什么敏捷没有成功： 关于敏捷的一点思考 (1)
3. 测试驱动开发
我个人对TDD(测试驱动开发)的评价是： 这是最难的一个敏捷实践
它看起来起来很美，吃起来扎嘴
相信很多人都是从一些非常非常简单的例子来学习TDD的，例如加减乘除运算，货币转换等，确实很好的展示了TDD的特点。
但一旦想在自己的项目中运用，我们发现根本就不是那回事！
我们的实际项目很复杂，就拿最常见的Web应用来说，涉及到UI显示，数据校验，逻辑处理，数据存取，异构系统交互等等，远远不是一个简单的计算器能比拟的。
想用TDD开发这样的项目，对程序员的要求特别的高：
首先要改变思维，需要从测试角度看待整个软件系统，系统有什么功能，需要提供什么接口，不能经不起诱惑，一上来就想着怎么去实现
其次你需要具备“分而治之”的能力，能够把大的功能点纵向的切分成一个个小功能点，这样才能开始写测试用例，才能用测试驱动代码的生成。
最后就是技术方面的要求，会选用合适的工具，会写测试用例，会重构，会Mock各种系统
即使你满足上面所有的条件，还要面对一座难以逾越的大山： 遗留代码。
很少有项目是从零开始构建的，新的需求也不可能完全用全新的代码来实现，TDD的过程中势必要修改遗留代码。
每次提到遗留代码我就头大，因为这不管它们有多么的烂， 你都必须咬牙接受，一边骂着一边维护，因为他们还在运行中，还在产生价值，若是打着敏捷的旗号，实施TDD的时候把它们弄坏，相信客户和领导会蹦起来的 （参见我的另一篇文章 ： 代码腐化之路）
我还没有看到一个大型的企业级项目是真正用TDD开发的，大多数团队只是尝试了一下就知难而退了。
?
4. 结对编程
我个人超级喜欢这个敏捷实践，在工作中也常常要求手下去结对编程，结对几个小时下来，效率很高，大家也都会喊累，集中精力干几个小时的确是挺不容易的，要不极限编程怎么提倡“激情燃烧8小时”呢
结对编程效率高，产出的代码质量也高，大大减少后续修复Bug的开销，并且通过人员轮转也能促进知识的传播，可是项目经理不喜欢它，为什么？
因为结对编程的好处在短时间内体现不出来，从项目经理的角度看，两个人坐在一起，你效率再高，也只干了一个人的活，这怎么行？
迫于进度和交付的压力，只好把两人拆开来使用
写到这里，不仅要感慨一下：中国的程序员是苦逼的，因为我们经常需要面对巨大的软件交付的压力，在这种压力下，很多敏捷实践在执行中会变形，变味，最后导致放弃， 唉。。。
?
未完待续......
