整体工程：有机解决复杂演进系统中的问题

项目延期；架构偏离了最初的设计；代码神秘地演变成了没有人计划的东西。这些在软件开发中持续存在的问题往往不是由技术失败引起的，而是因为我们忽视了错以为不存在的力量，即奖励系统激励了错误的行为，组织结构忽视了领域边界，以及我们认为“太琐碎”而没有考虑技术决策中的人际关系。

整体工程（holistic engineering）是有意将这些非技术力量纳入我们的技术决策、设计和策略的做法。就像地质力量在峡谷壁上留下可见的层一样，组织和人类的力量在我们的代码库中留下了它们的印记。不同的是，我们可以清楚地看到峡谷的层，而塑造我们软件的力量在我们学会寻找它们之前是看不见的。

图片来源：感谢Tomáš Malík在Pexels上的贡献。

在我的职业生涯中，无论是作为软件工程师、架构师、技术领导、工程经理、首席工程师还是顾问，我都观察到相同的模式在不同的公司、领域和技术栈中反复出现。这些模式揭示了非技术力量如何始终塑造我们的技术系统，无论我们是否承认这一点。

现实环境中的现象

项目延期是我们的业务中一个持续存在的问题。要与截止日期完美对齐是非常具有挑战性的。另一个持续存在的问题是，当项目结束时，在经过如此多的策略和设计之后，最终结果与原始设计完全不同，这不是出于好的原因。不是因为我们在演变架构，而是因为资金被削减了，出现了其他问题，或者存在非常大的误解，以至于在某个时候，团队必须在现有约束下工作。

这些模式的出现是因为技术专家在孤立的视角中运作。像许多其他学科一样，技术专家会从自己的角度看待我们的问题空间，考虑我们的责任，很少有机会像我们本可以做到的那样彻底地检查全局视角。

“现象”代表了每个人都能认识到存在的事件或情况，但人们对为什么会发生这种情况可能会有不同的意见。这些模式被称为“现实环境中的现象（phenomena in the wild）”，是反复出现的模式。同样适用于自然力量，这些力量通常以某种方式影响路径，团队必须找到接受、缓解或解决它们的方法。

共享厨房水槽现象

有一个俗语叫做“除了厨房水槽什么都有（everything but the kitchen sink）”，意思是你把各种各样的东西都塞进了你的包或行李箱里，里面除了厨房水槽什么都有。这种现象几乎在每个组织中都以工具库的形式出现。组织通常将这些库命名为“common”或使用公司名称。这是一个由公司所有服务使用的库，它的所有开发人员来自不同的团队，他们添加小功能以帮助彼此。

这种方法造成了多个严重的问题。第一个问题是，假设我们有一个每个人都贡献的库，如果这个库有问题，所有使用它的服务都是想象中最大爆炸半径的一部分。另一个问题是，如果来自不同团队的多个人不断添加小功能，你最终会得到一个非常大的库，而在某个时候，开发人员会失去对库内容的可见性。

它越大，参与协作的人越多，人们就越难重构它，以使其更有效、更灵活。这不可避免地增加了复杂性，增加了错误率，而且，通常情况下，每当有复杂性出现时，它就难以很好地测试。

两个主要的力量促成了这种现象：人员管理过程和相应的奖励系统。此外，糟糕的计划或交付压力也是促成因素。

职业框架通常包括看起来很合理的标准，这些标准却创造了错误的技术激励。人力资源部门和高级领导经常设计评估系统，通过“影响范围”来衡量工程成熟度，其中公司范围的影响表明比团队级贡献更高的成熟度。虽然概念上听起来合理，但这种影响驱使工程师通过向共享库和服务添加功能来操纵系统，允许他们在绩效评估中声称创建广泛的组织影响，而不是专注于适当的技术解决方案。

另一个驱动力是由于交付压力导致的糟糕计划。常见的短语如“我们需要明天之前完成”或“我们需要下周完成”创造了交付压力。然后，团队中的开发人员将别无选择，只能使用他们已经拥有的交付机制，即已经存在的这个库。

这两者代表了在实际上促使工具库形成的力量。背后的决策根本不是技术性的。不同的部门出于不同的原因做出决策，但它们对你的代码有非常直接的影响。

领域身份危机现象

组织经常创建一些共享领域库，这些库中包含了像 Customer 或 Order 这样的类，试图代表公司所有团队的核心业务实体。例如，一个 Customer 类可能需要满足市场团队（需要人口统计数据和活动偏好）、计费团队（需要支付历史和信用评分）、支持团队（需要工单历史和沟通偏好）以及物流团队（需要地址和交付偏好）。团队没有认识到它们是需要单独表示的不同限界上下文，而是将所有这些关注点塞进一个庞大的 Customer 类中。

这种方法违反了领域驱动设计的原则，因为它假设整个公司共享一个单一的领域模型。由此产生的膨胀类变得无法维护和修改。团队开始使用不同的术语来引用相同的概念，这提示他们对应该分开的领域表达了完全不同的观点。当人类的理解以这种方式分裂时，软件不可避免地无法正确地模拟它应该代表的业务现实。

