FOSA丨02丨架构思维

本系列文章通过逐章回答《Fundamentals of Software Architecture》（下文简称 FOSA）一书中的课后思考题，来深入理解书中的核心概念和理论，从而提升我们的软件架构设计能力。本篇为第二章内容。

本章的课后题是：

Describe the traditional approach of architecture versus development and explain why that approach no longer works.

描述传统意义上的架构与开发的方法，并解释为什么这种方法不再适用。
List the three levels of knowledge in the knowledge triangle and provide an example of each.

列出知识三角中的三个层次，并为每个层次提供一个示例。
Why is it more important for an architect to focus on technical breadth rather than technical depth?

为什么对于一位架构师而言，注重技术的广度而非深度会显得更为重要呢？
What are some of the ways of maintaining your technical depth and remaining hands-on as an architect?

作为架构师，有哪些方法可以保持技术深度并保持动手能力呢？

1. 架构与开发方法

在传统方法中，架构师与开发人员的职责是分离的，如下图所示：

架构师的职责：

分析业务逻辑，以提取和定义架构特征
选择适合问题领域的架构模式和风格
创建系统的构建块 —— 组件

开发者的职责：

根据架构师交付的产出，创建类图
构建用户界面
开发和测试源代码

这种传统方法的问题在于它是一种单向的"移交"模式。架构师在设计完成后将产物移交给开发团队，但架构师与开发人员之间存在物理和虚拟的障碍。这种方法不再适用的原因主要有以下几点：

信息丢失和脱节：架构师的决策有时无法有效传达给开发团队，而开发团队在实现过程中对架构产生的改变也鲜有反馈给架构师。
缺乏协作与同步：唯一不变的就是变，业务是不断发展的，系统架构也是不断演进和迭代的。这种单向模式导致双方缺乏紧密、双向的合作，无法及时响应业务和技术变化，导致架构变得脆弱且难以维护。

更适合现代软件开发的方法应如下图所示：

在这种双向交互的方式中，架构师不再仅仅是交付设计产出，而是在整个软件生命周期中，不断对开发团队进行领导和指导，开发团队在实现过程也，也不断将遇到的问题和改变返回给架构师时，双方紧密合作、互通有无、共同前进。

2. 知识三角

第一层 (底层)：你知道你知道的 (Stuff you know you know) 这是你知识体系的基石，是你明确掌握、能够熟练运用的技能和知识。它们是你的"舒适区"和核心竞争力。比如掌握编程语言（Go/Rust）的基本语法和常见框架。

