敏捷中国史

内容亮点

• 敏捷发展亲历者与推动者、资深程序员熊节作品
• 2000 — 2019 中国软件工程 20 年发展关键脉络
• 敏捷方法如何从草根流派到备受青睐，再到存有争议
• 无数资深老程序员上下求索突破技术瓶颈的编程岁月
• 首次集中呈现 IT 巨头阿里、腾讯、华为的敏捷之路

专家推荐

在我看来，软件研发人员大概可以分为四类：知道自己正在变得敏捷的践行者、知道自己并不敏捷的鼓吹者、不知道自己其实已经很敏捷的草根探索者，以及埋头搬砖茫然不知世事的开发者。

我大概是属于第三类：“圈外敏捷”吧。看到书中那些圈子里的风起云涌，间或还能看到自己的名字出现其中，颇有些山外看山的莫名趣味:)。推荐大家都来阅读《敏捷中国史》，相信大多数人，都能够在其中找到自己的那一段故事。

——庄表伟，华为内源架构师

我理解《敏捷中国史》不仅仅是对历史的记录和纪念，更是以史为鉴。文中一个个致力于改善工作成效的一线从业者，致力于推广新方法新工具的布道者，正是他们吸引了一批又一批热衷软件开发的人加入进来，一起推动行业的发展。

——张松，ThoughtWorks 中国区总经理

课程背景

敏捷是一种重视质量、追求快速反馈的软件开发方法。它对行业的影响远不止几个编程实践，说它影响了 Java 技术栈的变迁，说它引领了 DevOps 和持续交付的潮流，甚至，说它在中国 IT 发展史上是浓墨重彩的一笔，都不为过。

然而，敏捷在技术人士中具有很大的争议，有人将敏捷奉为圭臬，有人对敏捷嗤之以鼻。

大家对敏捷的态度为何有天壤之别？如今很多人所认识的敏捷跟 Martin Fowler、Kent Beck 等先驱主张的敏捷有何不同？70 后与 80 后老程序员当年是如何突破自身技术成长困境，将敏捷引入中国的？敏捷是如何从一个名不见经传的小流派，到如今，从自由职业者，到创业小团队，再到大型公司，无不接纳并大力应用它的？IT 领域最有影响力的巨头阿里、腾讯、华为的技术成长是如何深度融入敏捷方法的？

作为中国敏捷十余年发展历程的亲历者与推动者，资深老程序员熊节从整个中国 IT 发展进程审视敏捷，通过本课程带你一起重新经历一代程序员的青葱热血岁月，与你一起梳理中国软件工程领域 20 年发展的关键脉络。

不止于敏捷，你会切实感受到整个中国 IT 行业、乃至中国经济的发展。

作者介绍

作者：熊节，现任宝尊电商成都研发中心总经理，曾任 ThoughtWorks 总监咨询师、 CSDN 技术主编。

IT 行业打拼 18 年，在金融、零售、政府、电信、制造业、全球医疗等行业的信息化建设方面有着丰富经验。翻译了《重构》《软件工艺》《实现模式》等行业重要著作，是中国 IT 浪潮中敏捷发展的领航者之一。熊节拥有利物浦大学 MBA 学位。

插图：虎头锤，旅居墨尔本的老程序员，北邮博士、北大硕士，15 年编程经验。目前从事支付系统相关业务，曾转战区块链、通信行业。敏捷倡导者、手绘爱好者。

课程大纲

适宜人群

• 致力于高效开发的程序员
• 对 IT 发展感兴趣的人士
• 互联网从业人员

课程内容

开篇词　平凡荣耀：你我这样的普通 IT 人塑造了今天的行业

起初好像是酒桌上的话。上海的一帮朋友聚会的时候，我跟庄表伟说，我要写一部敏捷中国史，而且要以你老庄的故事开头。

我和庄表伟认识 15 年了。2003 年的时候，我在杭州一家民企，做政府项目，他在上海一家民企，做的好像也是政府项目。我们在 JavaEye 网站上相识，大部分时候惺惺相惜、互相吹捧、同仇敌忾，彼此之间也掐了不少的架。

后来庄表伟去做了印客网，去了盛大创新院，又在返利网工作一段时间，再往后就加入了华为，负责华为的内部开源平台架构，还在开源社担任执行长。

他自认不是敏捷社区的代表，但过去 15 年来，在技术架构、开发方法、团队组织、知识传播等主题上，他的观念与敏捷社区每每不谋而合，这也是我跟他能做这么多年朋友的重要原因之一。

庄表伟就像中国 IT 行业的一个剪影。

这个行业里有千千万万像他一样的普通人（包括我自己）。我们二十出头懵懵懂懂一头扎进这个行业，十几年摸爬滚打，多多少少做了一些事。或许我们从来不曾成为杂志的封面、敲钟的主角，但谁又能说，这个行业的宏伟大厦，不是靠了我们一砖一瓦的搭建？

尤其对于敏捷这种原本草根、被行业主流轻视甚至打压的软件开发方法，从一开始就未能入庙堂之上大人物们的法眼，竟能在夹缝中生根发芽，生长成了行业中主流的方法。这其中的来龙去脉，满满的尽是如你我一般平凡小人物的机缘巧合和努力与坚持。

作为国内最早的敏捷引入者之一，过去 15 年里我经常引用“敏捷宣言”的第一行：人与交互重于流程和工具。然而反观今天在行业中盛行的敏捷，似乎更多的组织在强调 Scrum 的流程和看板的工具。

尽管办公环境普遍变得更“人性化”，在软件研发的一线上，个体与个体之间的交互关系相比 15 年前变化不大。然而在名义上，这些组织终归也是“敏捷”了。在传播与扩散的过程中，不仅是敏捷在改变着中国 IT 业，这个行业也在改变着敏捷，将这个来自西方发达国家的概念消化吸收成了一个相当本土化的事物。

从我在行业一线十余年的“低视角”来看，这才是中国 IT 业真实的发展样貌——并非像新闻稿和鸿篇巨著所写那样高屋建瓴，反而是由无数普通人自觉或不自觉、主动或被迫、有心为之或机缘巧合的行动一点点塑造起来。

时代的浪潮推动着茫茫众生前行，众生也同样形塑着浪潮。行业今天的样子不仅是因为历史的进程和少数精英的天才想法，更是因为无数普通人的奋斗。

这是我想要在《敏捷中国史》中刻画的东西。我想记录这些——像庄表伟一样——普通的 IT 从业者在行业中的经历与奋斗，以及他们身边的一件件小事如何塑造了这个行业。敏捷中国史，不仅是中国 IT 行业的一段小史，更是无数普普通通的 IT 从业者的一座纪念碑。

在行文中，我用了两种文体。在相对严谨的正文之间，我有意穿插了一些相关的故事（浅灰色小字号部分）。这些故事有的来自朋友之间未必精确的口述，有的还不乏我自己并无恶意的想象。

在我的设想中，会有这样一位好奇的读者，在了解到过去曾发生的“时事”之外，也会对“时人”的际遇报以两声慨叹，那么，我的记录就算得其所哉了。

分享上面的《敏捷中国史》阅读卡片，跟朋友一起了解中国软件开发方法的进化和一代程序员自我突破的故事。

推荐序　敏捷画卷：中国软件史的精彩侧影

1

如果把软件开发当成一个谜题，数代的软件人在过去的 50 年里前赴后继地尝试解决这个谜题，不过到今天为止，全世界不管是码农还是码神，我们仍在这个谜题当中痛苦挣扎。

1965 年 ~ 1985 年，软件危机逐步浮现，这让刚刚进入科学管理时代的人们极其不爽。1931 年建成的帝国大厦只花了 410 天，还是提前完工，写个软件还能复杂过盖摩天楼？那肯定是方法有问题。

