对敏捷开发等时髦概念泼点冷水

首先声明一下，我对敏捷开发了解的并不深刻，但我仍然持有很多怀疑。这个行业从不缺乏创意和神话，以前面向对象、UML等概念刚面世时，也都吹嘘得包治百病。Java提出Writeonce,runanywhere的口号又曾经打动过多少程序员的心！可如今呢？SUN被卖了，Java基本退出PC桌面应用，只在企业和Web应用领域有优势。远的不说，Web2.0前两年也吹得很响吧，其实作用有限，现在成熟的应用又有多少呢？

不扯远了。敏捷开发，不管是Scrum还是XP，可以完全替代RUP吗？

先说需求分析，靠Backlog或者Userstory能够代替严谨的需求规格说明书行吗？

1.如果说需求难以明确定义，常常是开发方对用户方的业务领域了解不够造成的；

2.至于说用户对自身需求认识不清，我觉得也是借口。好的开发商应该能够引导用户认清自己的需求，甚至提升自己的需求。比方说给一个小城市的环保局做项目，如果把沿海大城市环保局做过的成功项目介绍给用户，他自己会权衡选择自己的需求。

3.需求经常变更，没必要全部需求都定义清楚后再设计开发。问题是，需求之间很可能有依赖关系，或者需求中没有界定清楚的东西后来发现按既有设计会根本性地无法实现。如果到那个时候再推倒重来一遍设计和开发过程，到底是敏捷还是代价沉重？传统方式就不能反映需求变更吗？CMM中定义的需求跟踪矩阵严谨地关联了从需求、设计、开发到测试的所有变更记录，不敏捷就活不了了？

再说设计阶段，照敏捷的观念，直接就去编写测试代码了。OK，如果你做的项目是驾轻就熟没有任何挑战性的事情，这样做也行。可是还有很多复杂的项目，或者新产品的研发，概要设计阶段是很重要的，设计不成熟，先天缺陷后期弥补要么代价大，要么根本无法弥补，敏捷个屁！都能那么敏捷，咨询公司不用开了，谁还要他们设计。像我五年前做的一个产品，国内现在都没有同类产品，如果不设计就开发，甚至不设计就写测试代码，简直是胡闹！难道程序员只是泥瓦匠一样的体力活？

详细设计和编程阶段，我倒觉得确实需要敏捷一下。文档写了给谁看？东西做好了就行。不过，照scrum的观点，天天开例会，烦不烦呀？哪那么多成果和疑问呀？只有领导喜欢，天天看着燃尽图有变化，很有成就感。

测试，发布，维护阶段，用缺陷跟踪系统就挺好，跟敏捷也没什么关系。

骂了半天敏捷，再说说单元测试。

单元测试本来只是最基本的测试，只不过因为是由开发人员完成，现在就拔高得不得了，好像功能测试、回归测试都不重要了。尤其是XP，变态地坚持必须先写测试代码，然后再写实现代码。我每天早上起床喝杯水难道还要检测一下有没有毒吗？在我看来，重要功能模块的代码、复杂业务逻辑的代码、功能测试需要很多种测试用例的代码，才需要编写测试代码。其他的代码有没有bug，在其他的测试环节更容易检验。测试覆盖率高bug就一定少吗？盲目追求没必要。

就想到这么多，忘了提的以后再补充。

睡了一觉，接着写。

重构：真是个好东西，早就该提出来了。重构可以使面向对象设计的代码粒度更细，一方面降低了单个对象或方法的复杂度，从而减少了bug存在的可能性，另一方面粒度细了更容易实现代码复用；第3个好处是使代码更便于测试；第4个好处是减少了参数传递依赖和对象依赖，这样改一个地方不容易影响其他代码模块。第5个好处是更易于调整对象和方法的位置，使项目的整体层次逻辑更清晰。总之，即是个好的理论又可以在实践中获益匪浅。

设计模式：感觉就像是孙子兵法，我不是都看得懂，看懂的有些在实际编程中也不会灵活运用。成吉思汗没看过孙子兵法仍然是伟大的军事家，但也不能说孙子兵法这本书是垃圾。

面向领域设计/面向方面设计：概念而已，启发一下思路不错，构不成完整的设计开发体系。

O/Rmapping、RubyonRails：小项目玩玩可以，大项目严重影响性能。别跟我说Twitter也是在RoR环境开发的，人家后来为了提高性能重写了RoR的底层，感觉就像开改装车一样。既然买了个奇瑞QQ，就别到高速路上去找死。这可不是我本人的偏激看法，我举两个例子：

1.PayPal的注册用户大概1亿，PayPal开放给第三方的API显示，他们设计的数据库是不用索引的，原因很简单，如果这么多记录的一个表建了索引，插入和删除操作会导致性能无法想象的低下。

2.Google2005年左右，动用了很多人力，将公司核心技术——爬虫程序完全重写了一遍，以前是C语言写的，改成用汇编语言重写一遍。为什么？答案只有性能！

云计算和框计算：就像把冰淇淋和大便相提并论一样。云计算不只是个传说，只可惜10年以后才会见到大规模普及。另外别忘了，云计算是亚马逊提出来的，为什么是亚马逊？这个问题的答案很耐人寻味。框计算是个噱头，是李彦宏和李一男这两个极品厚黑学传人的硕果。

罗嗦了半天，最后总结一下我的观点，技术是针对应用的，它不是基础研究，用户认可并广泛接受的应用就是最好的技术。从这个角度看，用户才是决定技术优劣的最终裁判。

反面例子：2002年我的一个同事（也是个项目经理）曾经对我说“我心目中最好的界面就是纯文本的命令行方式，一条条指令输进去，执行结果很快就出来”，当时我无话可说，我知道很多做开发的都有类似的心态。

——————————————————

对诸位网友意见的回复：

首先呢，各位的意见我都认真看了（包括“一蓑烟雨任平生”删掉的那篇），没有听不进去的问题，只不过我比较懒，没有一一回复。

第二，我并没有全盘否定敏捷开发的意思，只不过对周围很多神话般吹嘘敏捷的人比较反感，在这里发泄发泄。

第三，我谈论以上话题的时候，是本着“什么样的技术和方式能够更好地满足用户的需求”这个视角考虑问题的，不是就技术谈技术，也不是从项目管理的方法论角度谈论问题，也没有考虑个人职业规划，或者考虑老板、同事、上下级之类的协作关系等问题。所以角度不同，看法自然不同。

第四，各位不要乱猜，本人三十有七，属于老枪/老鸟，不是新兵蛋子。大公司、小公司都干过，外企没进过。出国也呆过，后来又海龟过。创业失败又打工过，打工几年又创业过。程序员干过，项目经理干过，高工干过，现在是社会闲杂。自己注册了家美国公司，不过产品还没开始赚钱（20万行代码已经累得我一身病），所以现在不算什么老板，偶尔做点项目挣个十万八万补贴家用。总之，向我这把年纪还自己写代码的人，算是频临灭绝的稀有动物了，你们一定要爱惜，呵呵！