进入软件架构师角色后我学到的关键事项

作者 | Tago Fabic
译者 | Sambodhi
策划 | Tina

免责声明：有很多关于成为软件架构师的文章（在我开始担任这一角色的时候，我最喜欢的就是这篇名为《成为软件架构师之路》（The Path to Becoming a Software Architect）的博文。不过，这篇博文更多地关注了我从这一角色中学到的重要东西，我希望这些知识能够为我在担任这份工作的时候带来一些期望。

首先，设定一些基线。

在成为架构师之前，我从工程师做起，一直到技术主管的角色。

就我而言，这个角色并不是一个管理角色：我没有一个人或一个团队向我汇报，因此，我在以前的角色中所发挥的一些关键能力（作为直接的直线经理）并不适用，但是，其中有些部分可以适用（例如，指导等）。

这种角色的复杂性的确在组织上有很大的不同，但是对于我自己，我认为应该首先确定什么是软件架构师，以避免一些混淆。为此，我们主要依靠 The Software Architect Elevator（暂无中译本，本文暂译为《软件架构师电梯》）一书作者 Gregor Hohpe 提出的概念。

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

（架构师是那些）掌握着架构、技术细节、业务需求，以及大型组织或复杂项目中的人员的人。
——Hope

通过“电梯”的概念，让我们更深入地理解这句话，Željko 在内部峰会上对这句话也做了精彩的阐述和分享（我重新描述了一下，但概念是一样的）。

好的，既然已经确定了，那就让我们继续学习关键知识。

转换思维——领导力通过战略先行、执行力随后

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

身为团队中交付领导角色的技术负责人，当时我的一个关键目标就是确保团队以最好和最有效的方式实现他们的承诺。你把燃尽图看做是你衡量每个人工作效率的标准。你可以自豪地写下 Sprint 结束报告，介绍团队两周内的胜利、趋势和学习。当成为架构师之后，我需要“从战壕后退几步”，看一看我们将要到达的地平线。

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

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

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

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

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

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

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

像所有事情一样，我们也在不断地调整这一过程。由于架构决策的结果，我们不希望架构决策记录成为实际交付的瓶颈，因此我们就拉取请求（Pull Requests）中 +1 的最低数量达成了共识。

有一点提示：偶尔，架构决策记录编写者可能会因为在决策过程中添加一些并不真正需要的信息而使记录过长：如果设定一个期望，架构决策记录不是一个程序规范，而是一份指南（“这更像是实现细节吗？”），它当然不是标准的文档，那应该住别处。

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

下面罗列一些有关架构决策记录的优秀参考资料：

• 来自 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 也认为她所指的白板可以激发快乐。JK

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

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

开始居家工作之后，把这个活动转变成一项在线活动对我来说非常重要：像 Miro、Mural、Excalidraw，甚至是好的、方便的空白谷歌幻灯片之类的工具，都对在线活动很有帮助。

大黄鸭个人版本的木质乐高积木小人，我给它取名为“Arther”。

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

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

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

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

对谷歌幻灯片提出一个小小的愿望：为每一篇演示文稿设置一个“听众”设置，允许你设置跳过哪些幻灯片等等。我发现自己要么创建演示文稿的副本（“演示名称（开发团队受众）”或“演示名称（营销团队受众）”或类似的内容），要么根据观众的不同在注释中添加跳过哪些幻灯片。如果能够轻松地切换这个就好了！

又及：这篇文章也是写给澳大利亚 Gumtree 和 CAMS 团队的一封“情书”，我有幸在这个组织工作了 6 年。在我转到另一个组织时，我会深情地回忆起我从当地团队和更广泛的 Adevinta Classifieds Group（以前属于 eBay）中获得的所有学习和互动。

再及：我还将分享一些我曾经接触过的书籍/参考，这些都是我作为软件架构师的发展过程中接触到的。

分享的一些书籍。

• 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