供职于洛克希德软件技术中心的 Winston W. Royce，在其 1970 年的论文 “Managing the Development of Large Software Systems” 中提出了一个长得像瀑布的流程，业界似乎找到了一款灵丹妙药，虽然这位搞了多年航天器的 Royce 老兄并没有在他的文章中提到任何瀑布相关的字眼。之后以 1988 年 CMM 的发布为重大里程碑，剩下的似乎就是沿着既定的路线，细化，标准化，量化，优化，再优化……

直到一线干活的人们发现事情其实不是这样，于是生长出了各家敏捷流派，以期解决 Fred Brooks 在 “No Silver Bullet” 一文里提出的复杂性（Complexity）、配合性（Conformity）、隐蔽性（Invisibility）、易变性（Changeability），这些现代软件开发中本质性（Essence）的难度。

2

中国用 20 年的时间迈过了西方 50 年的软件工程发展史。《敏捷中国史》中一个个鲜活的故事和严谨的数据考证一起，描绘了敏捷方法在中国软件产业的土壤中一步步发芽、传播的画卷，构成了中国软件史一个精彩的侧影。

《敏捷中国史》不仅帮读者在宏观层面理清了中国软件工程领域在过去 20 年里发展的关键脉络；一系列从业者的经历巧妙串联，更让读者从个体视角体验历史，了解众多普通的软件人是如何参与着历史和创造着历史。

我个人的从业经历跟敏捷中国史的跨度大致重叠，因此格外有感触。阅读每篇内容，本以为早就遗忘的画面在脑海之中栩栩如生地一页页闪过。

3

我还记得 2001 年在新加坡的一个社区图书馆，第一次翻开 Kent Beck 的 Extreme Programming Explained 给我带来的冲击。

不过一番琢磨之后，我得出了几个轻率的结论：

• 迭代开发玩不转，甲方的预算和立项流程根本不可能让乙方这么干（我当时在新加坡的一个系统集成商工作）；
• 结对编程太奢侈，没有老板会让团队这么干；
• TDD 真是好东西，不过只要团队里有一个人不这么干，其他人也干不下去，让所有人都用 TDD 不现实。

所谓纸上得来终觉浅，直到四年之后，我自己卷起袖子，在全面采用敏捷实践的团队沉浸工作了几个月，才真正体会了那些理念和实践的价值和可操作性。让我很有共鸣的是，文中不少人和公司初步接触敏捷的经历和感受其实也是类似。

看到敏捷中国大会的举办，大型通信企业的敏捷转型，DevOps、设计思维、精益企业、精益创新的推广，ThoughtWorks 相关的记述把影像拉回我的记忆。那些熟悉的名字把他们的面容带回我的眼前，与他们合作中体验到的酸甜苦辣又从心中流过。虽然是文中很多事件的亲历者，我看到的也只是点点滴滴，从没想到有人能如此全局又生动地把握和呈现当时的脉动。

说到合作，我 2007 年加入 ThoughtWorks，那是我真正认识熊节的开始，不过我知道熊节却要更早一些。那时经常在 JavaEye 上津津有味地旁观一个叫熊节的人跟人吵架，觉得这人吵得很有见解，而且吵得很有文笔。于是，我有了无数的机会在现场和邮件里看熊节怼人，以及被熊节怼，从中学到很多。

为什么专门把怼人拿出来说？这其实跟 ThoughtWorks 的风格有关。不满足于现状，寻求更好的理念、方法和工具，追求软件卓越，这是 ThoughtWorks 的使命。ThoughtWorks 期望员工不盲从主流意见，要持怀疑挑战的态度，以求找到不一样的路径，做到比当前更好。熊节就是这种风格的典型代表。

4

20 年中国软件工程方法的变迁也是中国软件行业追赶国际先进水平的历史。巨大的国内市场已经让我们成为一个软件大国，但我们在工程方法领域并没能够取得匹配的领先地位。

我理解《敏捷中国史》不仅仅是对历史的记录和纪念，更是以史为鉴。文中一个个致力于改善工作成效的一线从业者，致力于推广新方法新工具的布道者，正是他们吸引了一批又一批热衷软件开发的人加入进来，一起推动行业的发展。

——张松，ThoughtWorks 中国区总经理

第2-1课　上下求索：软件危机和面向对象

行业高速发展，从业者普遍的不成熟显露无遗。中国软件业遭遇了“软件危机”，学界和产业界都在积极探索解决办法。对于软件人才供给不足、能力偏弱的普遍状况，当时有识之士提出的办法是，一靠面向对象提高软件复用程度，二靠软件工程降低对人才的需求。

对软件工程的渴望

---

从公司回到租住的小屋，孟岩打开电脑，拨号上网，习惯性地登录上了 CSDN 论坛。在这里，孟岩的 ID 是 “myan”，C++ 版和面向对象版的大侠。论坛里很多人在讨论问题时会请教他的意见，甚至引用他的话语。刚考上清华的才子王曦想办一份叫《C++ View》的电子杂志，也会询问他的建议。畅销书《深入浅出 MFC》的作者侯捷通过华中科技大学周筠编辑的关系联络到他，邀请他合译大部头的《C++ 标准程序库》。

孟岩彼时在网络上声名鹊起，重要的原因之一是他在 2001 年 2 月发布的一篇文章：《VC 不是梦想，C++ 需要自由的心》。在中文世界里用“梦想”、“自由”这样的词汇来描述一种编程语言，就算他不是第一个也差不太远。把当年如日中天的微软批评为“封闭”、并振臂疾呼“在我们程序员的心中，没有凯撒，我们可以把你当朋友，但是你别想做我们的主子”、“不自由，毋宁死”，这在当年看来是极具开创性和震撼力的观点。

在这篇满怀浪漫主义色彩的文章中，孟岩指出了“工具”与“技术”的分野。得益于盗版软件的横行，微软的 Visual Basic（VB）和 Visual C++（VC）这些本来昂贵的开发工具，突然变成连大学生也能承受的几张光盘。这些工具极大地简化了带有图形界面的 Windows 应用程序的开发，很多企业和程序员都趋之若鹜：企业招聘时要求掌握 VC（以及其中使用的编程框架 MFC 和 ATL ），程序员把 VC 作为“梦想”。

而在读研期间深入学习了 C++、钻研了开源的 C++ 标准库 STL 的孟岩，对于当时业界只重视单一工具、单一厂商的风气颇有微词。在他看来，掌握一种工具只是软件开发最初级的门径，在这扇大门背后还有“设计模式的精美与一致，面向模式编程范式的初现端倪，面向对象软件工程的成熟与巨大希望，TAO/ACE 的庞大与精致”等“目不暇接的珍宝”。

不过正如他在文中不经意透露出的，当他每天清晨挤上开往中关村的公交车，孟岩会清晰地认识到“我们都还是生活在现实世界中的，精神上的快乐不足以填饱辘辘饥肠”。

研究生毕业后，孟岩在联想谋到一份工作，在刚成立不久的掌上设备事业部做开发工程师。在几乎可以代表中国 IT 最高水平的联想，孟岩看到的是粗放的、手工作坊式的工作方法：从需求分析，到系统设计，到项目管理，再到发布流程，没有一件事是有章可循的，每个人都凭着自己在学校或之前工作的有限经验尽力完成任务，靠加班解决一切困难。理想与现实的巨大反差，让孟岩明白，掌握先进的编程语言、会用先进的开发工具，离顺利交付项目、开发出好的软件，中间还有很大的距离。

如何弥合这个差距？他看到的答案是面向对象。这段时间他特别推崇一本书，Robert Martin 写的 Designing Object Oriented C++ Applications Using The Booch Method 。在当时的孟岩看来，面向对象不仅是一种技术，更是一种涵盖了分析、设计、开发的方法。这种方法的完善与普及，能引导尚处幼年的中国软件企业和软件工程师走向成熟。

