软件开发团队中的体系结构决策

每种类型的工作都需要某种结构以使事情顺利进行。 在软件开发项目中，此结构的重要部分是我们正在构建的软件的体系结构。

架构描述了我们软件的构建块以及它们如何相互配合。 如果每个团队成员都按照自己的最佳想法构建模块，则可能会起作用，但是会导致整个代码库使用不同的样式和概念。 很有可能这将很快导致无法维护的代码。

相反，如果我们有一套一致同意的体系结构规则，则构建块的形状将可以放在一起，并且易于扩展，测试和维护。

根据我作为开发团队的高级成员/架构师的经验，我发现有必要从一开始就定义一组架构规则（是的，即使是在做Scrum时），但随后要进入一种持续决策的模式，团队。

这样一来，有没有成为危险象牙塔建筑师谁的团队决定一切，但谁不是由团队的尊重。 您希望团队参与重要的决策，而又不感到落伍。

这是我在与团队合作时 承担责任的方式来推动项目中的体系结构决策。

收集问题和想法

首先，我们需要一个收集架构问题和构想的地方。 这通常是具有以下列的表格形式的结构化列表：

• 提出问题的日期
• 提出问题的人的名字
• 一个关键字 ，用一个词描述问题的上下文，以便于索引
• 问题的简短描述 ，可能带有指向其他材料的链接
• 负责此问题的人员的姓名 （最初为空）
• 状态标志 ，例如“打开”，“进行中”或“完成”

此列表是体系结构问题的资料库，项目中的每个人都应该知道。 所有人均可访问，所有人均可编辑。 邀请每个人将有关体系结构的问题和想法添加到此列表中。

通常，并非团队中的所有人都会对此列表做出贡献。 有些满足于让其他人讨论和做出决定，这完全可以。 通常，这些是比较初级的开发人员，他们仍然对自己的技能缺乏信心，但是他们会做到的。

但是总会有一些开发人员，他们会很乐意借此机会提出有关如何做得更好的想法，并指出他们在当前体系结构状态下存在的问题。 这些想法和问题将推动我们软件架构的发展。

作为高级开发人员或架构师，不要忘记自己为这份清单做出贡献。 毕竟，您想引入自己的经验。

实际上，如果您是唯一对此做出贡献的人，或者您自己进行项目，则甚至应该维护一个体系结构问题列表。 如果清单仅在您的脑海中，则很可能会让人感到负担重重，因为您担心自己会忘记一些东西。 否则您实际上会忘记一些东西。 您未来的自我会感谢您写下的所有内容。

建立实践社区

但是，仅收集问题和想法并不能解决问题。 我们需要讨论它们，并以结构化的方式基于它们做出决策。

作为高级开发人员/建筑师，我们可以列出这份清单，撤入象牙塔的顶层公寓，并为每个项目决定采取的行动方案。 但是，像这样的自上而下的决策并不适合所有人（老实说，可能并非始终都是最佳决策），因此我们应该尝试让团队参与其中。

我过去成功完成的工作是为建筑主题建立实践社区（CoP）。 “实践社区”一词通常用于敏捷项目中，以描述每个团队都在项目中推动某个主题的子团队，但这些团队甚至起源于敏捷成为流行语之前。

本文所指的实践社区是一组对软件体系结构感兴趣并正在积极进行软件开发的团队成员。 “积极实践”部分很重要，因为如果他们不开发软件，他们将不知道任何架构决策的后果。

每两周左右，我为这个实践社区安排一次会议。 我看一下清单上的问题和想法。 通常，在会议的前一天，我会与遇到问题的每个人进行交谈，这样我就可以更好地理解这些问题。 然后，我决定哪些主题应成为会议议程的一部分。

在会议之前选择要讨论的问题很重要。 否则，会议可能会降级为无效的暴民优先级会议。

会议有时间限制，通常不超过一个小时或一个半小时。 另外，每个要讨论的项目都有时间限制，因此我们有明确的议程。

