软件工程——从艺术走向科学

引　言

我单枪匹马时，曾经是个好程序员。当带领团队时，却搞得一败涂地。如何改变被动局面，带出最优秀的团队？这篇文章以我亲身的经历，写下我和我的团队在软件工程管理和软件系统设计与开发方面的学习历程，也许，这有助于您了解我们的软件开发过程或者给您带来一点点启示。

一、艺术与科学

很久以前读过一本书，讨论了艺术与科学的区别。作者认为，艺术不能仅仅局限于音乐、美术、戏剧等传统领域。凡是那些凭借天才的、超出常人想象力的发明创造都属于艺术的范畴。诸如牛顿万有引力定律、爱因斯坦相对论、欧几里得几何体系、哥德尔不完备性定理等等，都属于艺术范畴——艺术就是天马行空，艺术意味着独创！

科学是可重复可学习的事物。突破牛顿的时空观建立相对论理论是独创性的，同样突破爱因斯坦相对论体系建立新的科学体系也是一个独创。这些过程需要天才的科学家来完成，这属于艺术范畴。然而，应用相对论理论求解普通物理问题则不需要天才的物理学家来完成，借助一定的培训，人人都可以出色地应用相对论理论计算卫星轨道半径。这种不需要天才、不需要独创就能完成的任务属于科学范畴——科学意味着规范、可重复，科学是能通过学习掌握的技能！

率领我的团队经历无数失败之后，我终于发现，一个从事软件开发的团队要想获得成功，必须摆脱程序员人人天马行空、无拘无束的状态，使软件开发从艺术走向科学。什么是科学的软件工程管理，如何走向科学的软件工程管理，是本文唯一要叙述的问题。
本文区区数千字，可能完全不值得一提。然而，作为我的团队历经数年、损失逾百万代价而得到的一份总结报告，它至少有一些参考价值。去年我曾在CSDN博客上写过一篇同名的文章，这次应公司之邀，重写这篇文章，希望能重更深的层面上谈谈我这几年来的感受。

二、艰难的岁月

一个团队没有成功的项目作支撑它很快就会死去，如果没有失败工程作镜子它也不会变得成熟。

数年前，我们公司的一个项目搁浅了。一个由四人项目小组承担的工程已经延期数月不能验收，项目有彻底失败的危险。我和搭档 nothatno 最后承接了这个烂尾工程，我们用了一周时间重新编写了服务器端软件，一周时间解决了数据分析系统——两周时间系统就顺利验收了。

我个人有着良好的程序员履历，做过很多成功的项目。把我处理软件工程和系统设计的原则总结出来，或许能够帮助他人提高项目 成功率。最终遗憾地发现，握处理问题的策略五花八门，自己没有能力归纳总结它们的共性。

具体问题具体分析——这真的需要一点小小的天才！这恰恰就是我的团队面临的最大问题，也许人人都是天才，但是由天才组成的团队可能是一个笨蛋团队。一百个笨蛋加起来是笨蛋，一百个天才加起来可能也是笨蛋。

每个成功的程序员都有一套成功的潜规则深深地埋藏在大脑，无形中左右着他走向成功。但是，他却无法发现这些规则究竟是什么样子，以至于他无法总结自己的行为。这使得我非常非常痛苦，我知道自己功力修炼还远远不够，还不足以 从理论的高度总结自己。必须从外界汲取充分的营养才有可能使自己的思维上升到更抽象的层次，从偶然王国走向自由王国，居高临下解决目前面临的问题。

可是，通往自由王国的道路在哪里呢？

在这期间，我的团队付出了巨大的代价。一个大型工程换了四组人马，历经数年仍未通过验收；另一个大型工程换了两组人马，付出数年的工作后，以彻底失败结束。与此同时，我几乎买下了所有能买得到的软件工程资料，牺牲了所有的业余时间，希望能尽快在字里行间找到答案。此时的心情应该和董存瑞炸碉堡的心情差不多吧，早一天找到答案，我的团队就多减少一天的损失。

三、UML与RUP

在众多的软件工程理论和方法中，UML首先引起我的注意。开始我以为UML提供了从项目需求调研到验收整个阶段的规范和工具，仔细研究之后，才知道 UML 只是软件工程的一个可视化设计工具。

