软件工程实践 | 宏观视角·设计文档·代码阅读·发布与版本管理·质量管理·开源与外包·迭代规划·未来展望

章节导言

软件工程只有 50 年的历史。相比动辄跨世纪的自然科学，它是一门极其年轻的学科。正因为实践时间太短，我们对其认知仍然肤浅。但恰恰是这门年轻的学科，却承担着人类有史以来最复杂的创造性工程活动。

软件工程的核心矛盾可以用一句话概括：软件工程本身是不确定的、快速变化的，但软件项目的管理却期望达到确定性。 我们的目标，是在大量的不确定性中找到确定性——这才是软件工程最核心的点。

架构师不是一个纯技术岗位。从软件工程的视角来看，架构师要对软件工程的执行结果负责——包括按时按质迭代发布、敏捷响应需求变更、防范质量风险、降低迭代维护成本。这意味着架构师必须关注团队协同、质量管理、外包决策、版本规划等"非纯技术"领域。

核心问题：

1. 软件工程与传统工程的根本差异是什么？为什么传统管理方法失效？
2. 如何将团队共识精确表达为设计文档？设计文档的核心结构是什么？
3. 阅读别人的代码有哪些方法论？如何从代码中反向还原架构设计？
4. 发布单元与版本管理的核心哲学是什么？容器化为何是终极方案？
5. 软件质量管理为何"反直觉"？单元测试与高频交付的核心价值何在？
6. 什么该自研、什么该外包？开源、云服务、外包的决策框架是什么？
7. 版本迭代规划在不同阶段的战略焦点有何不同？
8. 软件工程的未来走向何方？AI 会替代架构师吗？

一、软件工程的宏观视角

1.1 软件工程的两大本质特征

软件工程与传统工程截然不同，其根本差异体现在两个维度：

其一，不确定性。 大型软件系统中几千甚至几万人参与，却没有两个人的工作是重复的。每个人每天都在写新的代码、做新的工作。软件工程从事的是创造性活动，而创造意味着大量试错——因为我们没有做过。涉及的人力、时间、业务变数，都远超传统工程。

其二，快速变化。 建筑工程完工即结束，极少变更。但软件生产出来只是开始——只要软件还在服务客户，迭代更新就永不停歇，从诞生到消亡，始终在变化。这与传统工程"一锤定音"的模式大相径庭。

这两点导致一个根本性的管理悖论：

1.2 架构师的职责：对工程执行结果负责

架构师的职责远不止"边界划分和模块规格定义"。从根本目标来说，架构师要对软件工程的执行结果负责，具体包括：

这意味着架构师至少有两项关键能力超越了纯技术范畴：

• 用户需求的解读能力：尤其是需求演进的预判能力。关键不在技术，而在心态——心里得装着用户。
• 产品设计的参与能力：产品边界的确立不是纯需求问题，也不是纯技术问题，而是两者合而为一的过程。

深度注记：架构师深度参与产品边界决策是降低后期架构腐化风险的关键。某功能是否做成插件化、API 是否版本化、数据模型是否预留扩展字段——这些既是产品决策，也是架构决策。

1.3 软件工程生命周期

关键认知：软件工程不是一个项目，而是无数个项目。 每个项目只是软件工程的一个里程碑（Milestone）。其生命周期以数年甚至数十年计。

1.4 开发方法论演进：瀑布→敏捷→DevOps

许式伟的核心判断：现代软件工程的实践，本质上是在瀑布模型的基础上增加了迭代闭环。瀑布模型描述了单次迭代的过程，而软件工程的真实形态是无数个瀑布的螺旋上升。

1.5 团队共识管理

在不确定性中寻找确定性，最核心的手段是团队共识管理。架构师的首要工作不是画架构图，而是建立团队共识——只有共识才是可靠的协作基础。

共识的精确性决定了协作的效率。模糊的共识（口头约定、会议纪要）会在执行中产生歧义，导致返工甚至冲突。

许式伟的核心主张：共识必须尽可能精确。最精确的共识是代码级别的接口定义和数据结构规格，而非架构图或会议纪要。

共识管理的反模式：

1. 架构图即共识：架构图不精确，无法作为协作契约
2. 文档写完即弃：过时文档比没有文档更危险——它误导而非帮助
3. 口头约定替代文档：会议上的口头约定，到执行时各人理解不同
4. 过度追求完美文档：文档的价值在于精确，而非篇幅

1.6 确定性注入的工程手段