---

中国版本的软件危机

中国软件行业的“不成熟”，在更早的时候就已经被业内人士作为一个问题提了出来。早在 1994 年，时任电子工业部计算机司司长的杨天行指出，我国软件产业的现状是企业规模小、人才（尤其系统分析员等顶尖人才）数量少、行业处于初创阶段¹。

到 1998 年，在行业发展较为领先的广东省，已经出现了较为普遍的开发费用超支、软件团队沟通困难、软件重用率低下、开发人员各自为政、任务完成过期、可靠性下降、系统适应能力差、软件质量得不到保证、维护困难、可移植性差、文档不健全、不能适应需求变化等现象，用户抱怨不给予签收也时有发生²。

到 2000 年前后，软件应用严重短缺、软件队伍结构薄弱、软件研发缺乏规范性等问题已经成为阻碍软件产业发展的绊脚石。

对于这些现象，业内人士的一种普遍解读是中国民族软件产业遭遇了“软件危机”。例如 1997 年《上海微型计算机》杂志的一篇短文称，经过市场竞争的检验，许多专家已达成了共识：中国软件设计与生产的弊端在于技术环节不过关，社会化大生产尚未形成³。而应对软件危机的对策则是，亟需提高全行业的软件工程水平。为了理解这其中的逻辑，我们需要首先了解“软件危机”这个词的来由。中国科学院软件研究所王青研究员这样描述软件危机与软件工程的关系⁴：

20 世纪 60 年代，随着第三代计算机的产生，计算机的硬件性能发生了翻天覆地的变化，运行大型的复杂软件系统已经成为可能。然而，相应的软件开发技术却难以满足大型软件系统的开发需要，因而造成：

1. 大多数大型软件开发项目的成本都超过预算，开发进度一再拖延；
2. 软件产品质量不可靠，大型软件系统存在 Bug 几乎成为不可避免的问题；
3. 软件产品难以维护；
4. 软件产品的开发成本过高；
5. 软件产品开发的效率跟不上计算机硬件的发展以及用户需求的增长。

软件技术跟不上硬件技术发展而造成的诸多问题被称为软件危机（Software Crisis）。为了解决软件危机，1968 年在德国召开的国际学术会议上，北大西洋公约组织（NATO）的计算机科学家第一次提出了软件工程的概念，希望通过系统化、规范化、数量化等工程原则和方法来实现复杂软件系统的开发和维护。

按照 Wikipedia 词典中的定义，软件工程是“研究如何开发大型应用系统的计算机科学学科。软件工程不仅覆盖构建软件系统的相关技术层面问题，还包括诸如指导开发团队、安排进度以及预算等管理层面问题”。

由这个定义可以看出，软件工程不仅仅包括编写程序代码所涉及的技术，它包括所有对软件开发能够造成影响的问题。Brook⁵ 在 1987 年指出，不存在任何一个单一的开发技术或管理技术能够解决软件工程所面临的所有问题。因而软件工程是一个包括一系列概念、理论、模式、语言、方法以及工具的综合性学科。

这样一个大而全的一揽子解决方案，无疑给起步不久的中国软件业提供了宝贵的理论依据。

突然之间，一些令从业者困扰已久的问题，似乎都可以从软件工程的缺失上找到答案。例如有人问道：一般大家认为中国人才智过人，很适合搞软件，据说硅谷软件人员中三分之一是中国人，但是在国内却没有把中国人搞软件的智力优势发挥出来，即使有几个很有名气的程序员做了几个受到欢迎的产品（特别是中文产品），这些产品还是处于个体户经营状态，未能形成产业。

这是什么原因呢？原来是少了软件工程：如今软件已从早期的程序概念上升到软件工程的概念，必须要按工程的规范来组织开发和生产，更多地强调标准和团队协调，并需要网络和工具的支持，那种靠个人才智打天下的时代已过去，中国软件发展必须走工程化、产业化、规范化和大团队的道路，将力量相对集中起来，将个人才智熔汇在群体之中，才能形成发展气势⁶。

从事后诸葛的角度来看，一个行业的发展，当然要靠自我奋斗，但是也要考虑到历史的行程。中国软件业新千年前后所短缺的，并不仅仅是如何开发大型应用系统的方法。

然而站在业内人士的角度，相比于宏观经济、国家政策、科技趋势等或许更重要的影响因素，方法论的缺失问题是从业者最有可能把控的。于是，软件工程缺失导致中国版软件危机，软件业振兴亟需软件工程，这一思路在 2000 年上下已经成为业内共识。在“软件工程”这顶大帽子之下，从业者们在积极探寻各种具体的方向。

对面向对象的美好冀望

面向对象（Object Orientation）是一种设计和开发软件的方法。

在计算机技术发展的早期，瑞士知名计算机科学家 Niklaus Wirth 对于“什么是程序”给出了一个明确的定义：程序 = 算法 + 数据结构⁷。面向对象方法的倡导者认为，初级水平的软件开发者会自然地用编程语言描述解决问题的过程（即算法），但经常会忽略被操作、被处理的对象（即数据结构）。当系统规模增大到一定程度，这种数据与操作的脱节会给软件的编写、维护和复用带来困难。

因此他们提议，应该将数据与操作放进同一个单元（即对象），系统的基本逻辑构建块不再是算法，而是对象。在这个理念基础上，发展出了面向对象编程（如何使用对象和类编写程序）、面向对象设计（如何分解和建模对象）、面向对象分析（如何用对象和类的概念分析需求）等一整套软件开发实践⁸。

国内高校和科研机构在 1990 年代就已经开始了对面向对象技术的研究。一般认为，面向对象方法突破了数据与操作的分离，较好地实现了数据的抽象和封装，体现了很好的信息隐藏特性，并以继承、消息传递等方式支持业务领域的概念抽象，因此能够提高软件的可复用性和可靠性，使软件更易理解和维护。在这些潜在收益中，“可复用性”这一条显得尤为诱人。

研究者们相信，给定一个业务领域，第一个面向对象的应用程序也许会比传统的应用程序难以设计，但一旦设计出来，以后的应用程序的设计就变得相对容易，因为以前所设计的对象是可以重复利用的⁹。这幅图景对于正在经历“软件危机”的从业者们而言，无疑是一个美好的应许。

不过落地到真实的软件开发活动中，情况远非如此乐观。要想在应用程序中使用别人开发的对象，开发应用程序的人也必须采用面向对象的编程技术，很多时候甚至必须使用同一种编程语言。

也就是说，虽然面向对象技术能通过对问题的分解更好地描述和组织系统中的复杂性，帮助软件开发者更有效地理解和开发复杂的软件系统，但其根本目的是为了使软件开发团队能够处理复杂度快速膨胀直至“超出人类智能范围”的复杂软件系统，并不必然降低对软件开发者的技能要求¹⁰。

而当时中国软件业面临的挑战不仅是需要越来越复杂的软件，同时能力过关的软件人才也相当匮乏。如果解决软件危机的必由路径是首先培养一大批具备面向对象软件开发能力的人才，听起来似乎是远水解不了近渴。

同时，C++ 等面向对象编程语言本身也并不足以完整解答软件复用相关的各种问题¹¹：如何选择和建立独立的组件？组件按什么方法组织起来？针对不同领域的特点，开发出来的软件系统能否有一个较固定通用的结构模型？

为了开发出真正可复用的软件单元，并且——更重要的是——为了大幅度降低使用这些软件单元的技能要求，一些研究者将眼光投向了组件（component，或称构件）的概念。例如 1997 年，武汉大学软件工程国家重点实验室这样描述基于构件的软件重用技术¹²：

