架构回顾：如何让软件架构变得更好

重复同样的行为却期待出现不同的结果，这种已被广泛定义为“疯狂”的认知却是那些从不反省自己工作方式的团队常常掉入的陷阱。设计软件架构也不例外：如果你从不停下来检查你是如何做出决策的，结果可能会反映出你在看待问题方式上的系统性偏见。

软件架构评审很重要，但它们不能代替回顾，我们将探讨其中的原因。评审关注的是产品本身及其架构设计，而非决策过程本身，或团队执行这些决策的方法。回顾是许多敏捷软件开发方法的关键要素，原因很简单：它们为团队提供了必要的时间和思考空间，用于反思如何改进工作方式。在本文的其余部分，我们将探讨如何以及为什么要这样做。

架构评审的核心目标在于提升架构质量。在 MVA 方法的框架下，我们所讨论的架构评审主要专注于评估架构增量（MVA）对支持增量产品 MVP 的适用性。

增量开发的核心在于收集可以用来改进产品（MVP）及其相关架构（MVA）的反馈，所以架构评审是必不可少的，并且应该在每个增量开发周期（例如 Scrum 的 Sprint）中进行。

这与传统的架构评审不同，后者往往因频率较低而难以及时捕捉问题，直至问题恶化至不可逆转的地步。然后，它们会变成重大事故之后的一种事后分析，目的是确定是否可以采取任何措施来解决事故中遇到的问题。传统的架构评审，特别是如果由外部团队执行时，通常会变成一场责任推诿的游戏。与之相反，MVA 方法强调定期进行架构评审的重要性，核心在于汲取经验教训，确保灾难性故障永远不会发生。

架构回顾的目的在于利用过往经验帮助开发团队改进他们的架构技能和决策方式。架构回顾是开发团队进行反思，以便在未来可以做得更好的契机，并且对于每一个迭代 /Sprint 来说也很重要，因为团队几乎总是可以发现并学习那些可以在未来做得更出色的方面。

通过比较和对比架构评审和架构回顾，有助于了解它们之间的差异（见表 1）。

表 1：架构评审与架构回顾对比

如果你已经有在 Scrum 框架下进行 Sprint 回顾，那么只需要留出一点时间，提出一些关键性的问题，探索如何优化你的架构工作流。

如果你还没有进行 Sprint 回顾，可以安排专门时间来深入探讨关键性问题，这些问题将帮助你理解你的架构工作流。这种探讨不仅限于架构本身，也可以扩展到团队的工作方式。我们认为这两者都很重要，尽管本文重点放在对架构进行回顾上。

你可能会考虑在架构评审中添加一个回顾环节，但我们不建议这么做。例如，在 Scrum 中，Sprint 评审 和 Sprint 回顾是两个独立的过程，这是有原因的：

• 架构评审的涉众包括团队之外的人，他们可能并不了解团队的工作方式，也可能对团队的内部运作不感兴趣。如果你谈论他们不知道或不关心的事情，可能意味着你没有尊重他们的时间，导致他们在未来可能选择不参与评审。

• 开发人员在有外人在场的情况下，可能不会自在地讨论他们的工作方式中存在的问题。而如果不公开讨论团队正在经历的挑战，可能就无法发现重要的改进机会。

• 在大多数情况下，为开发人员在架构评审之后提供一些反思的时间是非常值得的。当架构评审暴露出架构问题时，每个人都自然会集中精力去解决这些问题。有些问题的根源隐藏在团队的工作方式或决策方式中，只是解决具体的问题往往无法触及这些根源。将架构回顾与架构评审分开，可以给予团队成员足够的时间来深思熟虑，从而更深入地理解问题的根源。

这种关注点的分离（借鉴自 Scrum 等方法）非常有效，因为它有助于集中注意力。评审产品或架构已经足够复杂了，所以无需再扩大评审的范围，而应该专注于团队的工作方式，这样有助于团队更有效地进行自我改进。

架构回顾会议的机制与 Scrum 中 Sprint 回顾会议的机制相同。实际上，可以在常规的回顾会议中加入架构重点，避免创建另一个会议，只要所有参与者都参与制定架构决策即可。这还是一个展示机会，证明任何人都可以做出架构决策，不仅仅是“架构师”。加入架构重点意味着要问一些关于团队如何制定架构决策的问题：

• 看看 QAR 是如何制定的。它们是猜测出来的吗？它们准确吗（也许它们是从其他系统复制过来的）？它们有用吗？它们是否带有限制性？我们做了哪些假设？团队的完成定义是否反映了 QAR？

• 看看做决策的方式。是整个团队都参与了决策，还是主要由最资深的人主导？它们是否得到了实证的支持（即开发和测试一个 MVA 的实证）？决策是基于经验而做出的吗？我们的认知或决策过程中是否存在系统性偏见（这些偏见会阻碍我们取得良好的结果）？

• 看看如何利用反馈来提升决策。你是否评估过决策的有效性？你是否因为接收到新的信息而撤销过决策？你是否在反馈的影响下曾经将某些任务从待办清单中剔除，因为它们不再具有相关性？

• 深入关注权衡决策。它们的有效性是否是基于你从 MVA“实验”中学到的东西？它们是否满足了预期的需求，还是有所不足？

• 评审技术债务。技术债务在增长吗？（答案显然是肯定的...）这是可接受的吗，还是团队实际上在无意中为将来的问题埋下伏笔？

• 考虑如何使用反馈来改进架构。你能够按照 MVP/MVA 来增量发布系统吗？你愿意进行可能失败的实验吗？你是否创建了既支持 MVP 又能验证决策和权衡有效性的 MVA？你能否利用发布 MVA 的反馈来改进未来的 MVA？

• 看看团队的技能。你的团队是否具备开发有效 MVA 的技能、专业知识和经验？团队需要改进或获得哪些技能？你是否因为无法抽出时间学习新技术而坚持使用旧技术？

在任何一个架构回顾会议中，最应铭记的要点是，回顾的目的是找到具体的改进团队工作方式的方法。回顾的目的不是为了批评或归咎责任，一旦出现了这种情况，回顾就变得毫无用处，甚至有害。团队只能通过构建和测试架构增量（MVA）来学习和成长，且不是每个想法都能如愿以偿。构建和测试想法对于尝试新方法和做出更好的决策来说至关重要。

有些人可能认为，每次创建 MVA（例如 Scrum 中的每个 Sprint）都不需要回顾，因为他们担心这会花费太多的时间。我们认为，在每次 MVP/MVA 发布后都自问一下上述的问题——如果没有什么引人深思的答案，那么回顾可以简短结束，你可以继续前进。但如果答案中包含了有价值的见解，那么花点时间检查一下你制定架构决策的方式是值得的。然后，你再开始构建下一个增量 MVP/MVA。从长远来看，这种做法将为你节省时间并避免潜在的痛苦。

架构回顾帮助团队改进他们的工作方式，而架构评审帮助团队改进他们正在开发的产品。架构评审不应该取代架构回顾，正如架构回顾不会取代架构评审一样。

许多团队选择忽略架构回顾，因为他们不愿直面自身的不足。架构回顾更具挑战性，因为它们不仅审视团队的工作方法，还审视团队的决策过程。但架构回顾所带来的回报是巨大的：它们能够揭示那些未被明确表达的假设和隐藏的偏见，而这些偏见往往会阻碍团队做出更明智的决策。如果你一直进行架构回顾，会得到更好的架构。

查看英文原文：

https://www.infoq.com/articles/architectural-retrospectives/

声明：本文由 InfoQ 翻译，未经许可禁止转载。