多年来，一些人询问有关Etsy的建筑审查过程的细节。

在这篇文章中，我将重点介绍架构审查工作组在促进技术决策对话方面的作用。其中一部分实际上只是关于一般的工作组（职业，缺点，格式等），另一部分则依赖于丹麦·麦金莱（Daniel McKinley）在他的讲话中的一般哲学，所以我会考虑阅读这些然后回到这里。

基础：工程决策是一个社会建设的活动

但首先，我们需要从一点基础理论入手。1985年，比利·沃恩·科恩（现任德克萨斯大学荣誉教授）介绍了我以前写过的“工程方法”的想法。关键的观点是他的观察结果表明，工程师的定义不是他们生产的，而是他们的工作方式。他简洁地描述了工程方法，它说：

“在现有资源范围内做出最不了解或不确定情况的最佳变化的战略”

请注意规范性条款最好和不好。

换句话说，工程（作为活动）对问题没有“正确”的解决方案。除此之外，如果您正在寻找解决问题的正确方法，我建议您在不同的领域工作（如数学）; 工程很可能会让你失望。

我完全同意这个想法，我会再说一遍，说成功的工程团队很大程度上是通过对话找到问题的解决方案。我的意思是，他们从事各种形式：

描述他们认为需要解决的问题。这可能或可能不是直接的解释或描述，所以一个组织通常需要一个来回来来完全掌握它。
生成关于所描述的问题是否需要或多或少完整或穷举的解决方案的假设。一些问题描述可能真的很狭窄，或者说真的很广泛，一些问题不一定要全部“解决”，等等。问题会永久存在吗？
评估解决方案的选项。优缺点都有什么？需要支持解决方案的团队能否维持或维护该解决方案？某些解决方案是否有“到期日”？可能的意想不到的后果可能会导致依赖于此解决方案的上游/下游系统？
建立对实施给定解决方案的信心。集团如何以积极或消极的方式发挥解决方案的不确定性（以及在什么方面）？
等等。
我意识到这应该是显而易见的，但我将这个观点纳入其中，因为我不断惊讶，当这个主题是公司选择使用特定技术（框架，语言，架构等）时，这是多么的困难，或不。

一旦你可以理解工程决策在社会上构建的概念，那么你可以理解我相信“架构审查”的设置和设置是至关重要的。

的概念和意图

当凯兰和我2010年第一次来到Etsy时，我们制定了一个过程，一个工程师（或一个小组）正在寻求实施新的东西（不同于我们已经在做或正在使用的）将提出他们是试图解决，为什么他们认为Etsy的现有解决方案不是理想的解决方案。我们称之为架构审查。

我们称这些“新事物”的事情离开了。再次，丹的帖子/谈话已经过去了，但基本思想是有成本（其中许多在许多方面都可以隐藏和惊奇），用于在不考虑全局影响的情况下尝试解决本地问题的出发可以在组织上

出发可以包括以下内容：

用已经在公司不广泛使用的语言编写功能或功能
重新设计功能或功能（即使是已经广泛使用的语言）
引入了一种尚未使用的模式或架构
使用新的服务器软件来存储，缓存或检索尚未使用的数据
基本上，任何有可能惊奇和挑战的团队（最终）破裂的事情
上面那些子弹很模糊，我相信你注意到了。那么你怎么知道什么时候应该要求架构审查？问你的同事 如果你正在辩论你的事情是否需要一个，那么你可能会这样做。

那么这个建筑评估会议呢？真的很简单 这只是工程师的一个演示文稿，就他们提出的解决方案寻求反馈，而凯兰和我会提出问题。会议开放给想参加的公司的任何人。希望许多工程师实际上会参加。这里的意图是帮助工程师尽可能彻底地描述他们的问题，通过提出问题，我们可以帮助我们提出他们在思考问题时所做的默认假设。简而言之，这是一个批判性思考的工作，我们希望工程师想要做到这一点，因为它是理想的提供反馈。

从这个角度来说，这个想法可以从一个想要反馈的工程师的角度来看：

