软件架构学习是一个看似简单实则复杂的命题。市面上充斥着大量关于设计模式的书籍和原则，但真正能够指导实践的方法论却凤毛麟角。matklad（Aleksey Kladov）作为 rust-analyzer 的核心贡献者，其博客上的一篇回复邮件的文章，为我们提供了一个独特的视角：如何从科研代码编写者成长为能够驾驭复杂系统的软件架构师。
实践优先：软件设计是干出来的
matklad 的核心观点掷地有声：软件设计最好通过实践来学习。他在职业生涯早期加入了 JetBrains 的生物信息学实验室，这段经历让他深刻理解了 “科学代码” 现象的本质。他坦承，尽管在大学期间修读过正式的 “设计” 课程，甚至在课程项目中担任过 “架构师” 角色，但那些经历不过是 “过家家” 式的模拟训练。真正让他学会做事的，是随后在 IntelliJ Rust 项目中的实战锻炼 —— 这个项目将他推向了软件领导的岗位，让架构设计成为他必须面对的真实问题。
这一观察揭示了一个重要的学习悖论：软件架构知识无法仅通过读书获得，必须在真实项目的压力下逐步积累。matklad 也承认自己在 IntelliJ Rust 项目中确实犯过一些错误，但好在没有造成太大的灾难，从中获得了宝贵的教训。这个故事给我们的启示是：不要害怕犯错，因为软件工程足够简单，好奇心足以引导人们从第一性原理出发找到正确的方向。
Conway 定律：被忽视的架构真相
matklad 提出的第二个元观察更为犀利：Conway 定律在软件架构中扮演着关键角色。这条定律指出，软件系统的结构往往反映产生它的组织结构。正如软件工程师 neugierig 所言：“我们谈论编程时，似乎主要是在谈论写代码，但实际上代码最终变得不如架构重要，而架构又不如社会问题重要。” 这一论述将软件架构学习从纯技术层面提升到了社会学和组织行为学的高度。
在 matklad 看来，科研代码与工业代码之间的差异，并不在于软件构建知识的多少，而在于激励机制的差异。一个典型场景是 “博士需要在三个月内发表论文”—— 这种时间压力从根本上塑造了代码的质量和架构选择。这解释了为什么许多科研代码往往是 “一次性” 的：它们的设计目标就是解决眼前的问题，而非构建可持续演进的系统。类似的时间压力同样存在于工业软件项目中 —— 永远没有足够的时间把事情做完美，只能在约束条件下尽力而为。
针对这一现实，matklad 提出了两条应对策略。第一是把握机会设计或影响项目的激励机制。这种机会虽然稀少，但影响巨大。TigerBeetle 项目的 TIGER_STYLE 规范之所以有效，关键并不在于规则本身，而在于使其成为良好选择的社会背景。第二是加速经历 Kübler-Ross 五阶段模型，最终达到接受状态。既然激励机制几乎永远不是你想要的那样，就必须学会适应它。rust-analyzer 项目就是这种适应思维的典型体现。
架构设计的社交工程学
matklad 以 rust-analyzer 为例，详细阐述了如何将社会因素纳入架构设计。这个项目同时具有两个特点：深度上，它是一个编译器；广度上，它需要大量针对不同目的的特殊功能。这两个特点对应了两种截然不同的贡献者类型：深度工作吸引少数专注的精英贡献者，而广度功能则适合 “周末战士”—— 那些学习 Rust、缺乏持续参与能力但能抽出时间解决自己痛点的人。
为了吸引高质量贡献者，matklad 坚持 rust-analyzer 不需要编译 rustc、在稳定版 Rust 上构建、无 C 依赖、整个测试套件秒级完成等设计原则。这些看似技术性的决策，实际上是在为特定的社会目标服务 —— 让贡献者能够专注于借检查器的核心工作，而无需被复杂的构建系统分散注意力。为了吸引周末战士，rust-analyzer 的内部架构被分割为多个独立功能，每个功能在运行时由 catch_unwind 保护。这种设计的精髓在于明确表示：不需要对质量过于苛求，进之路可行就行。如果代码崩溃是可以接受的，只要质量隔离在功能范围内、运行时对用户不可见即可。
然而，matklad 也警告了适应而非改变激励结构的风险：未来充满不确定性，往往以最不方便的方式发生。rust-analyzer 最初只是想避免并行编译器的需求并验证更好的 LSP 架构，最终却成为另一个编译器。这说明即使在核心层面保持实验性，也可能面临意想不到的后果。
代码阅读的方法论
对于渴望学习软件架构的开发者，matklad 推荐了一系列具体资源。Gary Bernhardt 的《边界》演讲是他永恒的最爱 —— 不仅包含扎实的具体建议，更促成了他对这一主题的元认知反思。matklad 自己的《如何测试》一文则阐明了他希望早点理解的东西：测试的重要性不难理解，但识别大多数被广泛引用的测试建议实际上是 “shamanistic snake-oil” 需要漫长的时间。∅MQ 指南以及 Pieter Hintjens 的著作向他引入了 Conway 定律的思维方式。Jamii 的《编码十年反思》极其具有元认知性质，是 matklad 链接页面中的第一篇。Ted Kaminski 的博客则提供了最接近软件开发生命周期统一理论的内容。
除了推荐资源，matklad 还给出了一个令人遗憾的观察：他没有找到一本能够涵盖所有真理的书籍。他怀疑这类书籍可能只存在于博尔赫斯的寓言中，因为实践似乎是其中不可或缺的元素。这暗示着软件架构学习是一个需要持续迭代、无法一蹴而就的过程。Google 的《软件工程》和 Ousterhout 的《软件设计哲学》经常被推荐，它们确实是好书，但并没有给 matklad 带来颠覆性的认知。
建立架构思维的行动框架
综合 matklad 的方法论，我们可以提炼出一套可操作的学习框架。首先是认识层面的调整：接受软件架构学习必须在实践中完成的事实，将每一个真实项目视为练习的机会，而非仅仅是交付成果。其次是社交维度的觉醒：理解 Conway 定律，在设计系统时同时考虑使用者和维护者的社会特征，而非仅关注技术指标。再次是分层阅读的能力：从宏观的架构模式识别到微观的代码实现，逐步建立对系统的完整认知。最后是持续反思的习惯：每个项目结束后复盘决策过程，区分哪些是技术取舍，哪些是社会因素作用。
这种多维度的学习路径，远比单纯记忆设计模式更有价值。软件架构的本质，是在约束条件下做出权衡决策 —— 而约束条件既包括技术因素，也包括组织因素。matklad 的洞见帮助我们认识到，优秀的架构师不仅是技术专家，更是理解人性、适应社会环境的实践者。
参考资料
- matklad 博客《Learning Software Architecture》（2026 年 5 月 12 日）
内容声明：本文无广告投放、无付费植入。
如有事实性问题，欢迎发送勘误至 i@hotdrydog.com。