跳到主要内容

编程系统产品的九倍成本

从程序到编程系统产品经过哪两个方向？​

  • 出发点: 程序（Program）, 本身完整, 由作者在自己的平台上运行, 是"车库产出"和衡量单个程序员生产率的标准;
  • 向下（越过水平边界）: 程序 → 编程产品（Programming Product）;
  • 向右（越过垂直边界）: 程序 → 编程系统（Programming System）中的构件单元;
  • 终点: 右下角的编程系统产品（Programming Systems Product）, 成本约等于九倍;
               │  程序 Program   │  编程系统 System
  ─────────────┼────────────────┼──────────────────
  编程产品     │ 程序           │ 编程系统
  （水平边界） │ ×1 成本        │ ×3 成本
  ─────────────┼────────────────┼──────────────────
               │ 编程产品       │ 编程系统产品
               │ ×3 成本        │ ×9 成本

为什么产品化要付出三倍成本？​

  • 定义: 能被任何人运行、测试、修复和扩展的程序;
  • 要求一: 按普遍认可的风格编写, 输入的范围和形式要覆盖所有合理的基本算法;
  • 要求二: 彻底测试, 准备、运行并记录详尽的测试用例库, 覆盖输入边界和范围;
  • 要求三: 完备文档, 使任何人可以加以使用、修复和扩展;
  • 结果: 相同功能的编程产品成本至少是"已测试程序"的三倍;

为什么成为系统构件又要付出三倍成本？​

  • 定义: 在功能上能相互协作的程序集合, 有规范格式, 可交互, 可组装成整个系统;
  • 要求一: 输入输出在语法和语义上与精确定义的接口一致;
  • 要求二: 符合预先定义的资源限制--内存空间、输入输出设备、计算机时间;
  • 要求三: 与其它构件以任何能想象到的组合进行测试;
  • 结果: 组合数随构件数增加, 意外交互产生不易察觉的 bug, 测试非常耗时, 成本至少是三倍, 构件多时更高;

九倍成本对估算和取舍意味着什么？​

  • 车库神话的来源: 用"程序"级别的生产率外推产业团队, 得出 1000 行/年的错觉;
  • 估算含义: 计划、文档、测试、系统集成和培训的时间必须计入, 只估编码再乘系数会得到荒谬结果;
  • 采购含义: 买一个通用构件, 买的是别人已经付过的三倍乃至九倍成本, 常常比自研便宜;
  • 前提: 只有九倍成本的产物才是真正有用的产品, 也才是大多数系统开发的目标;