尽管 UML 远远不是问题的答案，但它确实是一套很好的工具和标准。目前 UML 已经成为我们公司标准的软件方案设计工具。RUP的全称是Rational统一过程，是UML所推荐的软件工程开发过程规范。这里面有一些重要概念引起我的注意。

首先是“用例驱动开发”的概念。RUP认为开发活动的根源在于需求，而需求在UML体系中表现为“用例”。这个观念和我最初的想象是吻合的。但是，我希望更为具体的东西，可惜无论UML还是RUP都说不清楚了。

其次，增量式开发给了我很大的启发，我过去没有意识到这个概念，尽管多次这样做过。增量式开发的理论依据是，我们不可能在系统设计之前把客户需求全部搞清楚。而在这之前，我犯的一个最大的错误就是试图弄清楚用户的全部需求。两个 失败的工程，都以数百页的需求文档开始设计，结果酿成大错。实际上，采取增量式开发应该在项目的开始首先确定核心部分的需求和设计方案，并通过编码得到可实际运行的系统，在此基础上进一步确定下一增量的任务。

采用增量式开发的好处就是把任务分成若干阶段逐步进行，重要的内容放在靠前的阶段完成，次要的内容则可以放在稍后的阶段完成。这象爬山一样，应该一步一个台阶地前进，而不是企图一步登天。

RUP把软件开发过程分成四个大的增量：初始阶段、细化阶段、构造阶段、移交阶段。用盖楼来比喻这四个过程，初始阶段相当于打地基，细化阶段相当于建立基本框架，构造阶段相当于完成全部主体工程，移交阶段相当于装修入住。

第三，RUP提出了迭代式开发的概念。RUP认为开发过程的每一个增量都应该采取规范的形式进行，但是如何做才算规范，RUP没有给出答案。

UML和RUP初步把我带上了一个正确的道路，尤其是增量开发的概念让我看到了光明。这个时期，我的团队的工作状态有了明显的改观。我 知道这离终极目标还远得很，学习和思索一天也没有停止，终于有一天，接触到了一个全新的理论，让我看到一片曙光。这种理论就是——IBM净室软件工程方法。

四、IBM净室软件工程方法

开发软件犹如解数学题。作为开发人员，我们需要知道问题的条件和所求，然后才能给出问题的解法。

给我的感觉是，软件系统往往复杂无比， 一个很简单的系统可能存在无穷多的输入状态。以排列组合的方式精确罗列软件需求根本是不可能的。比如，Windows的计算器程序已经很简单了，如果让你罗列可能的用户输入，你能办得到吗？这一错误的判断自从学习程序设计以来一直牢固地盘踞在我的大脑深处。

偶然看到一本介绍IBM净室工程技术的书，书中的理论惊得我目瞪口呆，以至于那天的中午饭都忘记吃了。净室理论认为， 由于计算机内存和硬盘空间是有限的，无论多么复杂的软件系统最终必然等价于一个有限状态机。

我马上联想到抽象代数里学过的有限变换群的循环子群定理。一台状态有限的机器，影响其状态变化的外部条件一定是有限的。一个元素个数无穷大的外部条件集合，一定存在某种等价关系，使其等价于一个元素个数有限的外部条件集合。

净室理论也完全颠覆了传统的软件测试方法，从程序正确的可证明性和基于随机过程模型的正确性统计，让我无意中也掌握了一套新的软件系统测试理论，同时也彻底拒绝了传统的软件测试方法。

这时我认为自己找到了全部的问题答案，而事实上，我仅仅触及到一种全新的软件工程理论的冰山一角。随后的一系列发现，让我不寒而栗——过去的几年里，我实在是无知者无畏！

五、理论实践、再理论再实践

向我的团队灌输净室理论时，反馈给我的是一片嘘声。大家满已经足于增量式开发，而且很多人对极限编程方法所吸引。我决定自己在新的项目中实践净室方法，结果带给我的是一次又一次的失败，每次都让我在此退回到RUP的基本框架下。对于一个工期有限的工程来讲，一个复杂的有限状态机和无限状态机没什么区别。

原因是对净室的理解还太肤浅，一定还有更深层的观念我还没有意识到。工作之余我不断地思索为什么一次次地应用净室方法失败的原因，同时，不断搜罗更多的资料开阔自己的思路。