构件软件强调以即插即用的方式重用不同开发人员的开发成果。基于构件库及构件组合的软件重用技术可以将软件开发活动分成两大部分：一是构件的设计与开发；二是构件的管理与重用。开发构件的活动与重用构件的活动不但在时间上和空间上可以互相分离，而且实施两者的主体也可以是完全不相关的开发人员。构件可以独立地进行开发，可以像软件系统那样成为独立的商品；构件的重用可以只是统一、灵活、简便地组合构件。

中科院院士杨芙清在 1998 年的一篇文章里将软件的生产与机械、建筑等传统行业进行了类比。在她看来，传统产业的发展，基本模式均是符合标准的零部件（构件）生产以及基于标准构件的产品生产（组装），这种模式是产业工程化、工业化的必由之路¹³。这是国内计算机学界较早将工程化、工业化理念引入软件产业的表述。

这一理念走出高校的实验室、真正被推向业界实用，还需要企业数年的努力。七年以后，主推构件平台和构件库产品、打出“民族构件化软件”大旗的普元公司在接受《软件世界》杂志采访时声称¹⁴，构件化软件技术是不可逆转的发展趋势，其目的是彻底改变软件开发和生产方式，从根本上提高软件生产的效率和质量，提升企业应用系统尤其是商用系统的成功率。至于为何构件技术有这般功效，这篇文章对杨芙清院士的理念做了更为平实的解读：

十八世纪中期，一场以机器代替手工劳动的工业革命从英伦开始，工业革命最伟大的贡献是促进了生产力的发展，工厂流水线的生产效率高出手工作坊几倍甚至几百倍。直到如今，人类的生活仍然在从传统产业生产车间流水线效率的提升过程中受益，甚至以技术领先见长的软件产业也有回归传统流水线生产作业的趋势，也就是构件化。

可以看到，面对 IT 需求迅速增长、IT 人才供给不足的行业大背景，一种受到广泛关注的思路是借鉴工业化、流水线经验，将高技术含量的设计工作与低技术含量的实施工作严格分离，由少量高技术人才负责软件的设计和构件的开发，大部分低技能水平、低收入的从业者则负责使用可复用的构件进行简单的拼装，完成应用程序的实施。

在这个构想中，那些低技能、低收入的大量 IT 从业者应该像制造业的工人一样，坐在生产流水线旁边，进行相当简单重复的操作。业界甚至给这一群体起好了代号：软件蓝领。

参考文献

1　杨天行.软件产业发展的十年[J].软件世界,1994(09):5-7.
2　陈仲驹.软件开发标准化、规范化是软件产业发展的前提和保证[J].现代计算机,1998(10):30-32.
3　新社.计算机产业应尽快摆脱软件危机[J].上海微型计算机,1997(13):22.
4　中国计算机学会主编.中国计算机科学技术发展报告2004[M].清华大学出版社,2005:63.
5　原文如此，应为“Brooks”。
6　姚卿达,张国海,古威.我国软件产业发展现状、问题及与印度的比较借鉴[J].现代计算机,1998(10):12-17.
7　Wirth, N., 1976. Algorithms+ Data Structures= Programs Prentice-Hall Series in Automatic Computation. Prentice Hall.
8　（美）布奇等著.面向对象分析与设计[M].电子工业出版社,2012.
9　黄涛.面向对象技术的形成与发展现状[J].软件世界,1995(02):9-11.
10　（美）布奇等著.面向对象分析与设计[M].电子工业出版社,2012.
11　唐胜群,唐涛洲.软件体系结构与组件软件工程[J].计算机工程,1998(08):32-35.
12　应时,周顺,朱春艳.基于构件库及构件组合的软件重用[J].计算机工程,1998(11):19-22+37.
13　杨芙清,黄柏素.软件开发的“灵魂”——软件工程技术现状及发展趋势[J].中国计算机用户,1998(42):23+25.
14　齐国涛.普元 把应用开发推上流水线[J].软件世界,2004(11):52.

分享上面的《敏捷中国史》阅读卡片，跟朋友一起了解中国软件开发方法的进化和一代程序员自我突破的故事。

第3-1课　久旱甘霖：敏捷传入中国

当中国软件业满腔热情地向往“工业化”、“工程化”愿景，美国的制造业却在着眼快速、残酷与不确定的变化。对灵活性、响应性的追求，促成了敏捷在美国的诞生。万里之外的中国，也有一批年轻的 IT 从业者，受困于软件工程不能有效解决他们的实际问题，开始关注到敏捷，并在很短时间里翻译引进了敏捷的主要基础著作。

---

为侯捷举办的专家研讨会在《程序员》杂志社的二层小楼里进行。这是 2001 年 10 月，经营着 CSDN 网站和《程序员》杂志的百联美达美公司总共也只有 20 来人，控股的百联集团在位于北京亚运村西侧的利康饭店租了一栋独立的小楼，美达美和另一家公司共同在这里办公。这年夏天，北京成功申办 2008 年奥运会，利康饭店所在的这个位置正是未来奥运村的核心区域。7 年以后，这栋有些老旧的二层小楼将不复存在，在同一地点矗立着的将是被称为“鸟巢”的国家体育场。

第一次参加这种专家研讨会，旁听大家的发言，熊节感到有些费力、又非常兴奋。除了侯捷与孟岩等人围绕 C++ 的讨论让他大感兴趣之外，来自上海的王昕带来了一些新鲜的话题。王昕在 CSDN 论坛的账号是 “cber”，平日里在论坛发言相当尖锐，而且每每能跳出技术的框子，从业务和管理的角度给讨论引入一些新的观点。这天他跟熊节聊的话题就不完全是技术性的：

“你听说过 Refactoring 这个东西吗？”

“没有，”熊节连连摇头，“那是个什么来着？”

“是一种写出高质量代码的方法。你之前不是翻译过一系列关于设计模式的文章嘛！你看啊，设计模式社区的思路是，你先想好应该用哪些模式，然后照着模式的实现方式写出来，你的代码就是高内聚低耦合的。但是难就难在‘先想好’对吧？”

熊节点头。如何在开始编码之前先想好应该如何设计，这是他一直感到困难的一个点。之前孟岩与他讨论时曾经提醒他，“尽管当前软件界里几乎所有的人都为设计模式叫好，不过对于软件工程的发展方向，还是有不少批评意见的”。但这些批评意见是什么、对他熟悉的编程工作会产生什么影响，他并不了解。

“简单地说，Refactoring 这种技术，让你可以随时调整代码的结构，”王昕解释道，“把质量不好的代码修改好，在开发的过程中引入设计模式，那么你就不用担心一开始的设计做得不到位，可以一边编码一边完善设计。”

“现在国外有一个软件工程流派很重视这个技术，”孟岩也加入到讨论中，“因为有了在开发过程中调整设计的能力，才有可能降低前期设计的投入，不然软件开发的技术含量就必然在前期设计，开发必然不被重视。这个流派叫‘敏捷’，你有空可以看看。”

---

制造业语境中的敏捷

处于世纪之交时，中国软件业的主流认为：工业化、工程化、对软件研发过程的严格控制、少量精英设计者与大量“软件蓝领”的组合等借鉴自制造业的经验，是软件业发展的方向。恰好在同一时期，美国的工业界对于“制造业本身应该如何发展”却有了新的思考。

1991 年，在美国国防部的资助下，里海大学亚科卡学院撰写了一份题为《21 世纪美国制造业战略》的报告，对制造业在新千年将遭遇的挑战和应对办法做了前瞻性的论述。在这篇报告及后续的著作中，这批研究者指出“快速、残酷与不确定的变化”将是未来制造业面对的常态挑战：

革新的步伐仍在加速，而革新的方向却常常无法预测。产品多样化已经达到了纷繁缭乱的程度，同时，模仿竞争迅速出现并正在影响企业能够获得的利润。变化和不确定性主宰的经营环境发起了挑战。¹

