关于敏捷和TDD的一些感悟

通过昨天对老师的提问，也算是对一直以来的困惑和思考做了个总结。

敏捷开发是一种内涵非常丰富的思想，面向用户，面向需求，而不是面向模块。而TDD则是一种卓有成效地提高工作效率的办法，与敏捷相辅相成。

接下来，结合本人最近项目上的一些经验和教训，来做一个深入的总结和反思吧~

关于敏捷，面向需求和面向模块究竟有什么区别呢？

以目前的经验为例，作为一个用户量巨大的后台，按照模块来分，有测试模块，面向数据库的模块，面向缓存的模块和面向前端的模块。如果按照模块来分工合作的话，会出现的问题是，接口的负责人很难提供其他模块所需要的特定功能，很难知道自己的接口在其他模块究竟是怎样运行的，发挥着什么样的作用。倘若尝试解决这些问题，沟通的成本是昂贵的，需要给出的API文档的工作量和需要的时间成本同样很高，但是需要更新甚至返工的概率是很大的。那么按照需求来分工的话，则是功能的开发者对所需要的模块接口进行全局的设计和实现，在已有的可扩展性较高的接口基础之上，为需求进行专属的扩展。事实上有经验的对业务进展十分清楚的程序员会能够在最初设计接口是就考虑接口的通用性，为后来的接口扩展提供便利，但多数情况下还是按照功能，定制地去拓展接口。

这种情况下对程序员的挑战是大于以往的，一方面，前期的结构对于后期功能的拓展可能会是一种阻碍，很可能需要全部重来。如果接口的可拓展性极差，或者架构对后期的功能的添加会产生大量负面影响而需要重新设计，推翻重来是不可避免的。所以这是十分需要经验的，现代软件开发流程的科学化使得很多公司有专门的架构师，这类人所承担的责任通常是巨大的，就我现在的感受而言，架构师应该不仅仅是面向开发团队的，同时也是面向用户的。在我们这次实践中，SM便是这样的一种角色，而PO更像是用户和SM之间的桥梁。如果SM缺乏面向用户的意识，整个团队的代价是无法真正实现敏捷的，开发过程中遇到的阻碍也可能会变多。另一方面，是对编程技能的要求更高，需要更加全面的编程知识。譬如，一个后台程序员，除了要对前端有所了解，对于算法，数据库，数据库底层，操作系统性能等方面都比较熟悉，否则同样是无法敏捷的。也就是说，对于一个整体的功能，任何拿到部分功能的程序员，都应当具备实现全局功能的编程能力，同时也意味着不同的人是需要操作相同的模块的。

关于测试，什么样的测试才是系统测试呢？

还是结合自身经历来思考。对于一个面向前端的登录接口，我们获得前端的输入，返回其想要的结果，我们不需要关心用户信息是否写入了数据库或缓存，不需要关心返回值是如何计算的，这个过程中可能出现的错误等。我们的测试是不依赖于实现的。那么单元测试呢？我的理解是，单元测试时关注实现的，譬如我的需求，a+b+c，实现者利用了函数sum(a,b,c,)，过程需要函数add（x,y），系统只关心初值和终值，单元却还会关心过程中的两次add，他需要知道实现，才能确认实现，进而测试实现来保证最终结果。

那么，TDD是什么，又如何应用呢？

TDD，所谓测试驱动开发，那么一定是测试现行。TDD的过程中，我们需要的是专注于一个需求的开发，直到测试通过。这里我说针对一个需求，我想强调的，这里的测试，应当是不依赖于实现的系统测试，而不是单元测试。否则，TDD将难以展开。

大多数情况下，开发者会先开发再测试，很可能出现的一种情况是，过程中一系列的单元测试都是通过的，但最终的功能依旧无法保证，这时再开展系统测试，可以说是比较耗费时间的，毕竟，原本你的目标可以变成：通过眼前这一项测试。

先这么多吧~期待后面会有更多不一样的感受。