“嘿，大家 - 检查一下：我相信我必须解决问题X，而且我已经考虑过使用A，B和C来做，但是它们似乎都不是理想的。我想我必须以离开Y为解决方案。请尝试跟我说这个。“

这种方法导致了上面提到的对话的一些非常好的提示。提示如：

“可能我甚至不需要解决问题X？”
“我错过了A，B或C的东西吗？他们有可能工作得很好吗？“
“如果我和Y一起去，我们需要做些什么来确定支持Y作为这种类型问题的解决方案？”
在很高的水平上，我们在早期的这种做法是相当成功的，因为我们能够让工程师来到，谈论他们所做的判断和假设，并就他们的理解细节提出问题和建议的问题和潜在的解决方案。即使它开始主要是凯兰，我提出问题，我们也积极鼓励他人。慢慢地，他们做到了，它成为了一个真正强大的信心来源的团队，集体。

做这些审查有一些非常令人惊讶的结果。不止一次，房间里的某个人会认识到所提出的问题，并且继承了他们也在与代码库的不同部分过去一样几乎相同的问题。他们说，有一些微小的变化，它可以解决手头的问题，而不是重新发明一些新的东西。大！

有一次，工程师走过一个相当复杂的图表，概述了他们将如何收集，总结，存储和处理数据以提供新功能。他们的解决方案不仅将新语言纳入应用程序的关键路径，而且还向堆栈引入了一个新的（并且在当时相对不成熟的）数据存储区。来了几个问题后，很明显，他们需要的数据已经存在，而且只有一个SQL查询和一个cron工作远离实现新功能。

这些结果并没有经常发生。但是当他们这样做的时候，这是相当满意的。

其他时候，一位工程师会出面对话，很明显，从多个角度来看，出发（新的和新颖的建议）似乎是最好的路线。

总的来说，我想说，从早期的架构审查实践中我们获得了很多好处。工程师在职业生涯中开始了很好的做法，介绍他们的工作和思考，老员工有机会分享一些他们不会拥有的知识或专长。就像我提到的，有时工程师通过走一条更简单的路线可以节省大量的时间和头痛。从领导层面来看，我对组织关于设计的建设性谈判能力的信心增加了。

多视角对话如何演变

但是，有一个问题：当你是首席技术官和高级副总裁时，当你邀请他们来参加会议时，你不会感到惊讶。我经常想知道有没有问题和意见，因为在房间里的力量动态不被说。我知道，除非房间中的大量工程师证明了实践的精神（即创造和支持一个批判性思维对话，旨在帮助工程师，个人和组织），那么将有一个很好的机会它将成为一种分层次的“美国偶像”风格的判断小组，严肃的政策掌握。

当然，这个想法是，更好的决策来自于人们对提出可能被视为“愚蠢”或“天真”的可能被看到的问题感到放心，并且主持人的听证会作为评论意见的设计，而不是在评论他们的技能。这意味着设计的起源（当时打算解决什么问题，当时人们关心的是什么）可以被记录下来

组织越多，单个人（甚至CTO或SVP）就越难以维持这种方法，并将工程师带入建筑评估中的假设。

特定类工作组的开始

因此，开发了一个建筑评估工作组或“ARWG”。主要思想是，如果没有高级工程领导层，这样一个团队可以保持这种做法，为会议带来专制风格，并不断地为行为所需的行为提供模型，以鼓励需要离开的多个视角。

一个小组成立，4或5人。原始的工程师将来自产品，基础设施和运营团队，但是其他团队的工程师则在之后加入。在某些时候，一些成员旋转进出。

该团队的章程基本相同，在高层次上，正如我们打算如何早期的建筑评论一样：提供一个稳定和受欢迎的环境，工程师可以公开地描述他们如何在解决问题时解决潜在的新颖和新颖的技术和模式。这个环境需要支持组织其他部门的关于权衡，假设，约束，压力，维护以及离职的责任的问题和意见。最后，记录如何确定出发的决定，因此存在一种人类学的工件来为未来的决策和对话提供信息。

