解耦、架构和团队
本文讨论了软件开发中代码组织和社会组织之间的关系。我讨论了为什么软件和团队不容易扩展，我们可以从生物学和互联网中吸取教训，并展示我们如何将软件和团队解耦以克服扩展问题。
讨论基于我 20 年构建大型软件系统的经验，但我也对Nicole Forsgren 、Jez Humble 和Gene Kim提供研究数据来支持我在这里所做的大部分断言。这是一个强烈推荐阅读。
软件和软件团队无法扩展。
这是一个很常见的故事，一个产品的第一个版本，也许是由一两个人编写的，通常看起来非常容易。它可能只提供有限的功能，但它编写得很快并满足了客户的要求。客户沟通很棒，因为客户通常与开发人员直接沟通。任何缺陷都可以快速修复，并且可以轻松添加新功能。过了一会儿，虽然速度变慢了。2.0 版的时间比预期的要长一点，修复错误更难，新功能似乎也不是那么容易推出。对此的自然反应是向团队添加新的开发人员，但团队中每增加一个人似乎都会降低生产力。随着软件的老化和复杂性的增加，它似乎在萎缩。在极端的情况下，组织会发现自己运行在维护成本非常高且似乎几乎不可能更改的软件上。存在负面的规模效应。问题是您不必为此发生”错误”，它是如此普遍，以至于人们几乎可以说这是软件的”自然”属性。
为什么是这样？有两个原因，代码相关和团队相关。代码和团队都不能很好地扩展。
随着代码库的增长，一个人理解起来变得越来越困难。人类的认知极限是固定的，虽然单个人有可能维持一个小系统细节的心智模型，但一旦超过一定规模，它就会变得比单个人的认知范围更大。一旦团队发展到超过 5 人或更多人，一个人几乎不可能跟上系统所有部分的工作速度。当没有人了解完整的系统时，恐惧就会盛行。在一个紧密耦合的大型系统中，很难知道任何重大变化的影响，因为后果不是本地化的。开发人员学会以最小影响的工作方式和重复工作，而不是分解共性并创建抽象和概括。这反馈到系统复杂性，进一步放大了这些负面趋势。开发人员不再对他们并不真正理解的代码拥有任何所有权，也不愿重构。技术债务增加。这也导致了令人不快和不满意的工作，并鼓励”人才蒸发”，最好的开发人员，那些更容易在其他地方找到工作的人，继续前进。
团队也无法扩展。随着团队的发展，沟通变得更加困难。简单的网络公式开始发挥作用：
c = n(n-1)/2
(其中n是人数，c是沟通渠道的数量)
随着团队规模的扩大，团队的沟通和协调需求呈几何级数上升。单个团队很难在一定规模内保持一个连贯的实体，即使没有管理投入，人类社会自然倾向于分裂成更小的群体，这将导致形成非正式的子群体。同级沟通变得困难，自然会被新兴领导者和自上而下的沟通所取代。团队成员从系统中的平等利益相关者转变为受指导的工作人员。动机受损，责任分散效应驱动的主人翁意识缺失。
管理层经常在这个阶段进行干预，并正式建立新的团队和管理结构来组织他们。但无论是正式的还是非正式的，大型组织都发现很难让人们保持积极性和积极参与。
通常将这些扩展问题归咎于技能低下的开发人员和糟糕的管理，但这是不公平的，扩展问题是不断增长和老化的软件的”自然”属性，除非您及早发现问题，识别拐点并工作，否则总是会发生这种情况很难减轻它。软件团队不断被创建，世界上的软件数量不断增长，大多数软件都是小规模的，所以一个成功且不断发展的产品是由一个没有大型软件经验的团队创建的。发展。当规模问题开始产生影响时，期望他们认识到拐点并知道如何应对是不现实的。
从自然中汲取教训
我最近阅读了Geoffrey West 的优秀书籍 Scale. 他谈到了生物和社会经济系统中的规模数学。他的论文是所有大型复杂系统都遵循基本的标度定律。这是一本引人入胜的读物，非常推荐。出于本次讨论的目的，我想重点关注他的观点，即许多生物和社会系统的扩展性非常好。采取基本的哺乳动物身体计划。我们与所有哺乳动物共享相同的细胞类型、骨骼结构、神经和循环系统。然而，老鼠和蓝鲸之间的大小差异大约是 10^7。大自然如何使用相同的基本材料和计划来处理如此巨大不同规模的生物体？答案似乎是进化发现了分形分支网络。如果你考虑一棵树，这可以很明显地看到。树的每一小部分看起来都像一棵小树。我们的哺乳动物循环系统和神经系统也是如此，它们是分形网络的分支，您的肺或血管的一小部分看起来像是整体的缩小版本。
我们可以从大自然中获取这些想法并将它们应用到软件中吗？我认为我们可以学到一些重要的经验教训。如果我们可以构建具有看起来像完整系统的较小部分的大型系统，那么就有可能包含影响大多数软件随着它的增长和老化而影响的病态。
是否存在可以成功扩展多个数量级的现有软件系统？显而易见的答案是互联网，一个拥有数百万节点的全球软件系统。子网确实看起来和工作起来就像整个互联网的较小版本。
解耦软件的属性。
将软件组件与更大的系统分离的能力是成功扩展的核心技术。互联网本质上是一个解耦的软件架构。这意味着网络上的每个节点、服务或应用程序都具有以下属性：
- 遵循共享通信协议。
- 仅通过与其他节点的明确合同共享状态。
- 不需要实施知识即可进行交流。
- 版本化和独立部署。
互联网可以扩展，因为它是一个节点网络，通过一组明确定义的协议进行通信。节点只通过协议共享它们的状态，一个节点的实现细节不需要被与其通信的节点理解。全球互联网不是作为单个系统部署的，每个节点都是单独版本化和部署的。各个节点相互独立地来来去去。遵守互联网协议是对整个系统真正重要的唯一事情。谁构建了每个节点，何时创建或删除，如何版本化，它使用的特定技术和平台都与整个互联网无关。这就是我们所说的解耦软件。
解耦团队的属性。
我们可以通过遵循类似的原则来扩展团队：
- 每个子团队应该看起来像一个完整的小型软件组织。
- 团队的内部流程和沟通不应成为团队外部的关注点。
- 团队如何实施软件在团队之外不应该是重要的。
- 团队应该与更广泛的组织就外部问题进行沟通：通用协议、功能、服务级别和资源。
小型软件团队比大型软件团队更有效率，因此我们应该将大型团队分成更小的团队。大自然和互联网的教训是，子团队应该看起来像一个单一的小型软件组织。多么小？最好是一到五个人。
每个团队应该看起来像一个小型独立软件组织这一点很重要。其他构建团队的方法效果较差。按功能拆分大型团队通常很诱人，因此我们有一个架构师团队、一个开发人员团队、一个 DBA 团队、一个测试人员团队、一个部署团队和一个运营团队，但这并不能解决任何扩展问题我们上面谈到的问题。每个团队都需要触及单个功能，如果您想避免瀑布式项目管理，通常以迭代方式进行 - 您会这样做。这些职能团队之间的沟通界限成为有效和及时交付的主要障碍。团队没有解耦，因为他们需要共享重要的内部细节才能一起工作。不同团队的利益也不一致：开发团队通常因功能交付而获得奖励，测试团队因质量而获得奖励，支持团队因稳定性而获得奖励。这些不同的利益可能导致冲突和交付不畅。如果开发团队永远不必阅读日志，为什么还要关心日志记录？当测试团队因质量获得奖励时，为什么还要关心交付？
相反，我们应该通过支持业务功能或逻辑功能组的解耦软件服务来组织团队。每个子团队都应该设计、编码、测试、部署和支持他们自己的软件。与专家相比，单个团队成员更有可能成为通才，因为一个小团队将需要分担这些角色。他们应该专注于尽可能多地自动化流程：自动化测试、部署和监控。团队应该选择他们自己的工具并自己决定如何构建他们的系统。虽然系统用于通信的组织协议必须在组织级别决定，但用于实现服务的工具的选择应委托给团队。这与软件组织的 DevOps 模型非常吻合。
团队的自治程度反映了与更广泛组织的脱钩程度。理想情况下，组织应该关心团队提供的功能和最终的业务价值，以及为团队提供资源的成本。
在这种组织方式中，软件架构师的角色很重要。他们不应专注于团队使用的特定工具和技术，或微观管理服务的内部架构，而应专注于各种服务之间的协议和交互以及整个系统的健康状况。
Inverse Conway：软件组织应该为目标架构建模。
解耦的软件和解耦的团队如何保持一致？康威定律指出：
“设计系统的组织…被限制生产的设计是这些组织的通信结构的副本。”
这是基于这样的观察，即软件系统的架构将反映创建它的组织的团队结构。我们可以通过反转康威定律来”破解”它；组织我们的团队以反映我们想要的架构。考虑到这一点，我们应该使我们的解耦团队与我们解耦的软件组件保持一致。这应该是一对一的关系吗？我认为这是理想的，尽管一个小团队似乎可以提供几个解耦的软件服务。我认为团队的扩展拐点大于软件的拐点，因此这种组织方式似乎是有效的。然而，重要的是软件组件应该与它们自己的版本和部署故事保持隔离，即使它们共享同一个团队。如果团队变得太大，我们希望能够拆分团队，并且能够将各种服务移交给不同的团队将是一个主要的好处。如果服务紧密耦合或共享流程、版本控制或部署，我们就无法做到这一点。
我们应该避免让多个团队在同一个组件上工作，这是一种反模式，并且在某些方面比让一个大型团队在一个超大的单一代码库上工作更糟糕，因为团队之间的沟通障碍会导致更糟糕的缺乏感- 所有权和控制权。
构建解耦软件的解耦团队之间的通信需求被最小化。再次以互联网为例，如果过程简单且文档充足，通常可以使用其他公司提供的 API 而无需任何直接通信。沟通不应该需要任何关于团队内部的软件过程或实施的讨论，相反，沟通应该是关于交付功能、服务水平和资源的。
构建解耦软件的解耦软件团队组织应该比其他方法更容易管理。较大的组织应该专注于在功能和服务级别方面为团队提供明确的目标和要求。资源需求应该来自团队，但可以被组织用来衡量投资回报。
解耦团队构建解耦软件
解耦软件和团队是构建高性能软件组织的关键。我的轶事经验支持这种观点。我曾在团队按软件功能或软件层隔离，甚至按客户隔离的组织工作过。我还曾在单一代码库的混乱大团队中工作过。所有这些都受到上述缩放问题的影响。最快乐的经历总是我的团队是一个完整的软件单元，独立构建、测试和部署解耦服务。但是您不必依赖我的轶事证据，《加速》一书（如上所述）有调查数据来支持这一观点。
原文来自： https://mikehadlow.blogspot.com/2018/11/decoupling-architecture-and-teams.html