当产品组织缺乏完全理解和沟通领域边界的成熟度时，这种现象就会出现。没有与产品团队适应的领域映射和沟通技巧，工程部门无法在代码中准确地表示业务现实。

缺乏专职业务分析师的团队会面临额外的挑战。业务分析师连接需求和开发团队，确保需求不重叠，并且捕获所有细节。当团队缺乏这个角色时，开发人员会将这些责任作为次要职责承担，由于时间限制和注意力分散，不可避免地产生较差的领域建模。

这现象的最强有力引发因素是组织设计在组建团队时忽视了领域边界。组织可能会根据技术而不是领域来分组服务，将两个 Java 服务分配给同一个团队，而其他团队使用不同的语言。虽然这种方法优化了资源流动，但它迫使团队将不同的领域视为统一的，导致他们将独立的业务领域建模成了代码中单一的领域。

太阳马戏团编码现象

太阳马戏团（Cirque du Soleil）以精湛的杂技表演而闻名。类似地，一些代码库展示了所谓的“太阳马戏团编码”，在这些实现中，简单的特性包含了所有可用的设计模式、库特性和外部依赖。这些解决方案优先展示技术范围，而不是确定最简单有效的方法。

这种过度工程模式造成了巨大的维护开销。复杂的解决方案在调试、修改和测试方面花费更多。结果代码变得更脆弱，团队难以理解，导致 bug 率增加，开发速度降低。在这种背景下，有种“酷文化”出现了，在该文化中，开发人员将技术成熟度与专业能力等同起来，促使工程师使用每一种可用的工具，而不是选择合适的解决方案。

职业框架通过包括像“从业者在公司的技术栈中非常熟练”的标准加剧了这个问题。当组织缺乏适当评估工程工作的技术深度时，开发人员通过在他们的拉取请求中创建复杂的技术演示来做出回应。这些演示允许开发人员在集中的例子中展示他们的知识广度，而不是分散在多个更简单的实现中。

有影响力的技术领导者无意中加强了这种模式。当高级工程师或架构师推广特定的库或方法时，团队将这些建议解释为命令。无意间的认可变成了普遍应用的组织标准，而不是符合上下文的标准。

有毒的组织文化加剧了这些动态。在开发人员感到需要不断证明自己能力的压力环境中，过度工程变成了一种防御机制。工程师创建不必要的复杂解决方案来展示他们的技术能力并确保他们在团队中的地位。

使无意识变得有意识

工程师经常避免承认组织的问题和变化超出了他们的直接技术责任。就像谚语所说的“三只聪明的猴子”一样，技术团队对不正常的模式闭上眼睛和耳朵，拒绝讨论不可避免地影响他们工作的力量。

Carl Jung 观察到：“当内部情况没有被意识到时，它就像宿命一样在外部发生”。工程师经常能够认识到他们公司内部的人类动态和组织问题，然而当项目运行延迟或偏离预定方向时，他们将这些结果归因于不可预见的情况，而不是可预测的组织力量。

Gloria Steinem 曾指出：“真相会让你自由，但它首先会激怒你。”技术团队经常意识到不正常的动态，但将其视为过于琐碎或不专业，无法纳入技术决策。他们认为，利益相关者的冲突、不协调的职业框架或有害的团队变动，都低于他们的专业标准。这种故意无视非技术力量的做法并不能消除它们的影响；它只是确保团队对不可避免的结果缺乏准备，这些结果直接体现在他们的代码体系结构和项目结果中。

整体工程

解决方案需要全面地审视问题。整体（holistic）这个词描述了一个构造，其组成部分代表整个有机体，如果不检查整个系统就无法正确理解。整体医学可以作为一个例子。当人们接受整体医学治疗时，从业者不仅要检查疾病和症状，还要检查整体健康状况。治疗考虑到疾病的完整背景，包括环境和生活方式因素。

在技术设计过程中，整体工程涉及考虑的因素不仅包括传统的技术因素，还包括所有其他非技术因素，这些因素无论如何都会影响你的系统。通过承认这些力量，团队可以将问题视为一个有机系统，并在某种程度上影响系统的各个组成部分。

你的项目如何位于多个系统的交汇处

外部力量

• 世界事件

• 商业变化和趋势

• 技术趋势

外部力量是组织控制之外的影响技术决策和项目结果的因素。这些力量在公司之外运作，但直接影响系统设计、架构选择和项目时间表。

影响技术决策的外部因素（用绿色表示）

构建电子商务系统的团队通常会考虑假日期间的支持能力。很少有团队考虑选举或监管变化会如何影响其项目的未来，尤其是在更大的战略项目的时间框架内。

商业趋势也提出了类似的挑战。如果没有了解产品在更广泛的商业背景中的位置，团队很难确定哪些组件会发生变化，哪些会保持稳定。了解哪些因素可能完全颠覆市场或摧毁产品对于优先考虑技术决策至关重要。

