上周参加了一次TDD的开发培训，敏捷教练演示如何通过测试驱动出求质数的公式，借此向我们展示了TDD的巨大魅力。
"红灯-绿灯-重构"的开发节奏为我们开启了另外一条软件开发的思路，从底往上推导出整体业务逻辑。而我们传统的开发思维里总是要先进行顶层的业务设计，然后分解有多少业务接口，从上往下进行。两种模式当然互有利弊，TDD看上去更加的直观，更能让人感觉与正确性相关，让程序没有BUG、有完善的测试保护、再也不用当心重构会影响原有的业务逻辑。
有感于次此，回来的时候我们组织了一个代码编程比赛，借此向开发介绍单元测试的重要性，以及简单重构的好处。简单的套用了一个教练提供的网球比赛列子，为了增加一些难度，增加了几个复杂的case，对代码行数做了限制。在花了15分钟给开发门简单的介绍了一下比赛的规则后比赛开始。特意把比赛开始的时候定在的周5的下班后，希望大家周末有时间可以去找找资料，有更多的时间去反复重构代码，且不占用工作时间。
结果很意外，30分钟后，便有一位开发完成了任务， 还是一位没有参加TDD的人（原来没有练习过）。采用了类似穷举法的方式，将20个结果弄成一个数组，然后通过一个TDD的方式推导出了一个很牛逼的函数，将结果返回回来。于推广的意义来说 我觉得违背了我本来的意图，但对于比赛规则说，确实有效的。那么问题来了，在敏捷的模式里是否代码功能达到要求就认为是一个好的设计？
联想到我们敏捷的开过过程中，我们经常纠结的一个问题：简单够用的标准在哪里。在传统的开发模式中，我们总是被要求或则要求别人需要为代码后续维护做准备，尤其是在一些存在研发和实施由两拨人来做的公司。作为产品研发团队的人，总是在想未来变化的点在哪里，我该如何的设计才能满足需求。而在敏捷的开发环境中，总是强调MVP,强调尽快的交付。为了能够在一个sprint中完成,往往采用的是最简单实现的方案。日积月累这些方案就会成为心中的隐患，而事实上我们做的很多高价值的功能都可能运行在简单粗暴的方法上。
为什么敏捷和TDD能够共生，既然你选择了敏捷你就不应该背上那么多的沉重的包袱。当你的思绪总是羁绊在未来不可知中变化中，你就无法对你的当下做出选择。