改变我观念的是另外一本书《从规范出发的程序设计》，这是一本从数理逻辑出发探讨软件设计方法的书。这本书认为，程序设计本身是从需求规范到目标代码的一个逐步精化过程。每次精化必须遵循一些严格的规则，这些规则可以用完全形式化的方法表达出来。很久以后我 读了另外一本叫做《B方法》的书后才知道，这本书讨论的是形式化软件工程技术方法。可以断定，形式化方法必然是软件工程未来唯一的方向。

当时感觉这本书可谓是软件工程的“圣经”，我们不可能比它更抽象更精确地讨论软件工程学问题了。这本书我反反复复读了一年的时间，仔细思索着里面每个概念、定理的实际意义和价值。有这样的理论垫底，反过头来研究净室理论有一种豁然开朗的感觉——净室理论只不过是形式化方法中一个再简单不过的实例。没有必要把目标集中在如何建立简单的有限状态机上，有限状态机可以有很多形式存在，一些高级模型可以很好地简化有限状态机的建模。例如，利用Petri网模型可以使许多复杂的有限状态机模型得到根本性的简化，使得复杂无比的系统顷刻间转化为最简单Petri网模型。只要开发过程符合“精化”的规则和规范，就 可以保证目标代码的正确性。我们大可不必拘泥于净室或其它什么具体技术框架的约束。

“精化”的概念使我对净室理论里的“状态”的本质也有了更深刻的理解。我们必须合理把握系统“状态”的颗粒度。颗粒度太大，对代码实现没有帮助；颗粒度太小，造成系统过分复杂。合适的颗粒度应该恰好与程序代码的结构匹配——如果两个输入状态在程序中的流程是一样的，这两个状态就应该合并；如果一个状态可能在程序中可能经过两个不同的流程，这个状态就应该分解。本着这个原则理解净室理论中“状态”的概念才恰到好处，净室过程的复杂度才和工程的复杂度相匹配。

六、壮士断腕，东山再起

这期间我和团队矛盾更为明显。我下定决心推行形式化方法，然而，大多数人的不理解我的做法。甚至不少人认为我是在拿自己的数学特长压制他们。预料之中的结果发生了，我的团队2005年彻底解散了，只有aley和我最后留下来重新组队。此时，我的团队为公司造成的损失已经超过一百万，如果不能及时扭转形式，我也不得不另谋高就了。

接下来我们承担公司某系列软件的开发任务，这是我们第一次正式用形式化方法开发软件。和以前不同的是，这次我们在形式化理论方面已经基本成熟，所掌握的技术足以开发这款小规模的系统。这款软件采取逐步升级的策略，短短半年时间更新了6个主要版本。进入2006年时，这款软件已经趋于成熟，下一版本的蓝图和关键技术已经通过审核。如果不是2006年大型工程任务较重而暂停开发的话，2007年元月份我们就推出这款产品的终极版本了。

这是采用形式化技术开发的第一款软件产品，软件系统体系结构由我们设计，核心算法由我编写，系统实现和外围插件是以外包形式委托开发的。虽然这款软件还存在一些问题，但是，这毕竟我们第一次成功地运用的形式化程序设计技术的成果。 这里我向热心的用户们郑重承诺，今年下半年我们会推出该产品的2007版，也是该产品的最后一个版本，在她诞生二周年之际，我们 一定会让您得到一个惊喜的结果！

七、从艺术走向科学，从科学走向成功

2005年是我职业生涯的最低谷，我的团队只剩下aley和我。我很感激aley，因为在最困难的时期，他一直成功地管理着一系列项目。

2006年终于峰回路转，我们决定扩充队伍。

和以往不同，我们这次仅招收计算机专业或数学专业的应届毕业生。一张白纸，可以花更新更美的图画。 新程序员上班的第一件事就是接受“零缺陷程序设计”的理论培训，必须了解形式化软件工程的理论，树立零缺陷的设计理念。

正确的理论加上正确的实践，正使得我们越来越有力量。最近，我们一个完全由应届毕业生组成的小组在短短四个月的时间完成了近百万造价的工程，而在过去，这中大型系统可能需要1~2年时间才可能完成。

回顾这几年的艰难的学习和工作的历程，我的总结就是：从艺术走向科学，从科学走向成功！