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

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

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

在我的职业生涯中，我注意到一个趋势：许多人避免关键思维。我观察到三个主要原因。有些人认为他们已经应用了关键思维，但无法阐明他们提议决策背后的推理（主观思维，事实未完全已知）。其他人认为关键思维扼杀创造力，并积极抵制提议决策的经验基础（创造力胜过事实）。第三组人根本没有接触过关键思维作为一种结构化方法。

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

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

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

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

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

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

输入导向方法的常见陷阱

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

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

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

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

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