没有银弹与可行出路
"没有银弹"这个论断具体是什么?
- 原文论断: 没有任何技术或管理上的进展, 能够独立地许诺十年内使生产率、可靠性或简洁性获得数量级上的进步;
- 逻辑: 数量级提升要求解决根本困难, 而根本困难是概念结构的复杂性, 不是表达方式的笨拙;
- 澄清: 这不是悲观主义--"虽然没有通天大道, 但是路就在脚下";
- 论证边界: 论断以"次要部分占全部工作的比例"为前提, 该比例原则上可测量; 作者认为它已降到一半或以下;
哪些候选技术被评估过,结论如何?
| 候选 | 针对的困难 | 结论 |
|---|---|---|
| Ada 等高级语言 | 表达层面的机器复杂度 | 只是又一次高级语言红利, 最大价值是推动设计培训 |
| 面向对象编程 | 抽象数据类型 + 层次化类型 | 只消除设计表达上的次要困难, 动不了设计的复杂度 |
| 人工智能 / 专家系统 | 知识与推理的复用 | AI-1 定义会漂移, AI-2 的价值是分离应用复杂度与程序; 瓶颈在知识获取 |
| "自动"编程 | 从问题陈述生成程序 | 多数"技术说明"本质上是解法本身, 只适用于参数少、方案库成熟的窄领域 |
| 图形化编程 | 用图形表达设计 | 流程图是差的表达方式, 屏幕太小, 软件本身难可视化 |
| 程序验证 | 在设计级消除 bug | 验证成本极高, 只能覆盖少量程序; 验证的是"满足说明", 而写说明本身最难 |
| 更好的环境 / 工作站 | 工具与算力 | 有价值但回报有限; 一旦编译够快, 主要活动就是思考 |
作者认为真正有希望的方向有哪些?
- 购买而非开发: 最彻底的解决方案是不开发任何软件; 大众软件市场是最深远的开发方向;
- 前提变化: 软硬件成本比变化使"买软件包再定制"取代"定制开发"成为常态;
- 需求精炼与快速原型: 最困难的是决定"搭什么样的系统", 原型让客户能测试一致性和可用性;
- 增量开发: 先让一个可运行(哪怕什么也不做)的系统跑起来, 再逐个功能生长, 而不是一次性搭建;
- 卓越的设计人员: 优秀设计与卓越设计之间不是方法学的差距, 而是人的差距;
作者 20 年后如何修正这一章?
- 保留: 根本/次要的划分仍然关键, 是判断"哪些改进有用"的指南;
- 补充: 复杂度是层次化的, 用更高层构件开发、复用他人成果能避开整层复杂度;
- 承认被误读: 论断不是"对根本困难无计可施", 而是"没有单一的、独立的银弹";
- 面向对象降级: 从"银弹"改称"铜质子弹"--前期投入大、收益在第五个产品之后才显现;