构建可持续架构的三大秘籍

软件工程师必须在已经做出架构决策的情况下才能进行开发。我们可以在新的微服务中使用 Python 而不是 Java 吗？在开发新的前端库时，我们可以使用另一个捆绑器吗？我是否应该与经理或其他团队在代码库结构问题上达成一致？

在设计 REST API 时应该使用 snake_case 还是 camelCase 来命名 API？公司需要建立一个明确的框架来做出这些决策、需要谁参与，以及在哪里可以找到关于已经做出的决策的信息。

制定一个正确的框架非常重要，因为它将定义不同的团队将拥有多大程度的自由和自主权。这应该与公司在特定阶段试图建立的业务需求和公司文化相一致。

这可能会影响人们如何看待不同的领导角色、经理和个人贡献者在技术决策中的作用，以及不同职业级别的赋能水平。不同的公司需要根据其组织边界、成熟度和需求选择不同的负责人和不同程度的团队自主权，但框架应该提供非常相似的构建块。

在本文中，我将基于最近在不同规模的组织中工作的经验分享用来制定架构决策的框架应该提供的关键构建块。这些构建块包括内部技术雷达、技术标准和架构决策记录（ADR）。

建立自己的技术雷达

有些人可能知道 Thoughtworks，他们建立了自己的技术雷达。Thoughtworks 与行业内的客户一起捕获和发布他们所看到的东西。

类似地，你也可以建立自己的技术雷达，用于捕获公司使用或计划使用的不同的技术、工具和方法的成熟度。技术雷达是公司当前正在使用和期望使用的技术栈的可视化表示。

你需要定义不同的阶段——评估、试验、采用和保留，以及技术应该如何经历这些阶段的过程。

heycar 的技术雷达示例

在 heycar，我们定义了以下这些阶段。首先，新技术处于评估（Assess）阶段，也就是说它们正在被评估。我们在评估阶段进行概念验证（PoC），并生成在我们的环境中使用这些技术的优缺点清单。然后，我们与各自的内部团队或可能与之发生交互的团队讨论结果。如果论证清单和概念验证足够令人信服，那么下一步就进入可控的试验期。在试验期，新技术只被用于生产环境的单一用例。如果这一步成功，我们就宣布新技术已被采用，并为其他团队的进一步使用打开绿灯。如果新技术取代了以前使用的技术，可能需要发出信号。于是我们定义了“保留（Hold）”阶段——对于那么不打算再使用并且有了替代方案的技术。

技术雷达可以帮助团队了解技术前景，并就使用哪些技术做出明智的决策。如果你保持技术雷达是最新的，公司里的每一个人就都会知道正在使用的技术的最新状态及其对业务的影响。

引入内部技术标准

第二个部分是引入技术标准。技术雷达捕获技术、平台、工具、语言和框架，以及它们在整个组织中的采用程度，但这些可能还无法满足所有的需求。为系统的不同部分建立一致的实践会有所裨益。例如，你可能希望所有的日志都使用相同的格式，并包含相同的信息。或者，如果你正在使用 REST API，可能想要一些关于 API 设计和使用的约定，比如使用什么标头或如何命名。此外，如果你正在使用多种类似的技术，那么为何时该使用何种技术提供指导可能会很有帮助。技术标准定义了在公司内部选择和使用技术的规则。它们确保了一致性，降低以次优方式采用新技术所带来的风险，并在整个组织范围内推动保持一致性。

应该由谁来负责制定和维护这些标准？技术标准应由相关领域的跨职能专家团队负责制定和维护。技术标准需要进行定期的评审，并根据需要进行更新，以跟上技术领域的变化。应该鼓励团队遵循这些标准，并就其有效性提供反馈。格式可以不同，但最好可以提供详细的解释和代码示例。它可以是正式的，并遵循一些格式（如RFC 格式框架），也可以是随意的，这取决于具体的偏好和工程文化。Zalando 的 RESTful API 和事件指南是共享内部技术标准的一个很好的例子。除了 API 标准之外，你可能还想引入日志记录和监控、部署和 QA 标准。

你可以基于内部标准建立质量检验关卡，例如测试覆盖率检查、检查命名约定或格式的集成代码 linter、验证架构或代码库结构的适应性函数 （Fitness Functions）。自动检查、在新人加入时使用标准、代码评审或结对编程的组合将有助于确保标准被遵循并为我们带来价值。除了检查是否符合标准，这也是一个讨论平台工程价值的机会。不要只是简单地告诉人们他们做错了什么，而要让他们在一开始就做对。

架构决策记录（ADR）实践

架构决策框架的第三个构建块是创建 ADR 或轻量级 RFC。ADR 是记录架构决策及其推理过程的一种方式。它们提供了重要决策的历史记录，并帮助团队理解为什么选择了特定的方法。ADR 应该由负责做出架构决策的团队创建。它们应该包括正在解决什么问题、有哪些替代方案、做出的决策以及背后的原因等信息。它们是不可变的文档。在重新审视给定的决策时，通常需要创建一个新的文档。ADR 实践正变得越来越流行，因此AWS和GCP等主要云供应商已将其添加到各自的文档中。

技术雷达和技术标准为技术决策提供指导和预期边界，ADR 则捕获推理过程并记录特定的一次性决策——创建新服务或包、引入新技术或主要架构变更的原因。ADR 通常被保存在一个集中式的存储库或文档工具中，所有相关团队都可以访问它们。它们还可以帮助新团队成员快速了解整体架构和重大决策背后的原因。

ADR 评审有多种目的——评审决策和分享知识。每一个受决策影响的人都会参与到 ADR 评审中，但如果可以与更多人分享，它还有助于提高整个组织的整体架构意识。此外，ADR 可用于在内部收集更多的反馈。有时候，一些工程师可能在过去解决过类似的问题，只是现在没有在做相关的工作。

与前两个构建块一样，每个组织在最终确定 ADR 时的最终发言权以及哪些决策被认为足够重要而需要使用 ADR 的过程都是不同的。为了避免重复，你可以在做出新的主要系统变更时使用 ADR 来就特定的设计决策达成一致，而在决定使用何种编程语言、工具和实践时则采用技术雷达和技术标准。有了内部技术雷达和技术标准，采用 ADR 就应该是一个简单而直接的实践，因为最实质性的技术选择和原则已经达成了一致。

结论

技术雷达、技术标准和 ADR 共同构成了一种架构决策框架，这个框架为制定架构决策提供了清晰且一致的方法，降低了采用新技术的风险，并提供了决策历史记录。通过建立架构决策框架，团队可以确保他们的技术栈与他们的业务目标保持一致，并且他们的团队拥有做出明智决策所需的信息和指南。

团队所拥有的自由度，以及改变技术雷达、技术标准或 ADR 的过程，将塑造组织的工程文化。一些组织的目标是实现彻底的团队自治，而一些组织的目标则是保持高度的一致性。例如，一种可能的方法是让高级技术人员参与技术雷达和标准的制定，为进一步的技术决策提供指导，并将 ADR 留给负责实现软件功能的团队。你可以采用这种架构决策框架，并根据公司的需要做出调整。