技术趋势是另一类外部力量，不过团队在做出架构决策时会更普遍地承认这些。

内部力量

• 组织

• 技术

• 产品

• 人员

内部力量是公司内部影响技术决策和项目结果的组织因素。与外部力量不同，团队可以潜在地影响、缓解或绕过内部力量，不过这些力量由于其制度性质通常感觉是不可改变的。

影响技术决策的内部因素（用绿色表示）

人员、产品和工程的三元组合会在一个预先存在的组织结构中运转。这种组织基础是在当前团队成员加入之前就已经建立起来的，并且可能在他们离开后继续存在。团队必须认识到他们的技术解决方案是建立在这个组织基础之上并受其约束的。

考虑组织中的实际信息结构。了解实际的工作流模式和沟通渠道可以揭示工作是如何真正完成的。这些通信模式通常与正式的层次结构有很大的不同。接下来，确定哪些过程会阻碍你的进度。例如，一些组织需要 20 个人的批准来决定版本发布，包括 CTO。

奖励系统、职业框架和奖金结构代表了在关键项目中时刻影响团队行为的强大内部力量。这些机制决定了个人工作的优先顺序，通常与最佳技术决策相冲突，但与个人发展目标一致。

产品

团队经常缺乏时间来检查超出其直接项目范围的产品需求。如果不了解完整的产品策略和公司的使命，团队就无法做出明智的决定，决定哪些功能将保持稳定，在哪里投入精力，以及什么可能会发生变化。这种局部项目需求和更广泛的产品方向之间的脱节严重影响了技术决策。市场营销策略可以揭示即将发生的变化，帮助团队预防架构问题。

人员

分析团队成员需要超越技术技能和角色数量。项目参与者的关键特征、他们的职业动机、对项目结果的个人投资，以及个人环境会直接影响项目的成功与否。人们可能会被分配到他们职业规划之外的项目，这会影响他们的敬业度和绩效。个人生活的变化，如关系变化、搬迁、家庭成员增加或求职，都会产生可用性和关注点的限制，需要特定的缓解策略。

工程

技术决策必须与公司的技术战略和能力保持一致。如果团队设计的解决方案在部署频率、回滚能力或架构复杂性方面超过了其组织的运维成熟度，就会创建公司无法维持的实现。产品质量、可观测系统和运维成熟度的路径直接限制了团队可以成功部署的架构。在项目后期处理安全和隐私需求时，通常会成为需要额外资金的障碍，并导致延迟。

将整体工程付诸实践

识别组织力量

每个组织都包含影响技术决策的功能失调模式。系统地识别这些力量使团队能够预测项目将在哪里遇到阻力、延迟或意外变更。该分析揭示了哪些技术方法将在现有的限制条件下取得成功，哪些技术方法需要组织变更才能有效地实施。

使隐性知识显性化

将关于组织功能失调的非正式观察转化为具体的文档。为通信模式建模，绘制实际的决策过程，并可视化工作如何在组织中流动。这些制品将非正式的观察转化为团队可以用于项目计划的可操作的情报。文档使以前看不见的力量可以测量和定位。

有组织地社会化信息

将力量分析分享给直接利益相关者之外的人，以创建组织范围内的共识。当功能失调成为一个公认的事实而不是私人知识时，它使组织内的协调改进工作成为可能。公开承认“我们的部署流程造成瓶颈”会将个人的挫败感转变为组织变革的使命。这种方法建立了解决根源而不是解决症状的联盟。

设计两种架构

创建一个理想的“北极星”架构和一个务实的当前状态解决方案。北极星代表了没有组织约束的最佳设计，而务实的设计则在现有限制内工作。这种双重方法提供了潜在和现实之间差距的具体证据，使人们能够就是否解决组织约束或接受技术妥协进行知情讨论。

定义演变路径

记录当前架构和理想架构之间的具体里程碑。这些过渡计划表明，务实的初始解决方案可以随着组织成熟度的提高而演变为更好的设计。清晰的演变路径防止团队永久性地满足于次优架构，同时为改进提供现实的时间表。这种方法将“我们希望我们能构建 X，但我们被困在 Y”转变为“我们现在正在构建 Y，以下是我们如何达到 X”。

结论

采用整体工程的组织能够以可预测的方式控制通常使技术项目脱轨的力量。团队不是对“不可预见”的延误和架构漂移做出反应，而是可以预测和计划那些不可避免地影响技术结果的组织约束。

整体工程将工程团队从组织功能失调的被动受害者转变为系统改进的积极伙伴。当团队明确组织力量并同时处理技术和人的因素时，他们创建了可持续的解决方案，这些解决方案在组织约束中茁壮成长，同时随着时间的推移逐渐改进这些约束。

另一种选择是可预测的：项目延误、架构漂移和技术解决方案的持续循环，这些解决方案在纸面上有效，但在组织现实中却以失败告终。

原文链接：

Holistic Engineering: Organic Problem Solving for Complex Evolving Systems