你可能会在想：“但决定的时间和地点 何去何从？”

ARWG的作用不是作出决定。

ARWG的作用是创造和维持可以进行对话的条件，同时在既定时期内就可能遇到的问题和解决方案提出许多观点，然后便利围绕决定进行讨论。

在这一点上，我想在“对话”和“讨论”之间进行语义上的区分，我将从之前的博客文章中提到，在那里我提出了“对话：思考的艺术”

对话是探索选择的本质。选择是选择替代品。对话是关于唤起洞察力，这是一种对我们的知识进行重新排序的方法，特别是人们把握的假设。
讨论就是作出决定。不同于对话，寻求开放的可能性和看到新的选择，讨论寻求关闭和完成。这个词决定的意思是“通过削减他们解决困难。”其根源字面意思是“谋杀的替代品。”
ARWG的作用是首先促进对话，然后讨论。关键思想是在离开（问题和解决方案）之前通过“开放和好奇的心态”轻松地散发光，然后进入选项的评估阶段。对话旨在首先引起注意事项的细节（并假设必要性），然后只能讨论不同选项的优点。

根据我的经验，当一个架构审查引起了一个问题的注意，并从多个角度提出了解决方案，决策变得不那么有争议。当一个广泛群体的决定似乎是显而易见的（“问题：我们（或者我们不应该）是否对关键数据库进行备份？决定：是的）”决策的做法几乎消失了。

只有当一个决定没有普遍的协议（或者即使有必要的决定）时，知道如何，谁以及何时作出决定变得重要。架构审查的想法是以足够的方式将问题空间和提出的离职思想暴露给对话，尽可能地减少对它们的混淆。关于这个话题的较少的混淆可以帮助减少解决方案的不确定性和/或焦虑。

现在，这里存在一些陷阱：

工程师（无论是呈现还是作为观众参与）都需要了解架构审查的目的是开发更好的结果。而已。它不是展示他们的技术实力。
如果没有什么只关注“但是谁做出最终决定”呢，这就是一个信号，即批评和反馈（再一次是关于问题和解决方案）并不是真正的需要，而工程师则认为他们的偏离想法应该从任何理由得到通过批评。问这些原因是有用的。
没有强烈和持续地强调“批评代码，而不是编码器”，这种方法可以（并且将会保证它）在多个方面发挥防御性的作用。首先，正在寻找有关出发点的反馈意见的工程师需要将其视为作为成熟工程师的角色的一部分。
有时候，您可能会发现一位工程师对于他们针对特定问题开发的解决方案非常的热心，他们开始将重点放在演示文稿上，作为“销售点”，而不仅仅是表达了获得反馈的愿望。好消息是，检测发生的时间相对来说比较直观。坏消息是，审查的目的并不普遍。

其他时候，您可能会找到一组负责开发解决方案的工程师，这些解决方案与负责维护解决方案的团队不同。这个权威责任“双重约束”确实揭示了自己甚至是最小的组织。在这种情况下，恭喜！建筑审查能够将潜在的大象带入桌面。

在几乎每一种情况下，无论结构如何，建筑审查的结果都将永远在人们心中留下深刻的怀疑，就是离开而不是一个很好的决定。这些挥之不去的阴影是正常的。

欢迎来到工程部门，解决问题归结为“ 在可用资源范围内对知识不足或不确定的情况进行最佳变化的战略”。

虽然我不能指出，采用这种方法是在技术离职时总是做出最好的决定的气密方式，但我可以这么说：没有从技术上的不同群体获得多个观点，比如这种方法，你是所有这些都是保证不太理想的决定。

所以下一次你确定一个特定的新方式做得更好，组织的其他部分应该落后于你的想法，我会告诉你的：

“很好，听起来你有一个假设！我们要做一个架构审查。如果您认为它是一个明显的解决方案，组织的其余部分应该很容易得出相同的结论，这将使实现和维护更容易。如果有一些不明显的缺点，我们至少有机会挑逗出来！“