【IT168 分析评论】    我觉得推行一个新技术最大的阻力还是来自程序员自身。管理层一般不会关心开发方法和技术细节的问题。Struts的流行恐怕主要也是技术人员发自内心的认可和推崇造成的吧。毕竟这牵涉到他的切身利益——工作效率、成就感、乐趣......

    同样的道理，单元测试和其他敏捷方法也要首先打动技术人员的心，然后想不流行都难。目前的情况与这两种技术本身的特点也有关，单元测试是阳春白雪，Struts是下里巴人。

    初次接触，本能的抗拒

    我自己的经历就是这样。03年中期时，我们技术总监让我研究一下JUnit和Eclipse。那时候我用Struts和JBuilder用的正爽，瞟了一眼觉得Eclipse太简陋了，其实是自己被JB这种傻瓜相机惯坏了。

    JUnit就更无法接受，那时觉得程序员写业务代码天经地义，写测试就是自虐。

    于是就丢在一边不再看了。可是如今，这两样东西已经是我工作中最重要的工具。

    大多数人都走过的弯路

    现在每次看到缺少测试的代码，以及还在不停制造这种代码的程序员，我就会感叹前几年自己走的弯路。

    04年我经历了一个项目，20人在客户现场开发。到了后期的时候，整个项目就像一座沙子堆起的巨大城堡，稍有不慎就会跨塌。

    于是，程序员们开始变得消极、焦虑、易怒、神经质......（似乎还没有人到更年期 ）

    消极：不愿意修改Bug，不愿意改代码以满足用户新提出的需求。

    焦虑：担心刚刚修改的代码会破坏已有功能，对下一个版本能否正常工作毫无信心，梦到测试人员报告其大量Bug。

    易怒：经常对测试mm发火，私下里诅咒客户，抱怨别人弄坏了自己的程序。

    神经质：系统偶尔出现奇怪行为就胡乱猜测，改了不该改的地方导致更多奇怪现象出现。

    那段日子简直不堪回首，是对程序员身心的双重折磨！

    走上敏捷之路，相见恨晚

    时间到了2005年的春天，单元测试（连带着轻量级架构Spring和敏捷方法）真正走进了我的世界。

    从那以后，我发现我变得快乐，并且再也离不开它。编程不再是一件痛苦的事，至少不那么痛苦了，反而增添了很多乐趣和满足感，秘密就在于：

    勇气：单元测试是自动化的回归测试，她让我对自己的代码充满自信，每一个测试就像攀岩者钉在峭壁上的一个楔子，没有了程序衰退的担心，于是我可以大胆的重构、积极的拥抱变化。

    快速反馈：每写一段代码，我都可以在几秒钟之内看到他的运行效果，免去了打包、部署、重起Server以及在一堆日志里找结果的工作，开发的效率较高提升。

    测试驱动设计：通过编写测试可以准确的理解需求、发现问题、发现接口，在不知不觉间做出最合理的设计。

    文档：测试是最好的详细设计文档，不会过时、可运行。

    对于新事物的怀疑总是不可避免的，很多人最主要的是担心写测试会降低开发效率——写测试代码时间+写功能代码时间>写功能代码时间。

    对于这个问题，Martin有过回答，大致的意思是：如果软件开发的主要工作是敲键盘的话，那个命题是成立的。事实大家都知道，这个敲键盘的时间只占很小比例，但毕竟也是多用了。那么在哪儿又节省了呢？答案就是快速反馈。

    快速反馈：每写一段代码，我都可以在几秒钟之内看到他的运行效果，免去了打包、重新部署以及在一堆日志里找结果的工作。

    写测试3+写代码3+跑测试看结果1=7

    写代码3+打包2+重新部署10+用IE访问程序2+在一堆日志里找结果并确认5=22

    我一点也没夸张，那个WAS 5重新部署一次真的很慢，有时还需要重起服务。

    不断实践，终获回报

    来到e-ma以后，我继续在工作中实践着敏捷方法，包括在技术论证阶段极力推荐Spring框架；在编码开始之前做了项目原型和开发模板；配置luntbuild持续集成服务器；提倡编写单元测试......

    经过国检项目的考验，我更加坚信：敏捷方法是快速开发高质量软件的一把钥匙，因为它所承诺的那些好处全都得到了兑现，我所开发的支付、冲正、清单模块全都按时完成，并且Bug很少；虽然需求、接口一改再改，但是有密集的单元测试作保证，我总能毫无顾忌的快速的去调整程序。像国检项目这样的系统结构复杂、通信方式多种多样、需求变化频繁、质量要求高、工期紧张的分布式系统，对于任何开发方法都是个严峻的挑战。但是我惊讶的发现，相比那种简单的本地数据库应用，敏捷方法在这样的系统里能够更充分的发挥出威力 ，看看它是如何应对这些挑战的：

    系统结构复杂：TDD正好可以产生一个简单、松耦合、可测试的设计，极大的降低系统复杂度，防止过度设计。

    分布式系统、通信方式多种多样：这对程序员是个巨大挑战，但是Mock单元测试让事情变得简单许多，Mock可以轻松模拟任何外部资源和接口。

    需求变化频繁：敏捷的口号就是“拥抱变化”，有单元测试作保障，让变化来的更多些吧。

    质量要求高：有单元测试作保障，每一段代码都有一个测试用例守护，同一个Bug不会出现两次或以上。

    工期紧张：还记得“快速反馈”吧。

    敏捷方法很简单

    它不是软件天才专用的难以理解和掌握的神秘方法，它只是一些普遍原理和经验的总结、一种理念和一组非常好的实践。

    "I'm not a great programmer; I'm just a good programmer with great habits. "

    ——Kent Beck