Cosmos系列博客第4部分：结果导向的关键思维

这是我四部分博客系列的第4部分，分享我们在优化Cosmos托管服务平台的人员、流程和技术方面的经验教训。

第4部分：结果导向的关键思维

在我之前的博客中，我讨论了我们的工程和产品团队如何转变构建Cosmos平台的方法，从而提高了功能开发的可扩展性、灵活性和速度。这些博客涵盖了我们的架构原则、结果导向和拥抱自动化。在本文中，我将介绍如何通过加强关键思维来进一步提升我们的开发速度。

在我的职业生涯中，我注意到一个趋势：许多人回避关键思维。我观察到三个主要原因：有些人认为自己已经在应用关键思维，但无法阐明其决策背后的推理（主观思维，事实未被完全了解）；另一些人认为关键思维会抑制创造力，并积极抵制基于实证基础的决策（创造力胜过事实）；第三类人根本没有接触过作为结构化方法的关键思维。

麻省理工斯隆管理学院将商业和工程中的关键思维描述为"评估信息和证据以做出逻辑、无偏见决策的纪律性过程。它要求质疑假设、挑战主流规范，并依赖数据和分析来指导结论。"

在Bishop Fox，我们通过排名排序以及持续测量、审查和改进工程实践等流程，将关键思维引入Cosmos平台开发。

我们在Bishop Fox实施关键思维的一个关键方面是从最终结果开始分析。同样，我们通过关注期望结果来处理架构决策。虽然这听起来很明显，但在实践中很少如此。当面临设计流程、服务或功能时，大多数人首先列出必要组件。他们对结果（成功标准）做出假设，并专注于他们认为需要协调的内容以及输入需要什么。

我认为这种输入优先的方法是一个错误。相反，我建议从期望的结果开始，而不是（假设的）输入。设计工作随后将生成一个高度灵活、响应迅速且可扩展的流程方法。通过从结果开始，我们可以轻松地回溯每个步骤，从而更有效地将每个服务与其他服务及先前步骤隔离开来。

当设计者、架构师和工程师从结果开始并向必要输入推进时，事件驱动、异步、小服务的方法自然出现。

相比之下，当我们采用输入导向方法时，经常会出现几个错误，包括紧耦合、编排代码、次级管理系统和主动请求。

输入导向方法的常见陷阱

紧耦合：紧耦合是指服务相互连接或依赖，一个服务的变更需要另一个服务的变更。当团队在设计和思维中仍遵循输入到结果的导向时，这种情况经常发生。虽然服务共享一种语言，但不应要求另一个特定服务的存在。

编排代码：另一个常见错误是团队在多个服务之间构建"如果/这个/那么/那个"逻辑。这个错误会导致"寻宝游戏"式的错误搜索，并使重要行为驻留在服务代码之外。如果系统的工作依赖于不在代码中的外部文档（或更糟的是口头历史），请评估并解决该问题。

用于主要服务管理的次级流程和服务：第三个错误在团队设计次级流程和服务仅为了确保主要流程正确运行时很明显。次级服务可能支持报告、监控等，但它们不应回退到主要服务并修改其行为或强制重放。

主动请求：最后，审查事件消息中使用的语言也可以揭示问题。如果消息从"我已经做了这个"转变为"我需要你做这个"，后者表明耦合增加了，需要进行审查以纠正。

通过采用基于结果的心态作为关键思维的基础要素，我们加快了团队交付新功能和能力的开发速度，并通过更好的设计最小化了代码量。