然后在小组中讨论每个项目，如果一切顺利，则为所有人的利益做出决定。 一些物品到处都在那里安顿下来； 其他人可能会要求某人跟进评估或与其他人交谈。 在这种情况下，该项目将分配给后续的看门人。 问题列表中的看守者和状态列会相应更新。

议程上的重点之一应该是审查当前“正在进行中”的所有项目，以跟进它们。

做出决定通常感觉很好。 无论每个人是否支持该决定， 我们都在进步。

记录您的决定

此进展必须记录在案。 我们必须能够在一年后回来，并说：“啊，是的，这就是我们按照这样做的方式这样做的原因。”

几乎没有什么比讨论某些事情更令人沮丧，而不得不说“我记得几个月前我们谈论过这个问题，但我不记得当时的决定。”

而且，我告诉你，这在我身上经常发生。 我的记忆力很差（或者可能是长期选择性的）。

让我们将决策文档称为“架构决策记录”（ADR）。 自从2016年将其纳入ThoughtWorks的技术雷达以来，这个术语已经引起人们的关注。

从本质上讲，ADR是一个结构化的文档，描述了我们做出决定的原因以及我们希望通过该决定实现的目标。 例如，ADR可能包含以下属性（根据需要使此列表适应您的需要）：

• 唯一编号，以方便参考
• 一个标题
• 决定
• 决定的原因
• 我们希望以此实现的目标

ADR应该保持尽可能靠近代码库，以便它们可以与代码保持同步，并成为我们代码审查规程的一部分。

有了完善的ADR清单，当我们知道已经讨论过某个主题并从那时起重新评估我们的决定时，我们可以轻松地回溯过去。

也许过去决定的原因仍然存在。 但是，有时原因不再有效，因为上下文已更改，或者尚未达到我们希望通过决策实现的目标。 在这种情况下，我们可以决定其他的处理方式。

能够引用ADR还可以使我们在CoP会议中Swift扼杀无用的讨论。 只是指着ADR并说“我们已经讨论过这一点”就产生了奇迹。

何时没有共识？

有时候，我们在CoP会议上一直在讨论架构问题，而我们无法就解决该问题的行动方案达成共识。

在这种情况下，我们还有两个选择。

我们可以将问题推迟到下一次会议 。 这给了我们和团队其他成员一些时间来考虑它。 通常，这足以给我们或我们的辩论伙伴一些启发，以解决问题。 也许我们在此期间学到了一些对我们有帮助的新东西。

如果此事很紧急，需要Swift决定， 我们可以屈服于辩论伙伴的意见，并以他或她的方式去做 。 即使我们认为这不是最好的做事方式， 做某事总比什么都不做更好。 只需确保将决定记录在ADR中即可，以便在必要时我们可以重新考虑。

如果我们真的觉得自己的路是走的路，而如果我们以不同的方式做事，灾难将会来袭，那么我们可以凭借我们的经验推翻团队 。 显然，这只有在我们在团队中得到足够的尊重时才有效（或者我们具有给我们所需权限的角色）。 即使这样，这也可能会冒犯某些人，但有时必须由架构师做出决定 。

如果我们以团队为单位就体系结构决策达成共识，这是很好的，但是对于团队合作成功而言，不必达成共识。 如果我们彼此尊重，同时坚决主张某些决定，而又屈服于其他决定，那么我们仍然可以交付结构良好的软件。

交付出色的建筑

当您让团队成员参与制定体系结构决策的过程时，在软件开发团队中担任架构师或高级开发人员的生活会容易得多。 团队成员会感到自己的见解很荣幸，您可以通过团队传播架构知识，避免以后需要清理的架构混乱。

收集问题，在实践社区中讨论问题，然后记录决策的步骤只需很少的工作，因此几乎没有什么可以阻止您的。

一旦将此工作流程整合到项目的日常工作中，它将减轻您在自行决定所有事情的同时减轻了您的负担，同时帮助团队成长并交付具有体系结构的软件。

从今天开始。

翻译自: https://www.javacodegeeks.com/2018/10/architecture-decisions-software-team.html