原力的黑暗面2

原力是非常强大的，但它也有它的黑暗面，我们再回忆一下另一个场景：

 

Yoda大师：“小心黑暗势力。愤怒，恐惧，侵略是原力的黑暗势力。它们流动容易，很快引起打斗。一旦踏上黑暗之途，它便永远支配你的命运。”

Luke：“黑暗势力更强吗？”

Yoda大师：“不是。但它们较快，较易，更为诱惑。”

 

是的，为什么明明迭代模型好，但开发规程里就要求要采用业界已经证明失败的瀑布式模型？制定规程的人不是傻瓜，他们只是被黑暗面诱惑了。

迭代式开发对项目组人的要求比较高，如果人的素质不行，根本迭代不起来。这是因为迭代必然涉及重构，如果设计能力不足，不能发现变化，封装变化，不能保持软件的软性，迭代是非常痛苦的，会在无穷无尽的修改中度过一个失败的项目。

那么问题就是：瀑布式对人的要求低吗？其实，瀑布式对人的要求更高，因为前面工序的任何偏差都会在后面工序得到放大，最终很难保证产品是最初想要的。这就对执行前面工序的人提出非常高的要求，就是几乎不能出错。我们有这能力吗？反正我还没遇到这样的人，能不写一行代码，作出精确的设计。

黑暗面的诱惑就在这里出现了：即使人的素质再差，瀑布式也能执行起来！也许每篇文档还都很漂亮，至于误差，大就大呗，我们就把有误差的东西做出来，虽然故障多，虽然不是客户要的东西，可毕竟是个产品啊。于是：规程规定，必须采用瀑布式模型。理由：迭代式对人要求高，要考虑目前公司开发人员的普遍水平。

谈生命周期课题可能太大了，谈谈小的地方，比如unit test。现在TDD是一种行之有效的开发方法，这已经在业界多处取得成功了，但TDD对人的要求很高，如果不知道如何设计，有怎么“测试驱动设计”？于是诱惑来了：还是别test first了，就先写代码，再测试吧。

其实先写代码再测试对人的要求更高，这要求写代码的时候必须一次写出可测试的代码，否则写测试代码将痛苦地无以复加。什么叫代码的可测试性？本来就是说写测试代码的容易程度。如果代码不可测试，怎么写测试代码呢？这个时候黑暗面又开始诱惑我们：即使再差的人，有了再不可测试的代码，也能为他的代码写出几个测试用例来。然后我们有了结论：暂时不推行TDD，理由：TDD对人的要求高，要考虑目前公司开发人员的普遍水平。