架构应被视为产品，而非纪念碑。关注用户体验，通过开发人员生产力指标衡量架构的成功，并构建与业务目标一致的架构路线图。良好架构应降低认知负荷，使团队能够专注于解决业务问题。
译自：Software Architecture Is Finally Fixing Its Biggest Problem: Developer Experience
作者：Avraam Tolmidis
架构讨论经常迷失在抽象之中 —— 白板上的草图无法经受现实的考验，密集的文档堆积着数字灰尘，理论上的纯粹性在实际应用的压力下崩溃。在不同规模和行业构建和重建系统多年之后，我了解到最成功的架构都有一个关键特性：它们被设计成产品，而不是纪念碑。
我对这个认识的道路始于研究。我获得了塞萨洛尼基亚里士多德大学电气和计算机工程博士学位，专注于优化和协作机器人。我后来的工作探索了人工智能在城市交通管理中的应用。从那时起，我领导了学术和工业领域的软件工作，包括在大陆集团、采埃孚和安波福等汽车行业担任职务，目前我在 Meta 担任软件工程经理，负责诚信系统。在此之前，我曾在阿姆斯特丹的金融科技公司 Backbase 管理团队，为零售和商业客户构建核心银行平台。
这种视角的转变改变了一切。当你把架构当成产品时，你会开始问不同的问题。你不会问“这是否优雅？”，而是问“这是否能帮助人们完成工作？”你不会为了理论上的完美而优化，而是为了现实世界的结果而优化。
你的架构用户远远超出工程团队
我在架构之旅中最具变革性的认识是理解了谁真正与我们设计的系统互动。工程师是显而易见的用户 —— 他们需要清晰性、可维护性，以及在不破坏一切的情况下进行更改的信心。但他们只是一个更大的生态系统中的一部分。
产品经理依靠架构来实现快速迭代和功能部署，而不会产生过多的协调开销。如果他们因为三个团队需要为一个琐碎的更新进行协调而无法部署，那就是一个架构问题。设计师和质量保证工程师需要稳定、可预测的接口，具有清晰的边界和可预测的影响。如果一个小的 UI 调整变成了后端混乱，那么架构就让他们失望了。
业务利益相关者对速度、价格和可扩展性感兴趣。他们可能永远不会了解技术细节，但当架构使增长更容易或更难时，他们会立即感受到影响。客户支持团队通过系统的可靠性和可调试性来处理架构决策，他们通过这些系统引导用户。
认识到更大的用户群会改变你做出设计决策的方式。每一个设计决策现在都是一个用户体验问题：“这会影响谁，以及它将如何改变他们的日常工作？
将软件架构视为产品，而不是纪念碑
对“整洁架构”的追求可能是一个陷阱。我见过漂亮的系统 —— 完美分层、奇妙抽象、具有漂亮的类层次结构 —— 但没有人愿意维护。它们符合书中所有最佳实践，但不知何故，却使无关紧要、晦涩和简单的更改变得危险。
相反，我曾使用过所谓的“混乱”系统，团队喜欢它们，因为他们能够自信地发布功能，优雅地处理边缘情况，并且知道在出现问题时会发生什么。他们用架构的纯粹性换取了开发人员的生产力，这是值得的。
这并不是要抛弃良好的设计实践。结构、关注点分离和清晰的接口仍然至关重要。但是，应该为了使用该系统的人的利益而使用它们，而不是为了它们自己的利益。如果架构选择使工作变得更困难而不是更容易，那么即使方法论在理论上是合理的，也一定出了问题。
好的架构对于那些使用它们的人来说往往是隐形的。它们为正常的事情提供清晰的解决方案，为异常需求提供合理的替代方案，并提供足够的灵活性来扩展，而无需进行彻底的改造。
通过开发人员生产力指标衡量架构的成功
大多数解决方案的仪表板都充满了量化用户行为、性能和业务成果的指标。架构也应该得到同样的关注，但它不是通过对设计美学的有争议的主观争论来衡量，而是通过对有效性的客观评估来衡量。
我开始根据与团队生产力直接相关的问题来跟踪架构健康状况：部署和发布常规功能需要多长时间？有多少团队需要协调才能进行跨领域的更改？系统中看似不相关的部分以未知的方式相互影响的频率是多少？工程师在更改基本组件时有多自信？
这些数字胜于雄辩。当部署提前期从几天缩短到几小时，当团队间的依赖性降低，当生产故障发生的频率降低并且更易于调试时 —— 这些结果比任何设计文档都能更雄辩地说明架构决策。
有时无法进行直接测量，但信号仍然存在。与开发团队的定期讨论揭示了痛点、瓶颈以及架构正在促进或阻碍进展的领域。这种反馈构成了架构改进优先级中的关键输入。
构建与业务目标一致的架构路线图
架构不是一个一锤定音的决定，而是被刻在石头上。它是一个活的系统，要么有意识地进化，要么意外地退化。像任何产品一样，它受益于对未来需求的周密计划和战略思考。
将架构规划分解为三个阶段是可行的。“现在”解决的是近期的障碍 —— 当前积极阻碍团队的架构债务。这些通常是快速的胜利，可以提供快速的缓解，并为更重大的变化建立动力。
“下一步”问题并不具有时间敏感性，但如果不解决，就会造成损害。这可能是随着流量增加而出现的扩展瓶颈，或者是随着代码库扩展而变得更难以解决的结构性问题。
“稍后”是关于明智地押注未来的需求。在这里，您押注于未来规模、范围或业务方向发生后续变化时的灵活性。这些是风险更高的赌注，但当您做对时，它们可以获得巨大的回报。
明智的选择是将架构路线图与产品和业务路线图对齐。当架构改进与业务目标（例如更快的特性交付、更高的可靠性和更低的运营成本）高度相关时，它们更容易确定优先级并证明其合理性。
通过开发人员生产力指标衡量架构的成功
如果团队不采用它，那么最令人惊叹的架构也毫无用处。我见过太多精心构建的系统堆积灰尘，因为团队开发了解决方法或复制实现，因为“官方”解决方案不适合他们。
成功采用架构就是将内部团队视为外部客户。这意味着发送早期草案以获取反馈，而不是最终结论，有意识地征求关于痛点和需要改进领域的想法，并维护反映现实而不是表达愿望的记录。
跟踪采用指标 —— 哪些团队正在使用新模式，旧方法仍然存在于哪里，正在创建哪些解决方法 —— 提供了关于架构更改实际上是在解决问题还是只是制造新问题的关键反馈。
采用指标监控 —— 哪些团队正在采用新模式，他们在哪里仍然采用旧方法，他们正在应用哪些解决方法 —— 提供了关于架构更改实际上是在解决问题还是仅仅制造新问题的有价值的反馈。
人为因素：良好的架构如何降低认知负荷
最后但并非最不重要的一点是，架构是关于共同努力构建软件。技术上的合理性是必要的，但沟通、理解和信任也是如此。优秀的架构最大限度地降低了认知负荷，消除了协调开销，并使使用简单但易于理解的心理模型对复杂系统进行实际推理成为可能。
这种人为因素会影响一切，从命名方案到服务边界和部署过程。当架构与团队想要工作的方式发生冲突时，摩擦是不可避免的。当它增强并加速自然流动时，生产力就会起飞。
好的架构不仅仅是组织代码 —— 它还组织团队，减轻压力，并创建一个人们可以专注于解决业务问题而不是与技术障碍作斗争的环境。
构建与业务目标一致的架构路线图
只有当架构不再是一种约束而成为一种赋能时，它才有价值。当您将适用于任何优秀产品的相同原则和以用户为中心的方法应用于架构决策时，就会发生这种情况。
首先要了解您的用户 —— 所有人，而不仅仅是工程师。跟踪对您的业务最重要的结果。有策略地进行变更，将技术变更与业务价值联系起来。关注采用和实际使用，而不是理论上的完美。
当架构良好时，它几乎是不可见的。团队更快地发布功能，系统扩展得更漂亮，问题更容易理解和修复。那时，架构不再是一件让团队围绕其弯曲的工作，而变成了成倍提高团队效率的东西。
架构师能得到的最慷慨的赞扬不是因为美丽的设计，而是团队称赞他们说系统只是按照他们期望的方式工作。这就是产品架构，这就是重要的架构。