所有工程实践——版本管理、自动化测试、持续集成、代码审查——本质上都是为系统注入确定性的手段。

Trade-off：确定性 vs 灵活性：

• 过度追求确定性（如过重的流程）会扼杀创造力与响应速度
• 过度追求灵活性（如无约束的变更）会导致系统失控
• 最佳实践：在关键节点（接口契约、发布基线）追求确定性，在实现细节上保留灵活性

二、设计文档

2.1 为什么写设计文档

设计文档是团队共识的核心载体。无论是产品文档还是架构文档，本质都是团队内及团队间协同的共识载体。

许式伟的关键判断：设计是软件工程中的头等大事，我们应该在设计中"多浪费点时间"，这样的"浪费"最终会得到十倍甚至百倍以上的回报。

2.2 设计文档的统一结构

所有设计文档的内容组织逻辑是相通的，无论产品设计还是架构设计，都遵循四段式结构：

核心公式：程序 = 数据结构 + 算法。这是设计文档"实现原理"部分的指导思想——数据结构可以是内存数据结构、外存数据结构、数据库表结构；算法可以是 UML 时序图或伪代码。

2.3 产品设计 vs 架构设计的维度差异

产品经理与架构师是一体两面，对人的能力要求相似，但关注维度不同：

2.4 接口先行，实现随后

在描述交付物规格时，有两个核心关注点：

1. 接口是否足够简单，是否自然体现业务需求
2. 尽可能避免接口变更，接口要向前兼容

对于系统的概要设计：

• 第一关心的是模块关系
• 第二关心的才是各个模块的核心接口（这些接口能把关键 UserStory 串起来）

模块间依赖关系的三种接口类型：

• DOM API：常规功能调用
• Event：事件发送与监听
• Plugin：插件注册

深度注记：以 MVC 为例——View 监听 Model 层的数据变更事件（Event），View 转发用户交互事件给 Controller（Event），Controller 将用户交互事件转为 Model 层的 DOM API 调用。通过接口类型表达模块间依赖关系，比画流程图更有抽象力。

2.5 概要设计 vs 详细设计

2.6 多方案对比决策

当识别出多种实现方案时，决策流程如下：

1. 概要描述各方案的本质差别
2. 多维度对比（易实施性与可维护性、时间复杂度与空间复杂度）
3. 业务倾向性判断：绝大部分业务工程效率优先（易实施+可维护为先）；成本/性能敏感业务性能优先
4. 确定主方案后，判断两方案比较优势是否显著
5. 如果显著，以主方案写一篇文档并完整展开
6. 如果不显著，分别写两篇独立文档——应被鼓励

Trade-off：架构图 vs 接口定义：

• 架构图有助于理解系统分解逻辑，但表达非常粗糙
• 接口定义精确无歧义，但缺乏全局视角
• 最佳实践：架构图辅助理解，接口定义作为正式契约。模块关系图 + 核心接口规格，两者缺一不可

Trade-off：单方案 vs 多方案文档：

• 单方案文档：聚焦，撰写成本低，但可能错过更优解
• 多方案文档：论证充分，但投入大
• 最佳实践：当两方案比较优势不显著时，写两篇独立文档。设计是头等大事，在此"浪费"时间回报百倍

2.7 华仔的架构设计文档模板

华仔提供了一个完整的架构设计文档模板体系，包含两个核心文档：

备选方案模板包含五大部分：

1. 需求介绍：描述需求的背景、目标、范围
2. 需求分析：
   • 5W：Who（利益干系人）、When（使用时间）、What（产出物）、Where（应用场景）、Why（要解决的问题）
   • 1H：关键业务流程（非设计方案，而是关键用例流程）
   • 8C：8 个约束和限制——Performance、Cost、Time、Reliability、Security、Compliance、Technology、Compatibility
3. 复杂度分析：分析需求的复杂度（高可用、高性能、可扩展等），每个约束都应有详细的逻辑推导，避免拍脑袋决策
4. 备选方案：至少 3 个备选方案，每个方案描述关键实现而无须描述具体细节
5. 备选方案评估：360 度环评，内容会根据评估会议的结果进行修改

架构设计模板包含五大部分：

1. 总体方案：从整体上描述方案结构，核心内容是架构图及描述，包括模块或子系统的职责描述、核心流程
2. 架构总览：给出架构图及关键设计点说明

