软件构架：本质任务和附属任务

Frederick P. Brooks, Jr. —《No Silver Bullet: Essence and Accidents of Software Engineering》(1986/1987)，UNC 技术报告 TR86-020。软件工程领域的经典之一（后来 1987 年发表在 IEEE Computer）。

Silver Bullet 银色子弹，民间十分恐惧 Werewolves 狼人，认为银色子弹能消灭它

软件开发（software construction）包含本质任务和附属任务。

本质（essence）任务是构建复杂的概念结构、抽象的软件实体
附属（accident）任务是把概念映射到编程语言/机器上——语法、机器时间、工具链等。
关键论证：过去几十年的大幅提效几乎全来自消除附属障碍（高级语言、分时、统一环境）。但除非当前的附属工作占到全部工作量 9/10 以上，否则把附属工作压缩到零也换不来一个数量级的提升。所以必须转向本质部分的攻克。

文章结构

1. 引言——软件项目的"狼人"比喻，呼唤银弹
2. 本质困难（第 2 节）
   - 2.1 复杂性（首要）——软件实体是状态空间巨大的人造物
   - 2.2 一致性/符合性（conformity）——必须贴合既有机构、接口
   - 2.3 可变性（changeability）——软件被不断要求修改
   - 2.4 不可见性（invisibility）——软件无法被几何化可视化
3. 过往突破解决的是附属困难（第 3 节）——高级语言、分时、统一编程环境
4. 对"银弹"的期望逐个泼冷水（第 4 节）——Ada/高级语言、面向对象编程、人工智能、专家系统、自动编程、图形化编程、程序验证、环境工具、工作站
5. 真正有希望攻击"本质"的方向（第 5 节）
   - 5.1 买 vs 造（用大众市场，别自己重造轮子）
   - 5.2 需求精化 + 快速原型
   - 5.3 增量开发——"培育"软件而非"建造"软件
   - 5.4 培养伟大的概念设计者

QA1 如何快速构建原型 和 精化需求 文中有提到吗？

5.2 需求精化 + 快速原型（p.14–15）

核心观点：

• "建软件最难的一步是精确决定要建什么。" 需求的确立，比任何其他概念性工作都难；做错了对系统的伤害最大，事后最难补救。
• "客户根本不知道自己要什么。" 他不知道要回答哪些问题，也几乎从没在必须达到的细节层面想过问题。连"照我们原来手工流程那样做"这种"简单"答案其实都太简单——没人真的想要完全一样。
• 软件是会动、会跑的东西，其动态行为很难凭空想象，所以必须留出客户与设计者之间大量的迭代作为系统定义的一部分。
• 更强的一句话：在把某些版本真正建出来、试过之前，客户（哪怕配了软件工程师）根本不可能完整、精确、正确地写出需求。

对"快速原型"的具体定义（原文）：

原型是模拟重要接口、执行主要功能的系统，但不受硬件速度/大小/成本约束。它通常跑主流程，不处理异常、不响应非法输入、不干净退出。目的是让被规格化的概念结构"变成真的"，好让客户能测试它的一致性和可用性。

也就是说，原型不是缩小版产品，而是用来把需求"逼出来"的工具——把需求精化和产品开发做成迭代循环。

他还顺带批评了当时"先完整定规格 → 招标 → 建造 → 安装"的软件采购流程，认为这个假设根本错了，这类采购问题必须靠迭代开发+原型/产品的迭代规格才能修好。

5.3 增量开发——"培育软件，而非建造软件"（p.15–16）

这条是上面原型的落地方式：

• 抛弃"建造（building）"隐喻，转向自然界的生长（grown）隐喻——"大脑的秘诀就在于它是长出来的，不是造出来的"。
• 具体做法（引自 Harlan Mills）：先让系统跑起来，哪怕它什么有用的事都不做、只是调用一堆空壳子程序；然后一点点填充，把空壳逐步实现成实际动作、或对下一层空壳的调用。
• 好处：天然支持自顶向下设计、容易回退、便于早期出原型，新功能从已有部分"有机长出"。
• 士气效果被 Brooks 特别强调：只要有一个能跑的（哪怕极简单的）系统，热情就会跳升——图形系统第一次在屏幕上画出个矩形都算。"团队四个月里『长』出的复杂系统，比『造』出来的复杂得多。"

对你有用的落地版

这篇文章 1986 年提的原则，对今天的 ML/视觉研究几乎原样适用：

1. 先跑通最脏但端到端能跑的 pipeline（哪怕模型是随机初始化的、指标一塌糊涂）——对应"make it run, even with dummy subprograms"。这比先写完美数据管线再训模型有效得多。
2. 原型不追完整性：先不处理异常样本、边界情况、脏数据，只跑主流程，用它去暴露"到底要什么"（比如发现某类数据根本没法标注→需求变了）。
3. 需求迭代：你的"需求"就是评测协议、指标定义、数据假设——这些往往在跑过一版之后才会被真正明确，所以要预留反复修改的空间。
4. 一步一个能跑的系统：每加一个模块都保持整体可运行，方便回退和对比消融。

术语表 / Key Terms

• silver bullet — 银弹；传说中能消灭狼人的唯一武器，喻指「一举解决软件危机的单一技术/方法」
• werewolf — 狼人；文中比喻「平时无害、失控后变成怪物」的软件项目
• essence / essential tasks — 本质（任务）；构建复杂概念结构、抽象软件实体——无法被工具消除
• accident / accidental tasks — 附属（任务）；把概念映射到编程语言/机器上的部分（语法、机器时间、工具链）
• conceptual structure — 概念结构；软件作为抽象实体的核心（规格与设计）
• complexity — 复杂性；本质困难之首——状态空间巨大的人造物
• conformity — 符合性；必须贴合既有机构、接口（软件须符合外部既有约定）
• changeability — 可变性；软件被不断要求修改
• invisibility — 不可见性；软件无法被几何化 / 可视化地呈现
• order of magnitude — 数量级；文中指 10 倍提升
• productivity — 生产率
• high-level language — 高级语言
• time-sharing — 分时（系统）
• unified programming environment — 统一编程环境
• rapid prototyping — 快速原型（法）
• requirements refinement — 需求精化
• incremental development — 增量开发
• grow, not build — 「培育」而非「建造」（软件）；文中核心的隐喻转换
• top-down design — 自顶向下设计
• backtracking — 回退、回溯
• off-the-shelf — 现成的、货架上的（商业软件）
• buy versus build — 买 vs 造（的抉择）
• mass market — 大众市场
• great designer / conceptual designer — 伟大的（概念）设计者
• productivity equation — 生产率方程（time = Σ frequencyᵢ × timeᵢ）
• program verification — 程序验证
• expert systems — 专家系统
• object-oriented programming — 面向对象编程