首先请各位看看本文标题中的敏捷实践。为什么说是实践而不是说什么方法论，什么模式呢？我的看法就是实践能够确确实实落到实处。很多人说软件开发是一门艺术。但是艺术这个东西虚无缥缈，那要开发出好的软件还要培养出我们的艺术细胞，实在是不好操作。所以我们就需要一些能够落到实处的实践。这些实践很好操作，没有什么模棱两可的东西，也没有什么故作高深的东西，更没有什么只可意会不可言传的内容。

　　面向对象是个很抽象的东西，所以很多书都以各种小猫小狗的例子来教导我们如何去以面向对象的方式思考，这些例子在阅读的时候都朗朗上口，但是一到我们实际的项目中又全部玩完。所以我们需要一些看似有点死的实践：我们规定类和方法的行数，规定不要出现重复代码，规定一行不要出现多个“.”操作符等。这些都可以称之为实践，因为它非常好操作，一眼就可以看出来问题。

　　那有人可能要说了，软件开发是一门艺术啊，你这样搞和建筑队有啥差别。嗯，是的，这样弄起来可能有点土。但是我突然想起来，以前老师教我们画画的时候，不也是介绍了一些类似的实践么，比如画人像的时候不是有个三停五眼么（如下图）。画画是艺术吧，但是还是会采用一些看似死板的方法。那么，我们软件开发为什么就不能使用呢。

　　我想说的就是，敏捷实践就像这个三停五眼，他很好落实。测试驱动开发就是这些实践中极其重要的一个：

　　1、程序员都是技术人员，常常沉迷于技术细节而不能自拔，忘记了自己所要开发的软件的业务价值，有的时候甚至自己想出很多自以为对用户有用的功能来，但实际上交付给客户后，客户发现添加的这些东西根本一文不值。而测试驱动开发则用一种有点极端的方法来规定：测试通过了，你不要再写代码了，除非你添加一个失败的测试，否则我拒绝添加新的代码。以此来防止我们过分的追求技术，而忘记了业务价值。

　　记得很早之前，我的经理经常跟我说，你太过于关注技术细节，而忘记了一些很重要的东西。我那个时候不以为然，后来每次想起来就觉得惭愧。比如我经常为了构造非常好的类阶层次结构，将代码改来改去，有的时候为了实现这个目标甚至自行消减了部分软件功能。

　　2、设计是非常困难的一件事情。我们一直在强调，要高内聚，低耦合。那么我们又怎样构造出高内聚低耦合呢？靠喊口号当然不行。而如果你一开始就使用测试驱动出产品代码的话那么创建高内聚低耦合的代码就更容易得多。

　　比如上周，我在给一个遗留代码添加新的功能。具体需求大概是这个样子：根据当前用户以及所访问的内容，然后其他管理员设置的策略来显示签名。因为要将代码打包部署之后才能看到效果，而且这个遗留代码非常庞大，重新部署之后tomcat基本上要五分钟左右才能反应过来（每每这个时候我就很怀念IIS）。所以手工的测试显然是非常不合理的，每次打包部署都要浪费这么长时间。而且我们还修改了遗留代码，必然要进行回归测试。没办法，我们要加个集成测试，这样就免去了打包部署的步骤了。我们大概花了一上午的时间将这部分集成测试编写完成可以跑了，但最后总是出现异常。最后发现异常发生在一个叫UserRightBRO的类上，它有个currentUser方法，聪明的你可能已经想到了，这个currentUser当然是web上下文中的一个东西，我们这个集成测试里怎么可能获得这个东西呢。解决这个问题最好的办法当然是编写一个派生自UserRightBRO的类，然后将currentUser方法用我们的实现覆盖掉，然后在测试时使用这个子类替换掉原来的类。最后我们绝望了，UserRightBRO这个类是在调用它的类里实例化的，而不是通过接口传入的，这两个类紧紧耦合在一起。

　　可能你要说，编写这个地方的人就是个傻蛋，搞出这么紧耦合的东西。但是，你用什么办法保证我们自己就不会编写出这么高耦合的类么？敢打包票么？当然不敢。但我想如果这部分代码是用测试驱动出来的（这块是遗留代码，啥测试都没有），我觉得应该会防止这个问题的出现。因为你编写测试时，就会准备一些基础构造，当准备的时候你就在想我们应该如何使用这个类，需要一些什么东西，像这个对环境依赖这么强的实现基本上不可能出现。

　　3、你说我们该不该写测试？如果我们开发的产品不发布或者就使用一次，或者发布给内部用户用用（他们一般能忍受你），那你大可以不写测试。什么？你说你们有庞大的手工测试团队？好吧，我认了。如果没有庞大的手工测试团队，那我们最好还是多写一些能够自动化的测试，但是但是但是，我连说了三个但是。多少开发人员在代码编写好后又回来补测试？这样做的请举手。从我了解的情况，我觉得不多吧，那如何让测试落实到实处？我想，在编写产品代码之前先写测试也许是一个不错的方法。

　　关于TDD可以将一些难以操作的东西落实到实处的观点还可以列出很多，不过要声明的一点，我这里想说的是我不是在为TDD唱赞歌。因为一些敏捷实践将很抽象的问题具体化了，将一些不好拿捏的问题具体化了，将一些看似高深的技巧简单化了，所以也难免会遇到一些问题，所以在实践中还是会有很多阻碍的。

　　比如Todd Wei在他的文章里所描述的，当需求改变时我们的测试会红一大片，甚至会抛弃很多测试。其实我想回答的是：

　　1、即使我们不测试驱动开发，我们也应该编写测试是不是？那么这个时候如果需求变了我们改不改测试？不过Todd最后说，我们要快速的构建出可工作的软件，然后让用户看看，然后等需求稳定了我们再编写测试。好吧，如果这一条真的有效我想你是不需要这些敏捷实践了，因为你已经将敏捷运用到极致：频繁的沟通和反馈。频繁的沟通和反馈可以有效的抑制其他风险。