3. 核心流程：消息发送流程、消息读取流程等
4. 详细设计：
   • 高可用设计（消息发送可靠性、消息存储可靠性、消息读取可靠性）
   • 高性能设计
   • 可扩展设计（如果方案不涉及，简单写"无"表示设计者有考虑但不需要设计；完全不写则可能被认为是遗漏）
   • 安全设计
   • 其他设计
   • 部署方案
5. 架构演进规划：分阶段实施——第一期做什么、第二期做什么

2.8 架构图最佳实践：4R 架构定义与常见架构图

华仔提出画架构图的核心指导思想——4R 架构定义：

软件架构指软件系统的顶层（Rank）结构，它定义了系统由哪些角色（Role）组成，角色之间的关系（Relation）和运作规则（Rule）。

画架构图四步骤：

1. 明确 Rank：不要事无巨细地展现大系统的方方面面，明确要阐述的系统所属的级别（L0～L4），只描述该级别的架构信息
2. 画出 Role：从不同角度分解系统，角色对应架构图中的区块、图标和节点
3. 画出 Relation：画出角色之间的关系，对应架构图中的连接线，不同连接线代表不同关系
4. 画出 Rule：挑选核心场景，画出系统角色之间如何协作来完成某项业务功能，对应系统序列图

描述 Role 和 Relation 的架构图称为静态架构图，描述 Rule 的系统序列图称为动态架构图。

4+1 视图的局限：4+1 视图（逻辑视图、处理视图、开发视图、物理视图、场景视图）本身全面规范，但实际应用少，原因有三：

1. 架构复杂度增加——分布式系统下微服务太多，Development view 难以表示
2. 绑定 UML 图——UML 画架构图不美观，表达能力弱
3. 理解困难——逻辑视图、开发视图和处理视图容易混淆

常见架构图类型：

深度注记：华仔强调——目前业界并没有就架构图标准达成共识。TOGAF 的架构基本上到 CTO 级别才能接触，C4 模型的表达能力又不够。华仔整理的架构图类型在华为、UC、阿里和蚂蚁等公司验证过。核心原则：一张图的颜色数量控制在 3 种以内。

三、代码阅读

3.1 阅读代码是架构的反向工程

阅读代码是架构设计的反向过程。架构设计是从需求出发，自上而下地分解与构建系统；而阅读代码是从实现出发，自下而上地还原架构思想。这个过程类似于反编译——不是指令级的反编译，而是需要根据代码反推更高维的设计意图。

编译过程是有损的：大部分软件实体的名字在编译过程中被去除。即使有符号文件，精确还原高级语言代码仍然非常难——它需要模型推理，需要识别出熟悉的"套路"，然后按照套路进行还原。

有产出的学习过程，才是最好的学习方式。 阅读源代码的产出应该是构建这个程序的思路——也就是架构设计。

3.2 阅读代码的四种目标

明确阅读目标是第一步，因为它决定了你能为此付出多大成本：

3.3 系统架构理解流程

工具辅助：

• Go 语言：go doc 可自动生成包的文档
• 多语言通用：doxygen 支持几乎所有主流语言
• example 和 unit test 属于研究对象的使用方（客户），能辅助理解各软件实体的语义

3.4 业务实现机制理解流程

概要设计理清后，根据目标决定后续投入：

• 评估第三方模块：到此告一段落
• 局部 Bug 修复：聚焦 Bug 相关业务流程
• 接手长期维护：梳理关键业务流程

核心方法论回归最基础的公式：程序 = 数据结构 + 算法

1. 先理数据结构：类的成员变量、数据库的表结构，通常都有快速提取的方式。理清楚数据结构，事情就解决了大半
2. 再理算法：各个 UserStory 的业务流程，画出 UML 时序图

深度注记：MongoDB 等弱 schema 数据库，需要通过代码理解 schema；历史 schema 变更可能使最新代码无法反映完整的 schema 演进。这是数据结构理解中的特殊挑战。

3.5 阅读代码的核心原则

原则一：有文档一定先看文档。 如果已经有架构设计文档，坚持自己从零开始反向理解是愚蠢的。但文档和代码很容易脱节，需相互印证。发生冲突时，及时修改文档到与代码一致。

原则二：理解概要设计是首要目标。 概要设计的关注点是：各软件实体的业务范畴，以及它们之间的关系。只有在必要的情况下，才深入研究实现机制。

原则三：代码即文档，阅读代码不可替代。 哪怕团队文档多么完善，阅读代码都是不可或缺的基础能力——代码永远反映真实状态。

原则四：阅读代码时可以顺手改代码，但有原则：

