本篇要回答的问题：只有 50 年历史的软件工程，未来会走向何方？哪些环节已经解决得很好，哪些仍是 “稚嫩” 的短板？软件工程极大成熟的标志是什么？
上一讲谈了版本迭代规划这一高维话题。本讲收束本章，做一次趋势判断——尽管软件工程只有 50 年历史、谈未来条件还不算太充分，但本专栏的宗旨是每个领域都要谈清过去与未来。
软件工程的角色分工
瀑布模型里涉及的角色已经很多：
| 通用工种 | 2B（企业服务）额外增加的工种 |
|---|---|
| 产品经理、架构师、开发工程师、QA 工程师、SRE…… | 售前工程师、交付（实施）工程师、售后工程师、项目经理…… |
关键判断：软件工程的两大自然属性——“快速变化” 是其自然属性，“不确定性” 只能抑制无法消除。但软件工程的问题最终还是由软件来解决。
哪些已解决得好，哪些还稚嫩
按成熟度盘点各环节：
| 环节 | 现状 | 备注 |
|---|---|---|
| 源代码管理 | 已很成熟 | cvs → svn → git，协同方法论约定俗成、被软件 / 云服务固化 |
| 线上服务管理 | 正如火如荼发展 | 不久后大部分人不必再为线上稳定性操心（参见 “服务治理篇”） |
| 需求管理与测试 | 已较好解决 | —— |
| 界面（UI）测试 | 工具链有但普及率极低 | 界面不稳定 → 测试案例编译 / 跑不过 → 信心丧失；自动化测试极度依赖被测接口稳定性 |
| 产品设计 / 架构设计 | 工具普及度小巫见大巫 | 设计类工作是软件工程最大的不确定性来源 |
关键判断：单元测试方法论已极成熟，但仍有不少企业推行受阻；界面测试更高维，需等企业平均工程水平提升后才会形成可推广的最佳实践。
各类分工仍相对孤立，未来走向一体化
| 当前痛点 | 未来趋势 |
|---|---|
| 各分工的最佳实践与软件系统相对孤立 | 形成更一体化的系统，上一道 “工序” 的输出即下一道 “工序” 的输入 |
| 部分工序输出靠人肉传递，甚至无标准化仓库管理（如产品原型、架构设计文档） | 工序间标准化、自动衔接 |
最大短板：设计类工作与人才培养
软件工程最大的不确定性来源于 “设计” 类工作（产品设计 + 架构设计），而它们恰恰最难标准化、最缺人才：
| 原因 | 说明 |
|---|---|
| 设计是小众群体 | 产品经理与架构师培养难度极高，经验难形成传统 “知识点” 传递，合格者远少于程序员 |
| 缺方法论共识 | 以架构师为例，其职责、工作方法论、培养方法论，今天都没有被广泛接受的实践 |
关键判断（与常识相悖但作者深信不疑）：成为产品经理前，首先应该成为架构师——产品经理的培养难度比架构师更高。
软件工程成熟的标志
软件工程极大成熟的标志 = 一体化的软件工程支撑系统 + 高效的人才培养体系（含架构师与产品经理培养体系的极大完善）。到那时，软件工程才成为一门真正成熟的科学。
总结
软件工程还很年轻、日新月异。源代码管理、需求与测试、线上服务管理已较成熟；界面测试、设计类工作的工具化与人才培养仍稚嫩。它的成熟不仅是工程方法论与业务系统的成熟，更需要人才培养体系的成熟——因为不确定性源于设计与创造，人的主观能动性既是优势也意味着不确定性无法彻底消除。我们能做的，只是在大量不确定性中找到尽可能多的确定性。
先把"是什么"回答清楚
| 概念 | 一句话说明 |
|---|---|
| 软件工程两大自然属性 | 快速变化（无法改变）、不确定性（只能抑制不能消除） |
| 工序一体化 | 上一道工序输出即下一道输入，消除人肉传递 |
| 最大短板 | 设计类工作（产品 / 架构设计）的工具化与人才培养 |
| 成熟标志 | 一体化支撑系统 + 高效人才培养体系 |
一句话速记
软件工程的未来不是把代码写得更自动，而是把 “设计” 和 “人” 补齐：让工序输出自动接力成一体化系统，让架构师 / 产品经理有可传承的培养体系——届时它才算一门成熟科学。
几条值得记住的判断
- 已成熟：源代码管理、需求与测试、线上服务；最稚嫩：界面测试与设计类工作。
- 软件工程最大不确定性来源是 “设计”，而设计恰恰最缺方法论共识与人才。
- 作者断言：成为产品经理前应先成为架构师。
思考题
回到你的团队：从产品原型到架构文档再到代码，工序之间是 “自动接力” 还是靠人肉口头传递？如果说软件工程成熟的标志是 “人才培养体系”，你们团队有没有一套可复制的方法，让新架构师 / 产品经理成长起来，而不是只靠 “天赋自悟”？