制造业所面临的挑战，从生产力不足、无法满足消费者的功能需求，转为灵活性不足、无法满足消费者对创新和定制的要求，这一趋势转变可以上溯至 1970 年代的汽车产业。

在汽车产业的早期，产能不足是制造商的主要挑战。为了提高流水线大生产的效率，制造商努力将生产过程标准化，尽量避免定制。据说亨利·福特曾说过“顾客可以选择任何颜色的车，只要它是黑色的”。

然而到了1970 年代，产能过剩已经成为全球趋势，消费者开始提出各种定制需求：他们不仅想要各种颜色，甚至还想定制汽车的各种配置和配件。在丰田的竞争下，以大规模、标准化为特色的“福特制”生产方法明显地呈现出难以适应以个性化、多样化和快速发展为特点的市场环境。从汽车工业开始，美国的制造业逐渐意识到了市场风向的转变，逐渐转向了重视小批量、灵活性的“后福特制”生产方法²。

时至 1990 年代，科技，尤其是信息技术的发展，以及全球化的深入，日益强化了商业环境的不确定性。全球市场正在从大量市场产品和服务标准化、寿命期长、信息含量少、在一次性交易中交换的竞争环境，向产品和服务个性化、寿命期短、信息含量大、顾客基础不断变化的竞争环境转变。应对这一趋势，研究者们提出的对策是“灵捷”（Agile）：

灵捷就是关于企业如何在一个动荡的、竞争激烈的经营环境中获得利润。灵捷竞争要求产品和服务的开发、生产和分销以顾客价值为中心……成功的灵捷企业获得大量的对顾客个人认识，并定期地、广泛地与他们交流。

一个成功的灵捷企业，它的生产运营、组织结构、管理思想、人员需求及技术投资都是由这些顾客机会中心型的经营战略所拉动的。在灵捷竞争环境中，并没有组织和运营企业唯一的正确方法。一个成功的灵捷企业必须以这样一种机制来运营，这种机制使企业能够非常快速地合成新的生产能力。

[灵捷企业]需要激励人员采取独立的措施并向已有的程序挑战。[灵捷团队]新颖的地方在于管理特权的传统观念逐渐削弱，随之而来的是……开放的信息环境……同时操作员工得到决策权。³

显然，这种看待制造业前景的视角，与当时的中国人，尤其是中国 IT 人对“制造业”的想象大相径庭。

在 2001 年前，只有少数研究者在关注相关话题，并且关注的视角是如何用 MRP II/ERP 等信息系统来管理敏捷企业⁴——此时 “Agile” 一词已经普遍地被翻译为“敏捷”。针对敏捷企业动态、开放的组织形态，当时上海交通大学计算机系有一组研究者致力于研究可以根据动态联盟的形成和解体而快速重构和调整的“敏捷供应链”，并提出“基于对象的软件代理技术”作为敏捷企业和敏捷供应链的技术支撑⁵。

现在回头来看，当时所谓的“软件代理技术”，尽管牵连谈到了人工智能等前沿技术，实际上真正成型的是构建在 CORBA 等中间件之上的一种企业信息集成技术，可以看作是后来更流行的 SOA（面向服务架构）的一种早期版本⁶。另外，诸如工作流等技术，因其可以加快供应链管理信息系统建设和调整的速度，也被视为敏捷供应链的支撑技术⁷。

简而言之，在 2001年之前，中国 IT 业内关于“敏捷”一词为数不多的应用，仅限于制造业的敏捷制造、敏捷供应链、敏捷企业概念，以及支撑这些概念的 IT 系统。至于软件本身的研发过程和软件组织的敏捷性，此时尚未进入到行业的视野中。

---

“Refactoring 这个词我知道的，”潘加宇说道，“我这里正好有一篇文章想请你翻译一下呢。”

“哦？什么文章？”熊节的好奇心被勾了起来。这是北京理工大学东门外的一家小餐馆，两人一边喝着小酒，一边聊着《程序员》和《非程序员》最近刊登的文章。从夏天开始，熊节连续翻译了十多篇关于设计模式的文章，在潘加宇办的《非程序员》电子杂志上发表。两人熟络起来，潘加宇每次到北京出差就会来理工大学请熊节吃顿饭。

“ Refactoring 是 eXtreme Programming 这种软件开发方法里面的一个实践，”潘加宇接着解释，“最近国外开始流行一类软件开发的方法，叫做敏捷，这个 eXtreme Programming 就是敏捷方法中的一种，简称 XP。我最近看到一篇文章，是讨论设计模式跟 XP 关系的，你要有兴趣的话，就看看这篇文章呗？”

晚上回到宿舍，熊节上网搜索关于 Refactoring、eXtreme Programming 和“敏捷”相关的资料，很快发现了一个叫 Martin Fowler 的人：这个大胡子美国人在 1999 年出版了一本题为 Refactoring 的书，好像还挺有影响力的。潘加宇塞过来的那篇文章，也是在谈 Refactoring 技术和设计模式之间的关系。联想到前两天和王昕的讨论，熊节感觉这本书貌似还真挺有意思的。

“正好明天杂志社要开选题会了，要不我就报这个选题好了。”一边这样想着，熊节拿出记事本，潦草地写下一行字：12 期技术专题：Refactoring。

---

中国 IT 业与敏捷的初接触

中国的正式出版物首次刊载与敏捷软件开发相关的内容，是《程序员》杂志 2001 年 12 月刊。这期杂志的“技术专题”栏目用了 5 篇文章、12 页篇幅，较为系统地介绍了代码重构（即 Refactoring）。

这个系列的文章，在当时围绕软件工程的讨论中是别具一格的：一方面，它们讨论的不是用某种特定技术实现某种特定需求，而是软件设计的质量、程序的可理解性和可维护性、开发效率等明显属于软件工程领域的话题；另一方面，这几篇文章开展讨论的角度非常具体、非常细节，5 篇文章中有 3 篇给出了真实的程序代码。

以《重复代码》一文为例，作者石一楹从业内司空见惯的“把一份模板代码拷过去稍加修改”的开发方式为切入点，对于软件开发的 7 项基本原则展开了讨论，指出重复代码是损害软件可理解性和可维护性的重要因素，并用一段 C++ 代码范例说明了如何消除代码中的重复。

当时国内绝大多数软件工程相关的讨论关注的焦点在于流程、文档、架构、工具，与实际的软件开发实践、尤其是编程实践脱离较远。这一系列关于代码重构的文章，为中国 IT 业围绕软件工程的讨论打开了一种新的可能性。这期技术专题的导读如是写道：

坚固、灵活、容易维护。每个程序员每天都想得到这样的代码。How to ？编程不是盖房子，程序员不是砖瓦匠。你必须在代码中倾注自己的心力，你必须倾听代码的声音，你必须辨别代码的味道，你必须时时留心让你的代码看起来更漂亮……一句话，你必须善待你的代码。而你的努力不会白费，今天受你善待的代码，明天会加倍报答给你——优美的代码足以让你延年益寿了。

可以看到，这几篇文章所代表的软件工程思路，不是将软件的设计与实现分离、用严格的流程约束“软件蓝领”的“工业化”，而是将实际编写代码的程序员视为对软件开发效率与质量负责的主要角色。

在这种软件工程思路中，程序员所从事的编程工作不是由详细的设计和流程框定的、几乎不需要思考的、“高中生经过短期培训就可以干”的“蓝领工作”，而是软件生产过程中各种质量和效率诉求最终的承担者，因而是需要“倾注心力”的、高技能含量的工作，并且有一整套不同于传统软件工程的流程、技能和工具（重构就是其中的一种）与之配套。这种软件工程思路，就是被称为极限编程（eXtreme Programming）的软件开发方法。