1. 不做大改动：限定单个函数内改动不超过 10 行
2. 语义完全一致：包括所有 corner case（错误码、条件语句边界等）
3. 补全单元测试：不管多自信，有改动就必须补全相关单元测试

Trade-off：自己理解 vs 前任交流：

• 自己从代码推导：成本高，但理解更深入
• 找前任开发者交流：效率高，但依赖对方可用性和表达能力
• 最佳实践：先自行梳理到有一定理解，再找前任交流。提前准备迷惑问题列表，争取一小时左右的交流机会

反模式：

• 坚持从零开始反向推导（已有文档却不看）
• 试图完整理解所有细节（没有明确目标的情况下全面理解是过度投入）
• 阅读代码后不形成文档（下一次接手的人需要重新"反编译"）

四、发布与版本管理

4.1 发布单元：软件工程的分治基础

从软件架构设计可知，软件是分模块开发的。不同模块可能由不同团队开发，甚至有些模块是外部第三方团队开发。这意味着，一个软件工程的生命周期中，包含着很多个彼此完全独立的子软件工程。

发布单元 = 拥有独立迭代周期的软件实体。

发布单元与模块的区别：

发布单元的输出类型：

4.2 只读设计的确定性

一个打好了版本号的发布单元是只读的，不能对其做任何改动。 这句话包含两层含义：

1. 不能修改发布单元自身包含的各模块的代码
2. 不能修改发布单元依赖的外部模块（发布单元）的版本——例如将 opencv 从 v1.0 升级到 v2.0，这也是一次变更，需要修改自己的版本号

只读设计带来巨大的收益，因为版本是一个"基线"，我们对基线的预期是确定性的。

只读思想在软件工程中被广泛运用：

4.3 语义化版本

语义化版本（Semantic Versioning）是行业标准：

MAJOR.MINOR.PATCH[-PRERELEASE][+BUILD]

版本管理策略对比：

4.4 分支策略

GitHub 提供了完善的源代码质量管理闭环：

1. 开发独立性：每个人极低成本建立 feature branch，工作未完成时对其他人不可见
2. 质量检查机制：提交 PR 时可配置自动化检查（unit test / coverage / lint / code review）
3. 开放设计：质量检查过程需求易变，GitHub 做了开放设计——开闭原则的又一次体现
4. 回滚机制：合并后发现 Bug 可 revert PR，主干得到去除该功能的新版本

4.5 容器化是版本管理的终极方案

4.6 灰度发布与回滚策略

灰度发布是降低变更风险的核心手段：

灰度发布典型流程：1% → 5% → 20% → 50% → 100%，每一步都观察关键指标（错误率、延迟、业务指标），指标异常则自动回滚。

回滚能力是底线：当线上出现问题时，优先回滚恢复服务，再择机修复。保证回滚能力是发布系统的底线要求。

4.7 版本兼容性管理

版本兼容的难度在细节——兼容主体功能容易，兼容错误码和低频分支行为才是魔鬼。

Trade-off：兼容 vs 不兼容（改名）：

对于互联网服务（API），放弃兼容意味着放弃用户——不可接受。常见做法：为所有 API 引入版本号（/v2/foo/bar → /v3/foo/bar）。

服务端 API 兼容性的特殊挑战：客户端可以强制升级，但服务端 API 的消费者往往不可控。因此服务端 API 的变更必须遵循更严格的兼容性纪律——接口只增不改不删。

数据库 schema 变更是发布中最棘手的问题之一。标准做法：

1. 双写阶段：新代码同时写入新旧 schema
2. 迁移阶段：将历史数据迁移到新 schema
3. 双读阶段：从新 schema 读取，但保留旧 schema 作为回退
4. 清理阶段：确认稳定后删除旧 schema

每个阶段都是一次独立发布，每次只做一件事。

深度注记：Go 语言早期并没有官方的版本管理手段，导致社区出现很多版本管理方案。直到 go mod 机制终于统一了这一纷争。Go 1.5 引入 vendor 机制试图解决但未成功，Go 1.11 推翻重来引入 module 机制。这说明版本规划不排斥推翻重来，核心痛点必须持续攻坚。

五、软件质量管理

5.1 软件工程质量管理的反直觉之处

软件质量管理横跨整个软件工程完整的生命周期。但软件工程的质量管理思想与传统工程截然不同——甚至往往是反其道而行之。

传统工程中，设计工作占比极少，重复性工作占绝大部分，检查清单（Check List）即可实现质量管理。但软件工程中，设计工作贯穿始终，连编码实现都依赖个体创造力。Check List 完全无法满足软件工程的质量管理需要。

