9年当上架构师，我的很多想法变了作者|TagoFabic译者|刘志勇审校

作者|TagoFabic
译者|刘志勇
审校|燕珊
软件架构师至今仍被不少人视为软件行业的“新兴职业” ，网上时不时有关于如何成为软件架构师的文章，今天我们想分享的则是一位开发者在成为架构师后学到的重要东西。 TagoFabic有十多年开发经验，在2019年开始成为软件架构师，他近日写了一篇文章，总结自己在成为软件架构师后的所获所得和心路历程，以下是他的分享。
在成为架构师之前，我从软件开发工程师做到了技术负责人。但就我而言，架构师这个角色并不是一个管理角色：没有一个人或一个团队向我汇报，因此，我在技术主管一职中所发挥的一些关键能力在这里并不适用，不过其中有些部分可以适用（例如，指导等）。
这类角色的复杂性的确是因组织而异，于我而言，我认为应该首先确定什么是软件架构师，以避免产生混淆。为此，我们主要依靠TheSoftwareArchitectElevator（暂无中译本，本文暂译为《软件架构师电梯》）一书作者GregorHohpe提出的概念。
（架构师是那些）在大型组织或复杂项目中将架构、技术细节、业务需求和人员聚集在一起的人。 ——Hohpe
Adevinta公司首席架构师?eljkoObrenovi? ，和一位同事（我将他视为导师）在我们去年的一个峰会上提出了架构师是“超级胶水”的概念。
?eljko在内部峰会上通过“电梯”的比喻对Hohpe的那句话做了精彩的阐述和分享，以让大家能更深入地理解（我重绘了一小部分，但概念是相同的）。

文章图片
确认了这个基本概念之后，下面我将继续核心收获的分享。
1
转换思维——战略先行、执行随后
在担任软件架构师的几个月中，我需要不断提醒自己的一件事是，架构师的职责与我以前的角色（技术负责人）的目标有所不同。这两个角色虽然有很多重合之处，侧重点却大相径庭。
身为团队中肩负交付任务的技术负责人，当时我的主要目标之一就是确保团队尽可能有效地履行其承诺，完成任务。我可以把燃尽图（用于表示剩余工作量的工作图表）看做是衡量每个人工作效率的标准，然后自豪地写下Sprint报告，介绍团队两周内的胜利、学习成果和趋势。而当成为架构师之后，我需要“从战壕后退几步” ，才能更宏观地看到我们向前走的地平线究竟在哪。
成为一个团队的技术负责人是我的“舒适区”——我知道如何去做、怎么进步，但是架构师需要转换思维——积极分配时间进行咨询（沿着各个“电梯”层），着眼于一年、两年或三年之后的情况，并且清楚地把它阐述出来，以让每个人都在同一个轨道上前行。
2
架构决策记录用于讨论而非批准
我们的团队采用了架构决策记录（ArchitecturalDecisionRecord ， ADR）的编写方式，这确实是我近年来在我们组织中看到的很好的工作变革方式。
为什么这么说呢？让我来描述一下采用架构决策记录之前的情况：
面对被称为微服务的新世界，开发团队会硬着头皮开始向左、向右和中心去旋转服务（包括我在内）。
当团队壮大时，应用程序就变成了一个服务森林。
好几次，不同的团队会推出新的服务，但是却发现它已经重复了另一个服务的目的（或未来的目的），而这个服务是几个月前创建的、并还在不断发展和成熟。
同样有几次，工程师们（包括我自己）会在首次发布后就停下来，然后继续下一个服务，而不去做其他必要的管理工作（例如学习如何监控和警报等等）。