字数 13887，阅读大约需 70 分钟

第21讲：给"智慧邻里"画"施工图"（软件工程与架构）

【老孙开篇寄语】

同学们，欢迎来到“决胜篇”的第三个模块——工程篇。

在过去的“奠基篇”和“运筹篇”中，我们像一位“战略家”和“城市规划师”，为“智慧邻里”这个宏大的项目，规划了“做什么”（战略目标）和“为什么做”（商业价值）。

从今天开始，我们的角色将要发生一次“华丽的变身”。我们要从“规划师”，转变为“总建筑师”和“总工程师”。我们要开始，探讨一个更“具体”、更“落地”的问题——这个叫“智慧邻里”的软件系统，到底，应该怎么“造”出来？

“工程篇”，就是我们的“建造手册”。它将带领我们，深入一个软件系统的“内部”，去理解它的“骨架”（架构）、它的“蓝图”（UML）、它的“血脉”（数据），以及它的“免疫系统”（安全）。

这一讲，是“工程篇”的开篇之作。我们将要为“智慧邻里”这个项目，画出第一张，也是最重要的一张“施工总图”——软件架构图。

我们将探讨一个软件是如何从一团“混沌”的需求，演变为一个“结构清晰、层次分明”的工程产物的。我们将学习不同的“架构风格”（比如，是盖一个“独栋别墅”，还是建一座“乐高城市”），分别适用于什么样的场景，又会给我们的项目，带来怎样的“命运”。

同时，我还会为你们引入两个“神级”的软件思想定律——“《大教堂与集市》”和“康威定律”。它们，将帮助你，从“哲学”和“社会学”的高度，去理解“软件开发，为何如此之难”。

准备好了吗？戴上我们的“安全帽”，拿起“图纸”，开始我们“总工程师”的旅程！

第一章：“两种创世神话”——《大教堂与集市》的启示

在深入探讨“软件架构”这个技术性话题之前，我们有必要先来聊一聊“软件开发”的两种，截然不同的“世界观”或“哲学”。这源于IT界的“圣经”之一——由**埃里克·雷蒙（Eric S. Raymond）所著的《大教堂与集市》。

这篇文章，对比了两种，看似“天差地别”的软件开发模式。

1.1 大教堂模式 (The Cathedral Model)

• • 核心思想： “精心规划，一次成型”。
• • 运作模式：
• • 软件的开发，就像“建造一座宏伟的中世纪大教堂”。
• • 有一小群“顶级的、与世隔绝的”建筑大师（核心开发者），他们在项目开始时，就构思好了“每一个细节”，画出了“完美的、最终的”蓝图。
• • 然后，他们在一个“封闭的、安静的”环境中，花费数年时间，精雕细琢。
• • 直到这座大教堂“完美地”竣工的那一天，它，才会被“轰动地”，向世人，开放。
• • 在需求“极其稳定、清晰”的领域（比如，造火箭、盖大桥），这种模式，非常有效。
• • 管理上，非常“清晰、可控”。
• • 对“变化”的容忍度，极低。 一旦在“施工”过程中，发现“图纸”有问题，或者“甲方”的需求变了，那么整个“大教堂”，可能就要“推倒重来”，代价是“灾难性”的。

1.2 集市模式 (The Bazaar Model)

• • 核心思想： “快速发布，持续迭代，众人拾柴火焰高”。
• • 运作模式：
• • 软件的开发，就像“在一个嘈杂、混乱、但充满活力的集市中，搭建一个摊位”。
• • 你不需要一个“完美的”初始计划。你只需要先用“最快的速度”，搭一个“简陋的、但能用”的草棚（MVP - 最小可行产品），然后，就立刻“开门营业”。
• • 接下来你一边“听取着来来往往的顾客（用户）的抱怨和建议”，一边“观察着隔壁摊位（竞争对手）的新花样”，一边“不断地、快速地”，对你的草棚，进行“修补、改造、和扩建”。
• • 你甚至会允许“热心的顾客”（开源社区的贡献者），来帮你一起“添砖加瓦”。
• • 最终，这个“简陋的草棚”，在“持续的、混乱的、但充满生命力的”迭代中，令人惊讶地，演变成了一座“功能强大、深受用户喜爱”的“超级市场”。
• • 对“变化”的适应性，极强。 它天生就是为“拥抱变化”而生的。
• • 能够通过“快速的反馈循环”，持续地修正自己的方向，避免“闭门造车”。
• • 对“架构的远见”和“社区的治理”，要求极高。否则，很容易，演变成一个“打满补丁、混乱不堪”的“大泥球（Big Ball of Mud）”。