5.2 开发期 vs 维护期：预见性是关键

开发期的时间跨度可能不长，但它基本决定了后期维护期的成本有多高。这意味着软件工程是需要有极强预见性的工程。开发期恰如其分地多投入一分精力，维护期就有十倍甚至百倍以上的回报。

设计工作的质量至关重要。但它在执行上不太有复制性，可复制的只是设计范式和设计思维。我们只能在这种执行的不确定性中找工程上的确定性。

5.3 质量属性

软件质量的维度远不止"有没有 Bug"：

5.4 质量管理的两大支柱

如何在不确定性中找到确定性？两大支柱：

1. 自动化测试——通过可回归的验证注入确定性
2. 持续构建与持续发布——通过高频交付降低变更风险

5.5 单元测试

单元测试是重中之重。 从测试成本两个维度看，单元测试都是最优选择：

推广单元测试的认知障碍：很多公司推不起来单元测试，根因在于认知问题——我们不应把推广单元测试看作让大家多做一件额外的事情，而是规范大家做单元测试的方法。

实际上单元测试大家都会做——很少有人不经验证就直接交付。但验证方式五花八门：

这些方法代价不低，且最大的问题是没有办法固化已知的 Bug，最大程度保留测试案例。

核心认知：测试代码同样是开发成果，理应获得和功能代码同等重要的地位，理应被保留下来。

自动化测试的重要特征：

5.6 测试替身（Test Doubles）

在单元测试中，被测模块的依赖项需要被替换为可控的替身：

5.7 测试金字塔

测试金字塔是测试策略的经典模型：

• 底层：单元测试（数量最多，速度最快，成本最低）
• 中层：集成测试（数量适中，验证模块间协作）
• 顶层：端到端测试（数量最少，速度最慢，成本最高）

核心原则：单元测试覆盖核心路径和边界条件，集成测试验证关键协作链路，端到端测试验证核心业务场景。

5.8 持续集成与持续发布

CI/CD 中的质量管理抓手：

5.9 高频交付优于低频大版本

为什么高频交付更优？

1. 回滚代价低：交付功能越少，因错误回滚的影响面越小。同时发布数十个功能，一个出问题影响整体——不如只回滚出问题的功能，放行其他所有功能
2. 过程熟练度高：交付频率越高，对交付过程的训练越频繁，执行效率越高。交付成为自然习惯后，研发绩效与功能线上表现关联，面向客户价值

核心洞察：发布频率越高，每次发布的风险越低。持续交付的本质不是"更频繁地发布"，而是"让每次发布变得足够安全，从而敢于更频繁地发布"。

5.10 技术债务管理

技术债务是软件工程中不可避免的产物。关键不是避免技术债，而是有意识地管理技术债：

5.11 Go 语言的工程工具链

Go 语言从 1.0 开始就内建了完善的工程工具支持，体现了"工程能力内建"的理念：

• go test：单元测试
• go doc：文档生成
• go vet：静态检查
• go tool pprof：性能分析
• go tool cover：覆盖率检查

这些工具链的完善，大幅降低了推广单元测试和代码质量检查的门槛。

Trade-off：单元测试覆盖率 vs 开发速度：

• 100% 覆盖率：质量最高，但编写和维护成本高
• 0% 覆盖率：速度最快，但质量风险极高
• 最佳实践：核心模块追求高覆盖率（80%+），周边模块适度覆盖。关键路径必须覆盖，边界条件必须覆盖

Trade-off：自动化 vs 人工审查：

• 全自动化：效率高、可回归，但无法判断设计合理性
• 人工审查：能发现设计问题，但效率低、不可回归
• 最佳实践：自动化处理可机械化检查的部分（测试、lint、覆盖率），人工审查聚焦设计合理性和业务正确性

反模式：

• 用 Check List 管理软件质量（软件工程没有大量重复性工作）
• 单元测试是额外负担（正确认知：规范验证方式，而非增加工作量）
• 发布是特殊事件（正确做法：让发布成为日常习惯）

六、开源、云服务与外包管理

6.1 跨组织分工的三种外部依赖形态

一个软件工程的生命周期中，包含着很多个彼此完全独立的子软件工程。这些子软件工程中，绝大多数并非自研——它们可能是开源软件、云服务或外部团队外包的模块。

6.2 开源软件：公司与公司的竞争是生态的竞争

