软件公开的秘密

现在是数字时代，各种软件产品是数字世界的出入口，软件开发生产（以下简称“开发”）的背后，有什么秘密？

1 软件系统产品

计算机科学家弗雷德里克·布鲁克斯（Frederick P.Brooks），上世纪七十年代，出版了一本计算机的经典著作：《人员神话》（The Mythical Man Month，这本书是一本计算机、软件的科普类书籍，值得所有人一读），把软件产品分为四类：

1. 最简单的是独立软件：在指定平台环境下、可运行某些功能的独立程序软件，一般由一两个人完成（软件英雄故事的范本）。有两种途径可以使程序转变成更有用的、但成本也更高的东西。

2. 一种是软件产品：任何用户可运行的、各种平台环境适用的、可长期使用维护扩展的软件。要成为通用产品，首先，代码、数据结构必须按照统一风格来编写；其次，程序必须进行彻底测试，确保它的稳定性和可靠性；而且还需要有完备的文档，每个人都可以加以使用、修复和扩展。经验数据表明，相同功能的软件产品的成本，至少是“独立软件”的三倍。

3. 另一种是软件系统：考虑集成、协议、用户数据、兼容的软件组件、模块或子系统（如现在的“插件、库”）。要成为可组装的系统，首先，软件必须按照一定的要求编制，在语法和语义上精确定义输入、输出接口；其次，还要符合预先定义的资源限制，如内存空间、输入输出设备、计算机时间等；最后，程序必须同其它系统组件集成，以任何能想象到的组合进行测试。由于组合产生的交互爆炸，稳定性的测试工作将会非常耗时，因此相同功能的软件系统成本，至少是“独立软件”的三倍。如果系统有大量的组件集成，成本还会更高。

4. 软件系统产品：她的成本高达“独立软件”的九倍，只有她，才是用户真正需要的产品，是大多数软件开发的目标。

布鲁克斯对软件的分类，个人认为现在仍然适用。而且，随着软件用户、生产人员的平民化，软件需求的复杂化，软件成本持续走高；布鲁克斯的估算，被成功的、失败的案例，不断地证明。

2 软件开发特点

软件的用户、生产者，在真实世界；而软件本身，在数字世界，此种组合以前不曾出现过，其开发生产有以下特点：

2.1 软件开发是一种艺术品创作

艺术品，简单理解是一种超越实用的，承载着美的，吸引人感觉享受的东西。

艺术品，在真实世界是常见的，如字（中国的）、画、中国餐等。艺术家，可以用同样的素材，不同的组合，不同的时差，作出独特的展现。

软件开发，创作方法和真实世界的艺术品类似，使用数字世界同样的素材，不同的组合，不同的集成，要呈现独特的软件作品。每一个软件作品，在数字世界是唯一的，用户通过软件解决真实问题，感觉到美的享受。

2.2 软件开发的过程，验证、控制难 

其他行业产品的创作，其过程基本能在真实世界呈现。比如做中国餐，食材看得见，油盐酱醋看得见，刀案锅铲看得见，水气火烟看得见，切片剁砍看得见，煎炒烹炸看得见，最后的美餐色香味则可以看闻、直接吃。

在大批量的生产中，为了提高效率、降低成本，真实世界的生产过程会细分阶段，每个阶段划分不同的需求、不同角色或岗位、按不同标准来check，如果有偏差，则马上调整改进（腾讯视频上有一个好评前列的记录片《家园》（Home），集中展现了真实世界的过程控制和成果）。

软件开发，其最终成果是运行在数字世界中，开发过程成果也是在数字世界中，而用户、实现人员则在真实世界中。这类跨界的验证、控制，目前还没有像真实世界一样，有很好的标准、执行规范。

2.3 开发成本高/生产成本低

真实世界的艺术品，往往是单品。艺术单品要批量，会受到的资源和质量的限制，而且一旦被批量化，又会摒弃个性化，降格为工艺品。

数字世界中，规则不同，转换成数字艺术单品资源巨大，一旦完成，批量化的质量几乎一样，复制成本对真实世界的资源占用极少（光盘、DVD碟机、电视），如视频BBC系列。

软件开发，则更进一步，依靠开发者通过各种专业软件，出入数字世界，在数字世界中，创造出新的软件。这种软件批量化的质量不打任何折扣（不一样反而有问题），而且复制成本几乎为零（复用原来资源），如制作BBC系列的视频编辑软件。

我曾经有一个简单估算类比：设计开发：生产部署的成本比，建筑类大概是20:80；结构类大概30:70；硬件类大概50:50；软件则为95:5。最极端的是互联网及APP，生产部署是自动或手动网络更新，100%是设计开发成本。

2.4 单个人承担的角色多

