9年当上架构师，我的很多想法变了

软件架构师至今仍被不少人视为软件行业的“新兴职业”，网上时不时有关于如何成为软件架构师的文章，今天我们想分享的则是一位开发者在成为架构师后学到的重要东西。Tago Fabic 有十多年开发经验，在 2019 年开始成为软件架构师，他近日写了一篇文章，总结自己在成为软件架构师后的所获所得和心路历程，以下是他的分享。

在成为架构师之前，我从软件开发工程师做到了技术负责人。但就我而言，架构师这个角色并不是一个管理角色：没有一个人或一个团队向我汇报，因此，我在技术主管一职中所发挥的一些关键能力在这里并不适用，不过其中有些部分可以适用（例如，指导等）。

这类角色的复杂性的确是因组织而异，于我而言，我认为应该首先确定什么是软件架构师，以避免产生混淆。为此，我们主要依靠 The Software Architect Elevator（暂无中译本，本文暂译为《软件架构师电梯》）一书作者 Gregor Hohpe 提出的概念。

（架构师是那些）在大型组织或复杂项目中将架构、技术细节、业务需求和人员聚集在一起的人。——Hohpe

Adevinta 公司首席架构师 Željko Obrenović，和一位同事（我将他视为导师）在我们去年的一个峰会上提出了架构师是“超级胶水”的概念。

Željko 在内部峰会上通过“电梯”的比喻对 Hohpe 的那句话做了精彩的阐述和分享，以让大家能更深入地理解（我重绘了一小部分，但概念是相同的）。

确认了这个基本概念之后，下面我将继续核心收获的分享。

转换思维——战略先行、执行随后

在担任软件架构师的几个月中，我需要不断提醒自己的一件事是，架构师的职责与我以前的角色（技术负责人）的目标有所不同。这两个角色虽然有很多重合之处，侧重点却大相径庭。

身为团队中肩负交付任务的技术负责人，当时我的主要目标之一就是确保团队尽可能有效地履行其承诺，完成任务。我可以把燃尽图（用于表示剩余工作量的工作图表）看做是衡量每个人工作效率的标准，然后自豪地写下 Sprint 报告，介绍团队两周内的胜利、学习成果和趋势。而当成为架构师之后，我需要“从战壕后退几步”，才能更宏观地看到我们向前走的地平线究竟在哪。

成为一个团队的技术负责人是我的“舒适区”——我知道如何去做、怎么进步，但是架构师需要转换思维——积极分配时间进行咨询（沿着各个“电梯”层），着眼于一年、两年或三年之后的情况，并且清楚地把它阐述出来，以让每个人都在同一个轨道上前行。

架构决策记录用于讨论而非批准

我们的团队采用了架构决策记录（Architectural Decision Record，ADR）的编写方式，这确实是我近年来在我们组织中看到的很好的工作变革方式。

为什么这么说呢？让我来描述一下采用架构决策记录之前的情况：

1. 面对被称为微服务的新世界，开发团队会硬着头皮开始向左、向右和中心去旋转服务（包括我在内）。
2. 当团队壮大时，应用程序就变成了一个服务森林。
3. 好几次，不同的团队会推出新的服务，但是却发现它已经重复了另一个服务的目的（或未来的目的），而这个服务是几个月前创建的、并还在不断发展和成熟。
4. 同样有几次，工程师们（包括我自己）会在首次发布后就停下来，然后继续下一个服务，而不去做其他必要的管理工作（例如学习如何监控和警报等等）。

步入架构决策记录时代：为什么 ADR 受到我们工程师的青睐？因为它为工程师提供了一个工具，使他们能够尽职地考虑决策的后果，并就组织中不同的专业领域进行有价值的对话。这使工程师们可以清楚地说明他们是怎样做决定的，比如他们探索了什么，却又为什么最终认为这并不是最佳的前进方式等等。