开源软件是公司参与行业竞争的生态战略。公司与公司之间的竞争越来越像国与国之间的竞争，更像两大生态之间的竞争。大量的软件被开源出来，目的是：

• 形成行业标准
• 减少整个行业的无谓重复投入
• 构建以自身为核心的生态圈

开源软件引入与治理流程：

1. 识别需求后，评估是否有成熟的开源方案
2. 评估开源方案：License 合规性（GPL/Apache/MIT）、社区活跃度（commit频率/issue响应）、代码质量（测试/文档/架构）、维护团队稳定性
3. 综合评估通过则引入，否则自研
4. 引入后建立内部 Fork 管理（只做最小化修改）
5. 持续跟进上游更新（定期同步）
6. 深度依赖的开源软件应参与社区贡献（提升影响力）

6.3 云服务：基础能力的社会化

云服务本质上是"基础能力的社会化"。随着公有云越来越成熟，越来越多的基础能力被纳入云服务范畴：

• 存储（对象存储 / 块存储 / 文件存储）
• 数据库（关系型 / NoSQL / 时序 / 图）
• 计算（虚拟机 / 容器 / Serverless）
• AI 能力（NLP / CV / 大模型推理）
• DevOps（CI/CD / 监控 / 日志）

云服务 vs 自建基础设施决策维度：

6.4 外包：软件工程分工的必然形态

不要排斥外包。 很多人对业务外包有天然的排斥心理，这是不理性不客观的。原因有二：

1. 存在即合理：外包市场有几千亿美元的规模，不可能是一个不理性的事物
2. 软件工程分工的必然性：没有人能做完所有事情，总是有一部分需要让别人去做

外包决策框架：

1. 识别功能模块 → 是否核心业务？核心业务必须自研
2. 非核心业务 → 是否有成熟的开源/云服务？有则优先选用
3. 没有成熟方案 → 定制化程度？低则外包给标准化服务商，高则看是否长期需要
4. 短期需求外包给定制化团队（项目制），长期需求组建内部团队（或人月外包）

6.5 核心业务必须自研

所有围绕目标用户群体需求而产生的业务子系统，都应该自研。 原因有二：

1. 目标用户群体是我们商业闭环的价值源泉，围绕他们的所有工作都是核心业务
2. 外包团队不会对我们目标用户群体产生同理心——服务目标用户群体的心态只有我们自己的团队才有

外包管理的关键是接口契约：

• 交付物规格明确：接口定义、行为规格、非功能需求
• 验收标准清晰：单元测试、集成测试、性能指标
• 知识转移机制：避免供应商锁定

供应商管理关键要素：

1. 明确交付物规格（接口契约）
2. 建立验收标准（单元测试/集成测试）
3. 持续质量评估（定期回顾）
4. 知识转移机制（避免供应商锁定）

6.6 典型架构决策案例

• 自研：用户系统、核心业务逻辑、推荐算法
• 云服务：对象存储、CDN、数据库（初期）
• 开源：消息队列、日志收集、监控
• 外包：客服系统、内部管理工具

Trade-off：开源 vs 云服务：

Trade-off：外包 vs 自建团队：

反模式：

• 核心业务外包（外包团队缺乏对目标用户的同理心）
• 对开源软件放任不管（不跟踪安全漏洞、不定期同步上游、内部 Fork 与上游分歧越来越大）
• 过度依赖云服务（云服务故障时业务完全不可用、数据迁移困难、长期成本不可控）

七、版本迭代规划

7.1 版本规划是战略级决策

版本规划不是简单的"功能排序"，而是需要根据业务发展阶段动态调整战略重心。方向正确并不代表能够走到最后，执行路径和方向同等重要。版本规划可以影响一个业务的成败，一个企业的生死存亡。

7.2 Go 语言版本演进：经典案例

Go 1.0 之后语言本身的功能基本非常稳定，只有极少量的变动。这些年 Go 都在变化什么？

1. 性能、性能、性能！ 尤其在 GC 效率这块，持续不断优化。为了它大范围重构实现、完成自举
2. 强化工程能力：各种 Go tool 增加，最突出的是模块版本管理（vendor → modules）
3. 标准库能力增强：context、HTTP 2.0 等，context 是网络编程最佳实践的标准化
4. 业务领域扩展：整体专注服务端，对 Android/iOS/WebAssembly 做经验性支持

7.3 业务不同阶段的版本规划策略

7.4 从0到1阶段：用户使用姿势是第一位