第二层 (中层)：你知道你不知道的 (Stuff you know you don't know) 这是你已经意识到但尚未掌握的领域。你可能听说过某个技术、某个概念，知道它的存在和价值，但还没有系统学习或实践过。这是你明确的学习目标和成长方向。比如编程语言（Go/Rust）的编译原理和编译期优化技术。

第三层 (顶层)：你不知道你不知道的 (Stuff you don't know you don't know) 这是你的认知盲区。你甚至不知道这些知识、技术或方法论的存在。它们往往是突破瓶颈、实现认知跃迁的关键，也是最大的风险和机遇所在。一个人的成长，很大程度上就是不断将第三层的 "未知未知"转化为第二层的"已知未知"的过程。比如 AI 领域中的各种新兴技术。

3. 广度还是深度

对于架构师而言，广度比深度要更重要，原因如下：

架构师的职责不是"做"，而是"选择怎么做"。只有当架构师拥有广泛的知识宽度时，能在不同的业务场景中，通过权衡对比，选择出最适合当前业务的架构模式。
每个人的时间和精力是有限的，我们不可能同时精通所有的技术，所以架构师必须在广度和深度之间有所侧重。为了避免"过时专业知识"，架构师需要保持学习最新前沿技术，试图在多个领域保持深度会导致精力耗尽，只能牺牲部分深度以换取更大的广度。
软件架构中一切都是"权衡"。只知道一种解决方案的架构师是做不出权衡的，只有当知道多种解决方案，并清楚其中的优劣，才能在充满各种限制的现实场景中做出"最不坏"的架构设计。

在笔者看来，为了后期可以更快、更扎实的扩展我们的广度，前期的"深度探索"尤为重要。拥有一个深度的知识领域，就像在浩瀚的知识海洋中打下了一个坚实的"锚"。当你学习新知识时，可以把它关联到你的“锚点”上，而不是让它漂浮在空中。正所谓：一通百通。

如果你深度研究过 Go 的 GMP 调度模型、goroutine 的实现、channel 的底层结构，你不仅仅是学会了 Go 的并发。你真正理解了用户态线程、M:N 调度、CSP (Communicating Sequential Processes) 模型 等核心概念。当你再去学习 Rust 的 async/await 和 tokio 时，你会发现虽然语法和所有权规则完全不同，但其背后的异步运行时、任务调度、Future/Executor 模型 等思想，都与你已有的知识体系遥相呼应。你的学习过程不再是死记硬背，而是比较、关联和迁移，效率极高。

所以，一个更完整、更理想的技术人员成长路径应该是：

职业前期 (深耕期)： 深度优先，广度为辅。 选择一个你感兴趣且有前景的主航道（如 Go/Rust 后端开发），投入 80% 的精力向下猛扎，直到成为该领域的专家。用 20% 的精力保持对周边领域的关注。这个阶段的目标是 "立足"。
职业中期 (拓展期)： 深度与广度并重。 在你的根据地已经非常扎实之后，开始有意识地、系统性地拓展你的知识广度，将深耕期遇到的问题和知识点串联起来，形成体系。从 "I 型人才" 向 "T 型人才" 转变。这个阶段的目标是 "连接"。
职业后期 (整合期)： 广度优先，深度为基。 当你需要承担架构师、技术负责人等角色时，你的主要价值来自于广阔的视野和权衡决策能力。你过往的深度积累，则为你的决策提供了坚实的支撑和深刻的洞察力。这个阶段的目标是 "引领"。

4. 维持动手能力

很多架构师与开发团队的协议日益疏远，很大程度源于架构师脱离一线开发环境太久了，以下是一些简单且有效保持技术深度和动手能力的方法：

避免"瓶颈陷阱（bottleneck trap）"并委派核心代码：架构师不应独自承担关键路径或框架代码的开发，因为这会使其成为团队的瓶颈。应将这些核心代码委派给开发团队。架构师可以专注于编码一到三个迭代后的业务功能（例如，一个服务或一个屏幕），从而既能获得实践经验，又能让开发团队拥有核心代码的所有权，并更好地理解他们在开发过程中可能遇到的问题。
持续做概念验证（POCs）：POC 不仅要求架构师编写代码，还能通过实践验证架构决策。在这个过程中，架构师需要严格要求自己产出高质量的代码，因为开发团队后续的工作，很大程度会在 POC 的基础上进行扩展。
处理技术债务：通常这些任务优先级较低，即使未能在一个迭代内完成，也不会对项目造成严重影响。这能让架构师获得实践编码经验，同时解放开发团队去处理关键功能用户故事。
参与修复非紧急漏洞：处理 BUG 能够帮助架构师识别代码库乃至架构中的问题和弱点。
构建效率提升工具：开发一些提升效率的小工具，一方面可以帮助开发团队更高效率地开展工作，另一方面也可以有效维持架构师的动手能力。
编写适应性函数（Fitness Functions）：辅助编写单元测试、集成测试等自动化测试，一来能帮助架构师维持动手能力，二来能帮助架构师更深入理解项目细节，三来可以提高项目架构的健壮性。
参与代码评审（Code Review）：代码评审能让架构师保持对代码库的参与度，同时确保架构合规性，并发现团队中的指导和辅导机会。