在同一时期，另一些与极限编程相关的内容开始出现在中文互联网上。2001 年 10 月，IBM developerWorks 网站发表了厦门国际银行项目经理林星关于需求分析的文章，文中介绍了极限编程（当时林星将其译为“极端编程”）的核心价值观：沟通、简单、反馈、勇气⁸。

同样在 2001 年 12 月，浙江大学灵峰科技开发公司技术总监石一楹在 developerWorks 网站发表了 “Refactoring Patterns” 系列文章⁹，从较高层面概要介绍了重构技术的原理和实践原则。

除了重构以外，石一楹在文章提到的测试先行、结对编程等，都是极限编程的标志性实践。《非程序员》电子杂志于 2001 年 12 月邀请极限编程的创始人之一 Kent Beck 进行了在线交流¹⁰，又在 2002 年 1 月与 Martin Fowler 进行了在线交流¹¹。

在这些文献资料中，《非程序员》与 Kent Beck 的在线交流显得尤为有趣。发生在聊天室中、氛围轻松随意的交流，加上 Beck 直接犀利的言论（相比之下，Fowler 在交流中就显得更加字斟句酌、四平八稳），让这段文字记录成了一面镜子，清晰地映照出当时业界的情景。

Beck 在交流中提到，当时在极限编程的邮件列表中提及过 100 多个真实项目，他猜测全世界使用极限编程的软件项目不超过 1000 个。当时全世界有大约 20 个区域性的极限编程兴趣团体，主要在美国和欧洲，中国没有这样的团体。作为 1996 年才被发明出来、1999 年才有第一本著作的一种新的软件开发方法学，这个水平的热度并不意外。

Beck 对于极限编程的前景表达了谨慎的乐观态度。网友在交流中提到，众多主流的企业里，管理者们更倾向于使用重型的软件工程方法（例如 CMM ），因为这是更安全的选择。Beck 表示他相信，未来的软件组织会以频繁交付可工作的软件——而非严格定义的交付过程——作为关键的考核指标。

他期望 “50 年之内，许多极限编程实践被当做’只是以正确的方式做事情’接受”，这些实践包括了测试先行、重构、快速迭代交付、全功能团队等。由 “50 年”这个随口说出的数字来看，即使 Beck 自己，对于极限编程的传播也没有太多信心。

参考文献

1　（美）史蒂文·L.戈德曼（Steven L.Goldman）等著,杨开峰等译.灵捷竞争者与虚拟组织[M].辽宁教育出版社,1998:3.
2　刘刚.后福特制[M].中国财政经济出版社,2010.
3　（美）史蒂文·L.戈德曼（Steven L.Goldman）等著,杨开峰等译.灵捷竞争者与虚拟组织[M].辽宁教育出版社,1998:4.
4　张旭.敏捷企业与敏捷的管理信息系统[J].中国计算机用户,1997(13):6-8.
5　段永强,张申生,高国军.基于对象的软件代理的设计和实现[J].计算机工程,2000(05):21-22+25.
6　段永强,张申生,高国军.基于代理的软件设计和软件重用[J].计算机工程,2000(01):43-45.
7　刘建勋,张申生.工作流技术支持的敏捷供应链管理系统研究[J].计算机工程,2001(03):11-12+153.
8　林星.需求分析-软件和需求的实践[EB/OL].
9　石一楹.refactoring Patterns:第一部分[EB/OL].
10　《非程序员》第9期，Kent Beck：只是一种正确做事的方法
11　《非程序员》第10期，Martin Fowler访谈

分享上面的《敏捷中国史》阅读卡片，跟朋友一起了解中国软件开发方法的进化和一代程序员自我突破的故事。

第6-1课　异军突起：J2EE 技术社区的活跃

从 2002 年左右起，线下的技术社区交流活动逐渐成为一种风气，受到各地从业者的喜爱。随着 J2EE 技术在政企信息化领域的广泛应用，J2EE 相关的技术社区也蓬勃发展，其中就包括了后来颇具影响力的 JavaEye。

---

下午 1 点半，浙江大学玉泉校区的 300 人阶梯教室已经陆续有人进来落座。石一楹和何晓东在教室门外抽完一根烟，进门走向第一排座位。熊节坐在第一排角上的位置，正在对着笔记本电脑屏幕念念有词。

“今天人不少呀，都是冲着小熊你来的咯，”石一楹促狭地打趣道，“你等下上台可不要紧张呀，哈哈哈……”

“哎呀我都紧张死了，从来没上台讲过东西，你还搞了这么大一个场地，一会儿讲砸了可怎么办？”熊节抬起头，满脸愁容地说道。

“你就放心吧，你都翻译了《重构》了，就书里的东西讲讲大家也是爱听的。”石一楹安慰道，“别怕，这个主题你就是最懂的人了，台子底下谁也没有你懂得多，都等着你来普及知识呢，你尽管大胆讲。”

“就是，万一讲不好还有一楹的演讲在后面压轴嘛，反正一大半人是冲着一楹的名气来的，你只是暖个场，不要想太多啦，哈哈哈哈……”何晓东也拍着熊节的肩膀打趣他，熊节把头埋在桌上，摆出一个“不要理我”的姿态。

挂钟的时针指向 2 点，浙大软件学院的一位副院长做了个简短的开场，就邀请熊节上台演讲。熊节起身走上讲台，把自己的笔记本电脑接上投影视频线，转头确认背后大屏幕上的投影显示是否正常。大屏幕的上方，一条红色横幅写着“ERPTAO 软件技术讲座”几个大字。再看向台下，全是求知若渴的眼神。熊节深吸一口气，开始了演讲：

“今天我想跟大家分享的主题是‘重构思想’。什么是重构呢？要讨论这个话题，我们先来看一段代码……”

---

J2EE 新趋势：没有 EJB

中立于厂商的、纯分享性质的线下技术交流活动，在中国软件行业里最初的发起者可能是 CSDN。

2002 年春节后，CSDN 与北京软件行业协会（BSIA）共同发起了“优程—CSDN 技术沙龙”线下活动。在一次较小规模的试水后，这个技术沙龙在随后三个月里先后邀请了微软、Borland、Sun 的技术布道师进行分享交流，不偏不倚覆盖了当时在应用软件开发技术领域最重要的三家厂商¹。

在此之前，软件业内的技术会议都是厂商赞助、以宣传厂商产品为主。CSDN 的创始人蒋涛在发起这个活动时，希望改变厂商导向的价值定位，立足于服务广大从业者、尤其是软件开发者，为他们提供中立客观、有实用价值的信息。

这种价值定位在 4 月发生的第 3 次技术沙龙中体现得淋漓尽致：尽管演讲嘉宾李维是 Borland 的技术布道师，却是从行业角度客观讨论程序员的职业发展，并不宣传 Borland 的产品，甚至提出“程序员应该正确认识自己的发展方向，而不要把注意力集中于某种语言或讨论工具的优劣上”的建议。

CSDN 技术沙龙在行业里开了一股新风气。在随后 CSDN 主办和协办的一系列活动里，这种受众导向的定位继续得到发扬，再加上邀请了如“C++ 之父” Bjarne Stroustrup 这种技术人员眼中的“大神”²，受到了从业者、尤其是技术人员的广泛青睐，也被其他组织效仿。

杭州的 ERPTAO 组织模仿 CSDN 技术沙龙的形式，在浙江大学举办了软件技术讲座，主题既有与敏捷方法相关的“重构思想”，也有纯技术性的 “O/R Mapping 技术”³——后者的主讲人是最早在 IBM developerWorks 网站上连载重构相关文章的石一楹，此时他关注的技术热点之一，是在企业应用中使用 Hibernate 作为 O/R Mapping 实现工具，从而避免使用 EJB。

1998 年，发明了 Java 技术的 Sun 公司将 JDK（Java 开发包）的版本升级到 1.2 版。这次升级伴随着大量的新特性、新方向，尤其是在标准 JDK 的基础上提供了支持企业应用开发和移动应用开发的大量工具和类库，是 Java 历史上一个重要的里程碑版本。