Go 语言的版本规划给出了最好的示范：它首先把焦点放在用户使用姿势的迭代上。凡与此无关的事情，只要达到及格线了就可以先放一放。这也是为什么 Go 1.0 虽然有很多关于 GC 效率的吐槽，但他们安之若素，仍然专注于使用姿势的迭代。

使用姿势 = 产品设计的规格。如果使用姿势错了，后面的一切都是在错误地基上盖高楼。

Go 1.0 发布的兼容性承诺是 Go 语言发展的里程碑：承诺未来版本将保持向后兼容，保证已有代码在新版本下编译和运行的正确性。使用姿势一旦稳定就锁定，新功能只能在旁路演化。

7.5 从1到100阶段：非功能性需求成为战略焦点

一旦语言开始大规模推广，进入扩张阶段，版本迭代的关注点切换到用户看不见的地方——非功能性需求。生产环境中用户最关心的指标，就成了团队最关注的事情，日复一日不断迭代优化。

这是很了不起的战略定力：知道什么情况下，最该做的事情是什么。

7.6 重大冲击需求：谨慎处理，旁路演化

遇到会对产品产生巨大冲击的功能需求（如 Go 的泛型），正确的姿势是：

1. 认真对待：Go 团队非常认真地对待泛型需求
2. 不急于实现：并没有急着在 1.9、1.10 或 1.13 中加入
3. 旁路独立演化：泛型被放到旁路版本独立演化，直到验证成熟才会合并到 1.x
4. 灰度验证：在少量客户上先做灰度

尊重客户的正确姿势是：别折腾他们。

7.7 优先级排序技术

7.8 最小可行产品（MVP）

MVP 的核心思想是用最小的成本验证最大的市场假设。与"从0到1阶段聚焦用户使用姿势"的理念完全一致：

• MVP 不是粗糙的产品，而是精简但完整的产品
• MVP 的目标是验证使用姿势（产品设计规格）是否正确
• 验证成功后进入从1到100阶段，迭代非功能性需求

深度注记：Go 版本管理的演进说明版本规划不排斥推翻重来——vendor 不成功就推翻，module 是更好的方案。核心痛点（版本管理是 Go 1.0 后社区调查排名第一的痛点）必须持续攻坚。这也是"从1到100阶段，工程能力是战略焦点"的体现。

Trade-off：使用姿势 vs 性能：

Trade-off：快速响应 vs 稳定演进：

• 快速响应重大需求：满足客户期望，但可能打乱迭代节奏、引入不兼容变更
• 稳定演进旁路演化：保护既有客户，但短期可能引起社区不满
• 最佳实践：重大冲击需求放旁路独立演化，成熟后再合并。回到从0到1方法论，在少量客户上先做灰度

反模式：

• 技术背景的版本规划者一开始就陷入技术细节泥潭（首先应确定焦点放在哪里）
• 扩张阶段忽视非功能性需求（产品竞争力不足，被竞品超越）
• 急于响应重大冲击需求（引入不兼容变更，折腾所有既有用户）

八、软件工程的未来

8.1 三个演进方向

方向一：设计范式的沉淀。软件工程是高度设计驱动的工程活动，设计范式的沉淀是走向成熟的第一个标志：

关键判断：设计范式的沉淀不是让设计变成机械化的套公式，而是让"套路"成为默认起点，把创造力释放到真正需要创新的地方。类比围棋的定式——不是让对局机械化，而是让棋手不必在每一个局部重新发明。

方向二：工程手段的确定性提升。从版本管理（go mod）到质量管理（单元测试、CI/CD、灰度发布），到共识管理（接口定义、代码即文档），到容器化（镜像级别确定性），工程手段的确定性提升贯穿了软件工程的全过程。

方向三：基础能力的云化。IaaS 层已完全云化，PaaS 层正在进行，SaaS 层在进行中，AI 能力层刚起步。云化深化不是全盘云化——核心业务逻辑和合规敏感数据始终需要自研和私有化。

8.2 AI 对软件工程的影响

AI 在软件工程中的影响谱系：

AI 辅助不会替代架构师，但会改变架构师的工作：

• 编码层面：大幅提升编码效率，但需要人类审查
• 设计层面：辅助方案探索，但无法替代战略判断
• 质量层面：自动化测试生成，但覆盖率策略需人类定义

架构师的核心竞争力不是写代码的速度，而是对业务方向的判断力、对权衡取舍的决策力、对团队协同的影响力——这些能力在 AI 时代反而更加重要。

8.3 软件工程的成熟标志