在我们采用 ADR 的初期，每一条记录几乎都是一件大事：有人将提出将 ADR 进行面对面的讨论，由 20 多名工程师组成的小组就细节进行讨论和辩论，我们发现自己在整个会议的一个小时里都在讨论一条记录。我们知道这种方法不会变得规模化，因此我们转向 RFC 类型的、代码审查式的审查，而且这样做看起来更好。

像所有其它事情一样，我们也在不断地调整这一过程。由于架构决策的结果，我们不希望让 ADR 成为实际交付的瓶颈，因此我们就拉取请求（Pull Requests）中 +1 的最低数量达成了共识。就是说，ADR 不寻求批准，而是针对不同课题做有效讨论。

有一点提示：偶尔，ADR 编写者可能会因为在决策过程中添加一些并不真正需要的信息而使记录过长，那么可以设定一个预期，即 ADR 不是一个程序规范而是一份指南（也不是标准文档）。

在我看来，没有什么是天生不好的决定。只有不彻底、不够充分的决定。

下面罗列一些有关 ADR 的优秀参考资料：

• 来自 Cognitect 的《记录架构决策》（DOCUMENTING ARCHITECTURE DECISIONS）
• 来自 BetterProgramming 的《一款简单而强大的工具来记录你的架构决策》（A Simple but Powerful Tool to Record Your Architectural Decisions）——他们称之为 LADR（Lightweight ADR，轻量级 ADR），但是我们使用的格式类似。
• 《软件架构基础》（Fundamentals of Software Architecture）一书也有一个关于架构决策记录的好章节。

“这要视具体情况来看”

试想还是初级开发者的我要是穿越到现在，向现在的我寻求一些关于解决方案的意见，而现在的我会总说“这要视具体情况来看”，那年轻的我肯定对此会翻白眼，哈哈。

不过这是事实，你接触到的解决用户问题的各种方案和方法越多，你就越了解一个组织的成功案例可能在某个环境中行得通，也可能行不通（就像我们现在听到 “速赢” 或 “唾手可得的果实” 或流行语时产生的感觉一样）。

在“这要视具体情况来看”的回答之后，确实有一些开放的问题，以便进一步丰富这项建议的背景和理由。你认为数据库查询的意图是什么，或者缓存层是否有好处？需要的数据有多实时呢？认识到不存在银弹（不管是在解决方案上，还是在运作方式上），总能使问题的解决变得更生动、富有创造力。

完美是不切实际的

代码并不“关心”它的内聚或解耦程度；人们才会关心。——James Coplien

解决方案的完美之处在于接受或者承认，在某些时候，计划/投资的改变并没有给最终用户带来更多价值。

分解单体应用也是如此。我最喜欢的 Kelsey Hightower 的一条推文是这样写的：

很荣幸能在 @thenewstack 的 Context 播客上与 @el-bhs 辩论。虽然对单体和微服务存在争议，但是最终，我们都认为这两种架构模式都可以工作，而且对于复杂的组织而言，两者的混合是不可避免的。

简言之，优雅的解决方案始终是适合客户/最终用户需求的解决方案。

真相存在于代码中，而非文档中（或 JIRA Ticket 中，请注意这点！）

这一点，我想确实没有什么可解释的。我们知道文档会过时，但是我们知道，一个合适且充分的文件还是有必要的。

我发现自己通常从文档开始了解情况，然后在代码中进行验证，以确定它是否描述了一个准确的“故事”。如果不是，就在必要的时候更新文档。

有很多策略或建议可供使用来保持文档最新，但是最近我发现自己正在构建 Tiny 代码（非常感谢 GitHub API），它从代码本身提取信息来收集真相，或者依赖 Kiali 等工具的报告来实现流量与应用之间协作的可视化。

来自 Kiali 网站的屏幕截图。能看到流量，这很不错，并且它还提供了更多信息，比如每个箭头的延迟等。

白板会议激发了欢乐（以及惊人的想法和观点）

就连 Maria Kondo 也认为她所指的白板可以激发快乐。

大部分时间里，我发现自己变成了一只大黄鸭（Rubber Duck），工程师们可以在我这扩展或者验证他们头脑中的想法。（不是说我一直都是一个没有生命的物体，如果我们对这个定义有点学究气的话，哈哈）

