再问TDD： 扩散角模型
原贴：回帖整理：
关于TDD引发的流行方法的思考
其实我相信ThoughtWorks能做好TDD， 只是我不相信大多数中小公司和目前存在着这样那样混乱情况的组织可以做好TDD。
像Ruby之类的情况， 编译期检查根本没有，测试就变得非常重要，节约时间，提高效率那是可以肯定的。在这方面，由于各种测试在实质上替代了一部分编译器和连接器的工作， 自然用处要大得多。
但是对于静态语言来说，拿Test来提高软件质量的作用又有多少呢？ McConnell等一大片人不都提到测试能覆盖和发现的BUG极其有限。我觉得这并非是框架或者数据库的原因。在WebForm上，照样可以使用MVP/MVC，数据库则是哪儿都再用的。前者又涉及到成本上是否值得选取更复杂的架构。 说到底我觉得是一个权衡的问题。
就像我文章中说的，我个人也碰到过非测试先行不可的场景(往往我是处在一个库作者的角色之中)。问题是在一个项目里，如果去设定选取测试点的问题，选择测试范围的问题。最极端的TDD恐怕也不会面面俱到。这才是我所认为的复杂度。
这方面， 我有一个直觉上的方法， 就叫做“扩散角”吧。 想两条直线， 同时从一点出发， 它们中间有一个夹角。 这个夹角越大， 两条直线的另一端的两个端点，相距距离就越远。 我们假设靠近出发点这一端取一个三角形， 是被依赖的模块(或模块组)； 而外面的梯形， 是依赖这个三角形所表示的模块的模块集合。
如果这个夹角非常大，测试想要追求全面， 其成本就非常高。 我们可以考虑， 如果这个夹角接近180度， 全面应用TDD的成本就接近于无限大。可以对应到现实中的是， 我们在一个执行TDD的项目中， 很可能会发现测试仍然是不全面的， 因为全面的测试超过了成本；当然，我们可以找出各种各样的理由，说明哪些地方，为什么，没有做测试。
如果这个夹角非常小，比如接近0度，这时候考虑两种情况：这个被依赖部分存在大量在其它方向上的夹角(可以考虑有非常多的这样的扩散角)中的重用； 这个被依赖部分没有因为重用被包括在其它夹角之内，而仅仅存在在当前夹角之中。 后者的情况， 我们可以把它们看作一个部分， 在最外围进行一个测试； 前者的情况， 也许我们只对这个被依赖部分进行一个测试， 才是性价比最优的： 对于其它模块，是不是测试，仅依赖于其自身的复杂度可能造成问题的概率。
我特别认同思归说的这些，这东西应该就是工具箱里的一个工具， 不要把它当作特别玄的或者别的什么。而且有机会使用TDD的场景， 不妨一试， 而不是抗拒它。
但是经过多少练习和实践才能确定自己拥有这个能力， 不是空谈， 我想是可以商榷的。比如我相信， 有的人严格的实践了若干次， 不如带着问题实践几次。所以我说， 能否正确的采取TDD也好其它也好， 关键是人的水平的问题。我指的高水平， 更多的是知道怎么提出问题， 如何实践， 积极思考这些方面。
比如这个扩散角模型，也不是仅仅存在着这些简单的情况； 同时，这个模型也绝不是用来评估或者产生影响的唯一一个需要用到的模型。Kent他们有把事情都交代的非常清楚吗？ 即使他们交代了， 对于一个技术人员来说， 有那么多东西要学，时间和精力又有限， 能在每一个涉及领域里把这些东西一下子全记住并掌握吗？
恐怕我们需要的恰恰是很多善于思考的人， 虽然可能我们也缺已经在某一方面有大量实践的人；后面这种人，应该专人专用才是；这才是我发出疑问的地方。另外一个让我不满的就是，TDD宣传者们经常用“每一个”/“所有”这样的词汇；但是我觉得，光考虑上面这个“扩散角”接近180度这个极端的情况的存在性，如果再考虑那些依赖者中的大多数所存在的行为都是严格的可以预期的， 性价比的问题就会凸显出来了。这就是为什么我经常向这些宣传者开炮的原因。
换句话说，有多少人达到了真正能够“纸上谈兵”的水平呢？ 我们考虑两个没啥经验的小伙子： 赵括和孙武。 能“纸上谈兵”的人中间，有多少是前者呢？ 很显然我们需要大量的后者。 幸亏我们需要的智力和眼界， 比《兵法十三篇》需要的智力要少的多，所以我个人觉得，我所指望的行业整体水平的提高， 还是可以做到的。
有了足够多的高水平的人， 而且社会上雇佣别人的组织能够分辨它们， 在正确的时候采取正确的手段， 就是顺理成章的事情了。这是一个行业视角上的问题， 而不是一个具体技术的问题。
其实我相信ThoughtWorks能做好TDD， 只是我不相信大多数中小公司和目前存在着这样那样混乱情况的组织可以做好TDD。
像Ruby之类的情况， 编译期检查根本没有，测试就变得非常重要，节约时间，提高效率那是可以肯定的。在这方面，由于各种测试在实质上替代了一部分编译器和连接器的工作， 自然用处要大得多。
但是对于静态语言来说，拿Test来提高软件质量的作用又有多少呢？ McConnell等一大片人不都提到测试能覆盖和发现的BUG极其有限。我觉得这并非是框架或者数据库的原因。在WebForm上，照样可以使用MVP/MVC，数据库则是哪儿都再用的。前者又涉及到成本上是否值得选取更复杂的架构。 说到底我觉得是一个权衡的问题。
就像我文章中说的，我个人也碰到过非测试先行不可的场景(往往我是处在一个库作者的角色之中)。问题是在一个项目里，如果去设定选取测试点的问题，选择测试范围的问题。最极端的TDD恐怕也不会面面俱到。这才是我所认为的复杂度。
这方面， 我有一个直觉上的方法， 就叫做“扩散角”吧。 想两条直线， 同时从一点出发， 它们中间有一个夹角。 这个夹角越大， 两条直线的另一端的两个端点，相距距离就越远。 我们假设靠近出发点这一端取一个三角形， 是被依赖的模块(或模块组)； 而外面的梯形， 是依赖这个三角形所表示的模块的模块集合。
如果这个夹角非常大，测试想要追求全面， 其成本就非常高。 我们可以考虑， 如果这个夹角接近180度， 全面应用TDD的成本就接近于无限大。可以对应到现实中的是， 我们在一个执行TDD的项目中， 很可能会发现测试仍然是不全面的， 因为全面的测试超过了成本；当然，我们可以找出各种各样的理由，说明哪些地方，为什么，没有做测试。
如果这个夹角非常小，比如接近0度，这时候考虑两种情况：这个被依赖部分存在大量在其它方向上的夹角(可以考虑有非常多的这样的扩散角)中的重用； 这个被依赖部分没有因为重用被包括在其它夹角之内，而仅仅存在在当前夹角之中。 后者的情况， 我们可以把它们看作一个部分， 在最外围进行一个测试； 前者的情况， 也许我们只对这个被依赖部分进行一个测试， 才是性价比最优的： 对于其它模块，是不是测试，仅依赖于其自身的复杂度可能造成问题的概率。
我特别认同思归说的这些，这东西应该就是工具箱里的一个工具， 不要把它当作特别玄的或者别的什么。而且有机会使用TDD的场景， 不妨一试， 而不是抗拒它。
但是经过多少练习和实践才能确定自己拥有这个能力， 不是空谈， 我想是可以商榷的。比如我相信， 有的人严格的实践了若干次， 不如带着问题实践几次。所以我说， 能否正确的采取TDD也好其它也好， 关键是人的水平的问题。我指的高水平， 更多的是知道怎么提出问题， 如何实践， 积极思考这些方面。
比如这个扩散角模型，也不是仅仅存在着这些简单的情况； 同时，这个模型也绝不是用来评估或者产生影响的唯一一个需要用到的模型。Kent他们有把事情都交代的非常清楚吗？ 即使他们交代了， 对于一个技术人员来说， 有那么多东西要学，时间和精力又有限， 能在每一个涉及领域里把这些东西一下子全记住并掌握吗？
恐怕我们需要的恰恰是很多善于思考的人， 虽然可能我们也缺已经在某一方面有大量实践的人；后面这种人，应该专人专用才是；这才是我发出疑问的地方。另外一个让我不满的就是，TDD宣传者们经常用“每一个”/“所有”这样的词汇；但是我觉得，光考虑上面这个“扩散角”接近180度这个极端的情况的存在性，如果再考虑那些依赖者中的大多数所存在的行为都是严格的可以预期的， 性价比的问题就会凸显出来了。这就是为什么我经常向这些宣传者开炮的原因。
换句话说，有多少人达到了真正能够“纸上谈兵”的水平呢？ 我们考虑两个没啥经验的小伙子： 赵括和孙武。 能“纸上谈兵”的人中间，有多少是前者呢？ 很显然我们需要大量的后者。 幸亏我们需要的智力和眼界， 比《兵法十三篇》需要的智力要少的多，所以我个人觉得，我所指望的行业整体水平的提高， 还是可以做到的。
有了足够多的高水平的人， 而且社会上雇佣别人的组织能够分辨它们， 在正确的时候采取正确的手段， 就是顺理成章的事情了。这是一个行业视角上的问题， 而不是一个具体技术的问题。