一般各专业的开发生产人员，可粗分为这些角色：产品调研、项目管理、需求规格、设计、开发实现、测试、客户验证、批量生产、发货验证、供应商管理（如果有外协）。

在软件的开发中，比较成熟的企业，会分产品、开发、测试三类岗位角色，来承担以上所有职责；初创或极端的企业，开发岗就全部包揽掉。

这种现状，把产品、工程、技术、真实世界/数字世界转换的成熟度和集成要求，都会集成到单独个人身上。而且软件需求的极速增长，这些要求，被要求集成到平民化的从业人员身上。

软件的开发特点，是一个危机（“软件危机”从上世纪七十年代提出之后，一直存在）。从质量角度看，软件开发的控制就是一大挑战（搜索一下就有无数案例）；从发展角度，正是因为限制少，自主创新机会才多。

3 开发模式

3.1 大爆炸（Big Bang）

宇宙大爆炸的奇点理论:数百亿年前，什么都不存在（除了最原始的“道”了），时间没有，空间也没有。终于，洪荒之力憋不住了，嘭的一声，宇宙诞生，从此以后的世界万物，都由能量和粒子排列而成。

大爆炸开发模式，与之类似，一堆资源（人、钱、物）放在一起，嘭的一声，巨大的能量释放（通常很野蛮），产生了优秀的软件产品（或者一堆废品）。

大爆炸模式的优点是：简单。计划、进度安排、正规开发过程、测试验证步骤，几乎没有。所有精力都花在编写代码上。产品需求无需很好理解，最终发布日期可以随便更改（或根本没有），客户和用户聪慧过人。

常规案例是学校学生做实验项目。

3.2 编写边改（Write while Modify）

项目小组在未刻意采用其他开发模式是默认的开发模式，在大爆炸模式基础上进了一步，至少考虑到了产品需求。

边写边改模式，常规只有粗略的想法，接着进行了一些简单设计，然后开始漫长的来回“编写代码、测试、修改缺陷”过程。等到觉得足够了，就发布产品。

由于开头几乎没有计划和文档编制，项目小组得以迅速展现成果。但投资者、项目成员需要有清醒地认识到“无休止的循环往复”。

比较适合原型范例、演示程序、新技术预研。

在初创公司、互联网公司中的正式软件开发中，也能看到身影。

3.3 瀑布（Waterfall）

瀑布模型，基于一种严格规划思想：产品从构思到最终产品，需要经过一系列步骤，每一个步骤结束，需要项目小组组织评审，并决定是否进入下一个步骤。

瀑布模型的优点是简捷、逻辑容易理解。在上游的文档中，已经定义了具体的细节，可以制定精确的计划和进度。该模型的缺点是，每个步骤是线性的，实操中严格依赖上游步骤。

瀑布模型的变种包括，V模型（Verification & Validation）、W模型。

瀑布模型比较适合拥有明确产品定义、步骤划分较独立、时间较短的项目，如组装生产类。

不适合变化迅速的项目，如互联网App。

3.4 增量（Incremental）

增量模型采用渐进式思想：一开始不必详细定义所有细节，从小开始，定义重要功能，实现这些功能，接受反馈，然后进入下一轮的定义重要功能，重复上述过程，直至得到最终产品。

增量模式包含了一点瀑布模式（分析、设计、开发、测试的步骤），一点边写边改模式（增量模式的每一轮），一点大爆炸模式（从外界观察）。

增量模式的优点是，迭代逼近目标，验证早，发现问题早，成本低，实操性特别强。螺旋模式的要点是，每轮迭代的目标、开发、测试、集成，保证螺旋不退化。

增量模型的变种包括，螺旋（Sprial）模型、迭代（Iterative）模型、快速应用模型（Rapid Application Development）、敏捷（Agile）等。

和瀑布模型比，适用的项目刚好互补。

4 小结

这里虽然按照软件开发来列举模型，其实这些模型基本是通用的。一开始个人玩；后来团队采用自然模型；因为太随意，于是出现严格模型；最后，在自然和严格间，采用折中的实用模型。

开发模型的作用，一是保持团队方向不跑偏，二是提高质量和整体效率（不排除影响个别效率）。

学了“情境模型”，我们知道孤立判断哪种模型最优是不合适的。需要根据产品特点、人员准备度、管理水平来选择，通过成果来验证。

一些通用的实用原则是：

• 需求变化越频繁，开发模型越要灵活；

• 模型越新，对人员准备度、自动化要求越高；

• 人员准备度越高，书面文档颗粒度越粗；

• 质量要求越高，测试验证要越早越多越频繁；

软件，是一种真实世界，到数字世界的转化，这些软件自身公开的秘密，你有点感觉了吗？