我确实很怀念这场疫情爆发之前的一些事情，比如快速的白板会议，可以让我和工程师们一起充实项目或者想法。我们先用 Slack 进行初步的讨论，然后都跑到附近的白板上画画并讨论解决方案。

开始居家工作之后，把这个方式变成在线对我来说非常重要——像 Miro、Mural、Excalidraw这些工具，甚至是空白的谷歌幻灯片也行。

我的个人“大黄鸭”，给它取了个名字“Arthur”。

成为一名翻译和沟通者所需的创造力

最后，我学到的另一件很酷的事情就是，成为架构师能够将技术思想或概念进行翻译，并将其传递给非技术受众。

虽然我习惯于不断向技术团队分享计划或解决方案，但要让其他人也参与进来，我需要采取不同的方法。背景，背景，以及更多的背景，思考什么对你的听众很重要（例如，财务团队不需要知道项目时间表的细目，所以你只需要给一个非常快速的涵盖里程牌事件的幻灯片，但是要专注于明年的预算要花多少钱等等）。这些年来，我发现自己在演讲方面变得更具有创造性：不仅仅是视觉上的，还有如何传达每一次演讲背后的故事。

“你所说的每一句话都会影响到某人，所以要注意你所说的每一句话，”这句话是我几年前参加领导力培训时获知的，这话非常明智，但是我还想补充一点：要知道如何“翻译”它。

PS：分享一些我曾经接触过的书籍/参考，这些都是我作为软件架构师的成长过程中接触到的。

• Strengths Finder 2.0：这本书（以及相应的调查问卷）是我在几年前参加领导力培训时推荐给我的。这本书很有见地——特别是当你仔细研究自己的长处时，你可以挖掘并确定那些被认为是弱点的地方，并利用它们改变你的工作和协作方式。强烈推荐！
• Accelerate: Building and Scaling High Performing Technology Organisations：随着这份《DevOps 现状报告》在某种程度上已经成为标准，这本书很好地提醒了我们现在所熟悉的概念的细节，4 项关键指标等等。

其中最喜欢的一句话：“架构师应该关注工程师和成果，而非工具或技术。”

• Monolith to Microservices：啊，这可能是我的圣经吧，已经有好一段时间了。显然，这与我们一直在研究的实际架构有关，但是这本书提供了分解策略的良好指导——但是，在此之前，它会给你一些章节，询问为什么你想开始这么做，然后给你一个概述，让你知道计划如何完成这个任务并不像开发 Spring boot 应用程序那样简单。这本书与 Kelsey Hightower 的推文搭配简直就是绝配。

其中最喜欢的一句话：“拥有微服务并不能让你‘赢’。”

• Fundamentals of Software Architecture：这本书在导言和基础章节之后，我确实没有从头到尾按顺序阅读，而是来回跳着阅读关键章节，因为它讲述了不同的架构风格。

其中最喜欢的章节：（众多）架构师个性（哈哈）

• Team Topologies：在我的书库中，这是一本相当新的书，它探讨了思考团队结构的方法，咳咳，康威法则（Conway's Law），团队类型不是用规定性的镜头，而是鼓励团队优先思考的探索性观点。

其中最喜欢的话题：认知负荷。才华横溢，思维转变。

• Clean Architecture：又一部经典，不是吗？虽然这是一种更为实际的书籍讨论，但我还是不时地发现它是一个很好的参照点。

其中最喜欢的一句话（也是从某处引用的）：“如果你认为好的架构是昂贵的，那就试试坏的架构。”

• InfoQ 一直是个很好的参考渠道，这没有什么好奇怪的。
• Dear Architects 周刊每周都有精彩的文章策划——每周都有精彩的阅读。

作者介绍：

Tago Fabic，主业是软件开发者和技术负责人，副业是肖像摄影师。

原文链接：

https://tagofabic.medium.com/key-things-i-learned-after-moving-into-a-software-architect-role-dce88f9452a7