当设计范式足够丰富、工程手段足够确定、基础能力足够标准化时，软件工程将从"手艺"真正走向"工程"。但这条路还很长。

8.4 新兴趋势

8.5 核心矛盾不会消失

无论技术如何进步，软件工程的核心矛盾——不确定性 vs 确定性——不会消失。AI 和云化是缓解手段，不是终极解决方案。忽视这一本质会导致：

• 过度依赖工具，丧失架构判断力
• 过度追求自动化，忽视人为审查的价值
• 过度追求标准化，扼杀创新

深度注记：严谨并非创新的对立面，而是创新的重要基础。每个人都有灵光乍现的时刻，但是唯有那些拥有严谨的科学态度的人才能抓住它，把它变成现实。这句话，是理解软件工程未来的钥匙。

总结

全篇知识体系总结表

软件工程六大核心原则

高效团队 vs 低效团队

协同的科学是团队效率的根因——团队与团队的效率差距可达百倍以上，根源不在技术，而在共识管理、知识传承、默契程度。

思考题

1. 如果你接手一个没有文档的遗留系统，第一步会做什么？如何平衡"理解系统"和"交付需求"的时间分配？
2. 在你的项目中，团队共识主要靠什么载体？口头约定、文档、还是接口定义？共识的精确度够吗？
3. 为什么"发布频率越高，单次风险越低"这个结论看似反直觉？你们团队的发布频率是多少？有哪些瓶颈阻止了更高频的发布？
4. 一个模块从"自研"转为"云服务"依赖，或者从"云服务"转回"自研"，分别需要考虑哪些因素？
5. Go 1.0 发布时 GC 性能被广泛吐槽，但团队安之若素继续迭代使用姿势。如果换作你的项目，你能承受这种战略定力吗？
6. AI 生成代码不经审查直接使用，与"阅读代码可以顺手改代码"的原则是否矛盾？如何平衡 AI 辅助效率与质量保障？

关联阅读

• 68讲：软件工程的宏观视角（核心矛盾与架构师职责）
• 69讲：团队的共识管理（共识五层次与契约即共识）
• 70讲：怎么写设计文档（四要素与多方案对比）
• 71讲：如何阅读别人的代码（架构反向工程）
• 72讲：发布单元与版本管理（只读设计与容器化）
• 73讲：软件质量管理（单元测试、CI/CD、高频交付）
• 74讲：开源、云服务与外包管理（核心自研与接口契约）
• 75讲：软件版本迭代的规划（从0到1用姿势、从1到100磨性能）
• 76讲：软件工程的未来（范式沉淀、工程确定性、云化）
• 77讲：软件工程篇回顾与总结（六大核心原则与协同科学）
• 49讲：发布、升级与版本管理（灰度发布与回滚策略）
• 50讲：架构实战：架构设计文档模板（备选方案模板与架构设计模板）
• 51讲：如何画出优秀的软件系统架构图（4R架构定义与常见架构图类型）

延伸视角

从系统工程看软件工程：软件工程的"不确定性 vs 确定性"矛盾，本质上是复杂适应系统的特征——系统的行为不能从组成部分的行为简单推导。这意味着传统的还原论方法（分而治之）在软件工程中必须辅以整体论视角——模块拆分后，必须关注模块间的协作语义（接口契约）。

从认知科学看设计文档：设计文档本质上是团队共享心智模型（Shared Mental Model）的外化。认知科学研究表明，共享心智模型的精确度直接影响团队绩效。这就是为什么"精确的接口定义远胜冗长的文字描述"——前者减少了认知加工的模糊性。

从经济学看"设计是头等大事"：开发期投入1分、维护期回报百倍，这不是线性关系而是复利效应——良好的设计让每次迭代都站在坚实的基础上，而糟糕的设计让每次迭代都在偿还技术债。技术债的利息是复利计算的，这是很多团队"越做越慢"的根本原因。

从组织理论看"核心自研"：核心业务必须自研，不仅是技术问题，更是组织能力问题。核心业务的知识积累是组织的动态能力（Dynamic Capability），它决定了组织在快速变化环境中的适应能力。将核心业务外包，本质上是将动态能力外包——这在战略上是不可持续的。

从演化论看版本迭代：Go 语言的版本演进完美诠释了"渐进式演化"——每一代都在上一代的基础上做微小但方向明确的改进。泛型的旁路演化策略，类似于生物学中的"分支演化"——新的能力在旁系中独立演化，待成熟后再与主干合并。这种策略既保证了主干的稳定性，又不妨碍创新探索。