从这个版本起，Sun 公司将 Java 定位为一个“平台”（而不仅仅是一种编程语言），使用了新名称“Java 2 平台”，并将其分为三个主要分支：用于一般编程任务的标准版（Standard Edition，J2SE）、用于移动应用开发的微型版（Micro Edition，J2ME）以及用于企业应用开发的企业版（Enterprise Edition，J2EE）⁴。经过几年的发展，到 2003 年发布其 1.4 版本时， J2EE 已经成为行业信息化领域中最重要的技术平台。

J2EE 在行业信息化领域独领风骚的原因有几个。

首先，因为采用了虚拟机架构，Java 语言具有“一次编写、到处运行”的可移植性，因此生产系统可以在 Linux 服务器上运行，而不必绑定微软的 Windows，给了甲方更大的采购灵活性。其次，Java 语言与当时大学编程教学所用的 C 语言在语法上有很大相似之处，从业者学习门槛较低，掌握该语言的人数很多，给了乙方更大的人员灵活性。最后，J2EE 为企业级运算的许多领域设立了标准，促使各家应用服务器厂商基于标准提供常用的软件组件，从而缩短企业应用开发周期、提高程序员生产力⁵。

例如，如何访问数据库、如何编写 Web 应用的逻辑与界面呈现、如何集成企业中已有的若干软件系统，这些在行业信息化浪潮中普遍存在的问题在 J2EE 中都有现成的标准和工具可以解决，这就使软件开发团队更有信心选择 J2EE 来实施项目。

在 J2EE 的若干标准中，EJB 处于核心的地位。作为 Java 平台上的组件技术，EJB 又细分为三大类：Session Bean 用于承载企业应用的业务逻辑，Message Driven Bean 用于处理企业应用的多系统集成，Entity Bean 则用于处理数据库存取。

然而在 2003 年，以石一楹为代表的一批一线企业应用架构师开始旗帜鲜明地反对使用 EJB，其中首当其冲被他们批评的技术，就是用于处理数据库存取的 Entity Bean。

Gavin King 是最早对 Entity Bean 正面提出批评的技术领袖之一。他直言 “Entity Bean 正快速失去在业界的流行度”，因为 “EJB 2.1 中的 Entity Bean 在实际应用中就是灾难”⁶。由于规范设计上的不足，Entity Bean 并不是完善的 O/R Mapping（对象/关系映射）解决方案，也就是说，它不能很好地弥合面向对象的 Java 语言与关系型数据库之间普遍存在的“范式不匹配”。

基于对 Entity Bean 的不满，2001 年，时年 27 岁的 King 单枪匹马在很短的时间里开发了开源的 Hibernate 框架。随后的两年，Hibernate 在业内迅速蹿红，到 2003 年，国内如石一楹等技术领袖已经在项目中实际使用 Hibernate，并积极地向同业者宣传推广自己的经验。2004 年 2 月 ERPTAO 组织在浙大软件学院举办的技术讲座上，石一楹所讲的 “O/R Mapping 技术”主题，实际上就是在介绍 Hibernate 框架的设计理念与实用经验。

JavaEye 的诞生

同一时期，另一位较早使用并积极传播 Hibernate 框架的从业者是上海的范凯。2003 年 6 月，他以 robbin 的 ID 在一个当时小有名气的论坛“解道”参与了一个题为“最佳 J2EE 方案讨论之 O-R Mapping” 的讨论⁷，前后发表了数十篇、上万字相当有技术深度的回复，解答了关于 Hibernate 的事务处理、跨表查询、集群部署、架构设计等方面的诸多问题，受到很多同行的关注，一位论坛网友回帖说“一口气看完 5 页帖子，有一种观赏华山论剑的感觉”。

然而这个帖子的讨论并不止于技术。最初的发帖人就指出了 Hibernate 相比于 Entity Bean 的 6 大优点，范凯在讨论中也提出“不要轻易使用 Entity Bean” 的建议。而解道论坛的版主彭晨阳（论坛 ID 是 jdon）则倾向于严格遵循 J2EE 规范的建议、使用 Entity Bean，并提出对作为开源软件的 Hibernate 的担忧：“选择框架软件最好是主流，Hibernate 可能很好，但是生命力有多长？如果主要开发者停止了，你的产品也就陷入停顿发展”。

正如彭晨阳后来所说，这场讨论“实际是先进的非标准技术和成熟的标准技术之争”，他认为“技术本身是中立的……EJB 本身优点是大于缺点”，而业界讨论的 EJB 的若干问题都是由于“没有学会正确使用 EJB，或者胡乱使用 EJB”。这种观点，显然与 Gavin King 所发起、一路流传到范凯这里的观点大相径庭。

于是，在随后的几个月里，范凯在解道论坛发起了一系列更有针对性的讨论，用大量实证的论据阐述 EJB、尤其是 Entity Bean 本身的设计缺陷，以及 Hibernate 相比于 Entity Bean 的优势。

彭晨阳也积极地回应了这些讨论。两人间的讨论很快变得火药味十足，从技术的探讨延伸到了对个人专业能力的怀疑。大约在 9 月左右，彭晨阳删掉了范凯一批帖子，并单方面总结“这个争论本身实际是毫无意义的……在 Java 世界，之所以是百家争鸣，显得乱，但是不失去章法，关键是有标准……标准在 Java 中是主心骨，非常重要的地位”。

显然范凯并不认为这个争论是毫无意义的。被彭晨阳删帖之后，范凯自己开了一个论坛，这就是当时的 “Hibernate 中文站”、后来的 Java 视线（JavaEye）。

建站之初，范凯颇有所指地在一个帖子里说“在 Hibernate 中文论坛里面提出批评 Hibernate 的帖子，是不会被删除的……只有不遵守《论坛提问的智慧》的帖子才会被删”⁸。后来的 JavaEye 的确坚守了这一原则，一方面强调讨论的高质量、另一方面鼓励观点的多样性⁹，在业内名声很好。

到 2011 年被 Oracle 强迫改名为 “ITEye” 之前，JavaEye 有 80 万注册用户，每天 130 万页面浏览量，很可能是当时全球最大的在线 Java 技术社区¹⁰。

参考文献

1　对这一系列技术沙龙的报道见于《程序员》杂志2002年4~6期
2　C++之父中国行精彩回顾[EB/OL].
3　杭州ERPTAO组织成功举办第一次技术讲座[EB/OL].
4　维基百科.Jakarta EE[EB/OL].
5　(美)DeepakAlur,(美)JohnCrupi,(美)DanMalks著;刘天北,熊节等译.J2EE 核心模式[M].机械工业出版社,2005:8.
6　Christian Bauer,Gavin King著.Hibernate实战[M].人民邮电出版社,2008:640. 在这本书的草稿中，King更进一步批评“整个EJB完全是委员会[脱离实际的]创造，已经被Java社区所抛弃”，但在成书中去掉了这句话
7　转贴：最佳J2EE方案讨论之O-R Mapping： hibernate v.s. CMP，请大家讨论[EB/OL].
8　Hibernate In action里这样评价entity bean的[EB/OL].
9　Teahour访问谈JavaEye网站(2)[EB/OL].
10　范凯.JavaEye为何被迫改名ITeye[EB/OL].

畅聊技术历史与人生

我们希望订阅课程的朋友们可以一起把酒言敏捷，分享技术世界的一切趣事，畅聊各自的技术人生。《敏捷中国史》是普通 IT 人形塑历史的故事，也是永远不会完结的技术旅程。你可以将自己的想法发表在评论区，也可以加入《敏捷中国史》交流群，小到我们一起完善这部作品，大到共同创造未来更好的 IT 世界。（入群请加 GitChat 小助手伽利略的微信，ID 为 GitChatty6，注明「敏捷」。）

