本篇要回答的问题：软件工程到底是一门怎样的学科？它与传统工程有何根本不同，架构师在这个工程中真正的职责又是什么？
上一讲收束了第五章"架构思维篇"。本讲正式进入第六章"软件工程篇"，从宏观视角重新审视软件工程。核心命题：软件工程是一门年轻、充满不确定性的学科，而架构师的职责正是从软件工程出发——在大量不确定性中找到确定性。
软件工程：一门年轻而矛盾的学科
软件工程只有约 50 年历史（C 语言 1970 年诞生，Fortran 1954 年但代码量小谈不上工程），实践太少，认知还很肤浅。它与建筑工程的两大根本区别：
| 维度 | 软件工程 | 传统建筑工程 |
|---|---|---|
| 不确定性 | 几千上万人没有两人工作重复，从事创造性工作，大量试错 | 工作多可重复、确定性高 |
| 快速变化 | 软件生产出来只是开始，只要还服务客户就持续迭代 | 完工即结束，之后很少剧变 |
关键判断（软件工程的核心矛盾）：管理学的目的之一是抑制不确定性、产生确定性（确定工期、成本）；但软件工程本身是快速变化、不确定的。在大量不确定性中找到确定性，这就是软件工程最核心的点。
架构师的职责
软件工程全过程（瀑布模型表达）：需求与历史缺陷 → 产品设计 → 架构设计 → 编码与测试 → 产品发布 → 线上服务维护；贯穿始终的还有不变的团队分工与协同、不变的质量管理。
洞见：这个过程不是只发生一遍，而是生命周期内反复迭代。软件工程不是一个项目，而是无数个项目，每个项目只是它的一个里程碑（Milestone）。光靠把控工程师水平、靠他们自觉远远不够，需要一个能掌控全局的架构师团队来规划引导系统演变。
架构师要对软件工程的执行结果负责：按时按质迭代发布、敏捷响应需求变更、防范质量风险、降低迭代维护成本。所以架构师是技术岗，干的事却不那么纯技术。
架构师工作的内容范围（由近及远）：
| 范畴 | 具体内容 | 性质 |
|---|---|---|
| 用户需求解读 | 提升需求分析与演进预判能力 | 无关技术，关键是心态、心里装着用户 |
| 产品设计 | 产品边界确立，架构师深度参与 | 开放性设计涉及技术方案，是需求与技术合一的过程 |
| 团队分工与协同 | 目标共识、做事默契、各类规范制定 | 工程管理范畴，但与架构师密不可分 |
| 软件质量管理 | 版本发布、质量保障过程体系 | 同上 |
| 人力资源规划 | 什么外包给谁、版本计划/功能优先级 | 更宏观的工程管理 |
这些看似不是架构师"本职工作"，但若认同架构师要"对软件工程的执行结果负责"，就能理解为何必须关注它们。
总结
软件工程是一门只有 50 年、充满不确定性与快速变化的年轻学科，其核心矛盾是"在不确定性中找确定性"。架构师的根本职责不止于划边界、定规格，而是对整个软件工程的执行结果负责——因此需求解读、产品设计、团队协同、质量管理乃至人力规划都进入了架构师的视野。本章将精选与架构师工作密切的工程话题展开。
先把"是什么"回答清楚
| 概念 | 一句话说明 |
|---|---|
| 软件工程 | 约 50 年历史、不确定+快速变化的年轻学科 |
| 核心矛盾 | 管理要确定性，软件却不确定——要在不确定中找确定 |
| 里程碑 | 软件工程是无数个项目，每个项目只是一个 Milestone |
| 架构师职责 | 对软件工程的执行结果负责，而非只划边界定规格 |
一句话速记
软件工程年轻、不确定、永远在迭代；架构师的真正职责是"对工程执行结果负责"，所以他要在大量不确定性中找确定性——需求、产品、协同、质量、人力都得管。
几条值得记住的判断
- 软件生产出来只是开始，与"完工即结束"的建筑工程根本不同。
- 软件工程不是一个项目，是无数个项目，每个只是里程碑。
- 架构师是技术岗，但干的事不纯技术——产品边界是需求与技术合一。
思考题
如果"架构师要对软件工程的执行结果负责"，回看你最近一次延期或质量事故：根因是纯技术问题，还是需求理解、团队共识、质量过程这些"非纯技术"环节出了问题？作为架构师，你本该在哪一环更早介入？