【老孙划重点】

“大教堂”与“集市”，这两种模式，没有“绝对的优劣”，只有“适不适合”。

• • 对于“需求稳定、目标明确、技术成熟”的项目（比如，为国家税务总局，开发一个“报税软件”），“大教堂”模式，可能，更稳妥。
• • 而对于“需求模糊、市场多变、技术创新”的项目（比如，我们这个“智慧邻里”APP，我们一开始，并不知道业主，到底喜欢什么功能），“集市”模式，无疑，是更“明智”的选择。
  理解这两种“哲学”，将直接，影响我们，为“智慧邻ri”项目，选择什么样的“软件开发生命周期模型（SDLC）”和“软件架构”。

第二章：“康威定律”的魔咒——你的组织架构，正在设计你的软件

在选择具体的“架构”之前，我们还必须，了解一个，由计算机科学家**梅尔文·康威（Melvin Conway）**在1968年，提出的，如同“魔咒”一般的定律。

• • 康威定律（Conway's Law）：

  “任何一个，设计系统的组织，最终，所交付的设计，其结构，都与该组织的‘沟通结构’，同构。”
  (Organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations.)

• • “人话”翻译：
• • 你公司的“组织架构图”，就是你“软件的架构图”。
• • 如果，你的公司，有“前端部、后端部、测试部”这三个“壁垒森严”的部门，那么，你最终，做出来的软件，也必然，是“前端、后端、测试”这三个“清晰分离”的“大块”。
• • 如果，你的公司，分成了“用户中心事业部、订单中心事业部、支付中心事业部”，那么，你最终，做出来的软件，也极有可能，是“用户微服务、订单微服务、支付微服务”。
• • 场景一：如果我们（美好家园集团）是一个“强职能型”的公司。
• • 我们的组织，分成了“开发部、测试部、运维部”。这三个部门之间，沟通成本很高，需要层层汇报。
• • 那么，如果我们，强行，要采用“微服务架构”，会发生什么？
• • 灾难！ 一个简单的“修改密码”功能，可能，需要“用户微服务”和“认证微服务”联动。这意味着，开发这个功能的程序员，需要，不断地，和另一个团队，进行“跨部门沟通”。这种“高频的跨团队沟通”，与公司“壁垒森严的沟通结构”，是“根本性矛盾”的。
• • 最终的结果，就是“无休止的会议、扯皮、和等待”。
• • 我们应该，先“逆康威定律（Inverse Conway Maneuver）”而行。
• • 我们应该，先对“组织”，进行“改造”。
• • 我们应该，打破“职能部门”的壁垒，成立一个个“小而美的、跨职能的、全功能的”特性团队（Feature Team）。比如，成立一个“用户与认证团队”，这个团队里，既有前端，又有后端，又有测试。他们，可以“闭环地、独立地”，完成所有与“用户和认证”相关的功能。
• • 先，让“组织”变成“微服务”的形状；然后，你做出来的“软件”，自然，就成了“微服务”。

【本章小结】
“康威定律”，是项目管理中，一个“社会学”层面的“客观规律”。它深刻地提醒我们：

1. 1. 软件架构，从来，都不是一个“纯粹的技术决策”。它，是一个“社会技术性（Socio-technical）”决策。
2. 2. 当你，在选择一个“理想”的架构时，你必须，先看一看，你公司“现实”的“组织结构”和“沟通文化”。
3. 3. 如果你想“改变”你的软件架构，你往往，需要先去“推动”，你组织的“变革”。这，正是“高级”项目经理，价值的体现。

第三章：软件工程的“生命周期”——从“瀑布”到“螺旋”

好了，在完成了“哲学”与“社会学”的“热身”之后，我们正式进入“软件工程（Software Engineering）”的核心。

“软件工程”，这个词听起来很高大上。但它的本质，就是用“工程化的思想、方法、和工具”，去对抗软件开发这个“天生混乱的、充满创造性的、难以驾驭的”野兽。它的核心，就是为这头“野兽”的活动，引入“秩序”和“纪律”。

而“软件开发生命周期模型（SDLC, Software Development Life Cycle Model）”，就是我们，为整个项目，选择的“总体的、宏观的‘建造流程’”。

【老孙类比：国宴的“总菜谱”】