分享上面的《敏捷中国史》阅读卡片，跟朋友一起了解中国软件开发方法的进化和一代程序员自我突破的故事。

结束语　敏捷中国：筚路蓝缕，以启山林

2018 年 5 月的银行业例行新闻发布会上，招商银行的 CIO 陈昆德骄傲地宣布，此前一年招行金融科技创新项目“从提出创意，到落地上线，平均周期仅 128 天”，并提出招行在未来三年要“真正实现科技敏捷和业务敏捷”。

这一事件在中国 IT 业的敏捷历程上堪称里程碑，因为这是一向以保守闻名的大银行 IT 首次明确地将“缩短响应周期”作为自己的成绩来宣传，而这一点正是敏捷的要义所在。可以说，陈昆德的这次宣讲，客观而坚实地明确了敏捷在当今中国 IT 行业的主流地位。

回望过去的十多年里，敏捷在中国走过的历程，可谓筚路蓝缕。

2001、2002 年，彼此互不相识的几组人，几乎不约而同地向中文世界引进与敏捷相关的资料。

《程序员》杂志在 2001 年 12 月专栏介绍重构、2002 年 3 月专栏介绍极限编程，是中文出版物中有案可查的最早的先行者。

2002 年 10 月，人民邮电出版社出版了《极限编程丛书》。

到 2003 年，《软件研发》杂志的创刊号大篇幅介绍敏捷方法，《重构》《敏捷软件开发》《自适应软件开发》等一系列重量级著作引进。今日的风起云涌，即肇始于当年的青萍之末。

然而在短暂的闪光之后，敏捷在中国陷入了长达数年的低谷。究其原因，敏捷所强调的快速迭代、持续交付，对于植根政府和大企业内部信息化、仰赖“十二金”工程哺育的尚处幼年的中国软件行业而言，是太过超前了。对于其时的行业环境与技术环境而言，每两周一次迭代、每次迭代发布上线给用户使用，既不可能、也不必要。那时的中国 IT 业，还没有做好迎接敏捷的准备。

决定性的转机发生在 2008 年前后。

通信行业遭遇前所未有的竞争压力，诺基亚、爱立信、华为、中兴等通信大厂积极开展敏捷转型，这几家公司培养出的大量优秀敏捷教练与持续集成专家，为后来敏捷在行业里的广泛传播起到了推波助澜的关键作用。

ThoughtWorks、优普丰等一批咨询公司，也在通信业的敏捷转型浪潮中获得了大量咨询顾问业务，在这些咨询项目中打磨出一批理论与实战兼备的敏捷传道士，为后来敏捷的蓬勃发展做好了人才储备。

几乎在同一时间段，Web 2.0 的创业热潮从硅谷传到中国，不论小型初创互联网企业，还是百度、腾讯、阿里（BAT）为代表的互联网大厂，都面临前所未有的机遇与挑战。

与通信企业不同，互联网企业与敏捷方法有更深的基因相似性。在缩短交付周期、加速用户反馈的天然诉求倒推之下，众多互联网团队几乎自发地采用了敏捷的关键实践。几年积累下来，短迭代、持续交付、DevOps 等实践逐渐成了行业中普遍认可的标准，将敏捷的边际向前拓展到业务、向后拓展到运营。

随着互联网、数字化对传统行业的冲击，互联网企业的工作方式也受到各行各业的重视，遂将敏捷带入了主流视野。

然而在其内核处，敏捷强调的“可工作的软件”对于配置管理、质量保障相关的技术实践要求甚高，对于在 IT 人才争夺中本就落于下风的传统企业而言，落地难度很大。众多企业只得退而求其次，从 Scrum 的管理实践入手，冀望首先提升需求管理和项目管理能力。

这个无奈的“退而求其次”，一方面使 Scrum 这种敏捷方法深入行业、并且形成一个活跃的社群，另一方面也引发了对于 Scrum 认证培训有效性的不同观点。在扩散和下渗过程中的内涵流失，最终在很多企业变成只见其形不见其神的呆板管理手段，似乎是各种先进管理方法在中国难以绕开的难题。

与敏捷的变革浪潮同步发生的，还有 IT 企业办公环境的变迁。从早年间的格子间，到日益流行的开放式办公室，IT 从业者在感受到自己日益被企业重视的同时，肩上的工作压力也在日益加重。几家互联网大厂与华为取得的辉煌成功不仅让行业找到了学习的标杆，也让 996 成为无须掩饰、甚至理直气壮的要求。除了加班之外，追求沟通效率的办公环境、无限便捷的通信工具、以及敏捷开发方法，也都是加重从业者压力的因素。

作为中国敏捷十余年发展历程的亲历者与推动者，透过敏捷被引进中国、被推介、被传播、被漠视、被抗拒、被接纳、被推崇、被转变、被淡化的过程，笔者看到了整个中国 IT 行业、乃至中国经济发展的缩影。

今天敏捷成为业内最为广泛采纳的软件开发方法，背后折射出的是 IT 在国民经济生活中的地位提升、是技术人员从外包码农到企业核心竞争力的地位提升、更是中国经济在全球经济中的地位提升。

随着中国 IT 业乃至中国经济在全球地位的提升，来自美国的敏捷软件开发方法一边被广泛接纳、一边也开始日益显出其局限性。未来中国的 IT 行业应该用什么方法来指导，将是历史的崭新一页。

畅聊技术历史与人生

我们希望订阅课程的朋友们可以一起把酒言敏捷，分享技术世界的一切趣事，畅聊各自的技术人生。《敏捷中国史》是普通 IT 人形塑历史的故事，也是永远不会完结的技术旅程。你可以将自己的想法发表在评论区，也可以加入《敏捷中国史》交流群，小到我们一起完善这部作品，大到共同创造未来更好的 IT 世界。（入群请加 GitChat 小助手伽利略的微信，ID 为 GitChatty6，注明「敏捷」。）

第1-1课　腾飞原点：2000 年，一个 IT 行业的春天

第1-2课　一日千里：拉动 IT 行业的三驾马车

第1-3课　策马扬鞭：奋起直追的中国 IT 人

第2-2课　适逢其会：软件蓝领和 CMM

第2-3课　南橘北枳：中国特色 CMM

第3-2课　志趣相投：“敏捷宣言”引发共鸣

第4-1课　应对挑战：渐进式设计与重构

第4-2课　应对挑战：测试驱动开发与持续集成

第4-3课　应对挑战：迭代与用户故事

第5-1课　他山之石：2005 年的美国 IT 业


第5-2课　水土不服：无用武之地的敏捷

第5-3课　短兵相接：CMM 与敏捷的恩怨

第6-2课　适者生存：轻量级 J2EE 的浪潮

第6-3课　星星之火：敏捷社区的言论阵地

第6-4课　开路先锋：ThoughtWorks 与“敏捷中国”

第7-1课　崭露头角：通信行业尝试敏捷转型

第7-2课　巨人转身：华为的敏捷决意

第7-3课　以小及大：探索规模化敏捷

第7-4课　别开生面：拓展敏捷的外延

第8-1课　天生敏捷：Web 2.0 弄潮儿

第8-2课　敏捷之路：互联网巨头腾讯

第8-3课　敏捷之路：互联网巨头阿里

第9-1课　开枝散叶：敏捷在行业的扩散

第9-2课　青睐有加：Scrum 渐成主流

第10-1课　运维敏捷：持续交付和 DevOps

第10-2课　企业敏捷：设计思维和精益创新


第11-1课　敏捷与职场：IT 人办公空间的进化

第11-2课　敏捷与职场：IT 人办公时间的进化

大事记　敏捷中国史关键节点

阅读全文: http://gitbook.cn/gitchat/column/5c1a1c431e59245d4d2aede1