阿里落后的最大原因找到了？

阿里蔡崇信说：我们知道阿里落后了，因为我们忘记了我们真正的客户是谁。我们的客户是使用我们的app进行购物的人，而我们没有给他们最好的体验。

软件工程中的康威定理 提供了启发：
为何阿里 淘宝的app用户体验不好？是因为被划分一个个小团队在无意之中拼凑出支离破碎的用户体验。

• 康威定理是指人员组织结构决定了技术结构，人员被划分成一个个小团队，这些小团队开发出一个个零碎的功能，最后集成拼凑给用户。
• 但是，大型组织中有大量开发人员，如果人员不被划分进入团队又无法管理，但是划分了造成：每个人就陷入每个团队的上下文 限制中。
• 如何划分团队？通过团队拓扑 来影响技术架构，从而实现更好地用户体验？
• 大型组织需要从最终用户消费端把控，无论功能多么强大，但是用户难以使用，显然无法发挥强大的功能。
• 这属于分而合的问题。
• 今日头条评论

他山之石：Spotify在用户体验设计中实现外观Facade模式
在 Spotify，我们致力于为客户提供统一的体验：但是这有时会与我们庞大、自主的工程组织结构相冲突。为了防止 "康威定律 "成为现实，我们必须保持警惕：确保我们分散在不同地域的团队不会无意中创造出支离破碎的用户体验。

那么，我们该如何协调这些看似对立的概念呢？

从视觉角度来看：

• 我们的设计系统 Encore 采用了 "本地系统 "方法，使各个系统（创作者、广告、消费者等）建立在共享的基础上。
• 但同时，Encore 也为他们提供了灵活性，使他们能够针对每个本地客户群提供定制化的体验。

从支持的角度来看，我们最近采用了 "反康威策略"（Inverse Conway Maneuver），成立了一个团队来统一各本地细分市场的支持体验。该团队建立了一个名为 "Turnkey "的内部支持平台，采用了与安可为相反的方法。该平台将客户支持工具通用化，从而消除了为每个本地分部实施和提供支持的负担。

在将 "创作者支持 "页面迁移到 Turnkey 的过程中，我们遇到了一个意想不到的挑战，这是因为康威定律的两种方法存在差异。在迁移之前，我们的支持页面与 Spotify for Artists 主页放在一起。这包括我们的 MastheadHeader 和 MastheadFooter 组件，它们是统一 Spotify for Artists 用户体验的关键。我们希望这些组件在 Turnkey 系统中保持一致，但我们也假定所有其他 "本地细分市场 "的用户也希望如此。

为了解决这个问题，我们采用了门面facade模式，即 "为子系统的更多通用设施提供单一、简化的接口"，并创建了我们自己的迭代版本 S4X-Masthead，以保持这两个系统的 Masthead 组件之间的一致性。

概述
这篇文章是 Spotify 工程团队在 2024 年 2 月 7 日发表的，主题是关于如何在 Spotify for Artists 平台应用外观模式（Facade Pattern）。文章讨论了 Spotify 如何在其庞大的、自治的工程组织结构中提供统一的用户体验，并避免 Conway's Law（康威定律）成为现实。康威定律是指组织结构和它们所产出的系统设计之间的相互影响。 以下是文章的主要内容概述：

1. 统一用户体验的挑战：Spotify 的设计系统 Encore 采用了“本地系统”方法，允许不同的系统（如 Creator、Ads、Consumer 等）在共享基础上构建，并提供定制化体验。
2. 支持体验的统一：Spotify 采用逆向康威操作（Inverse Conway Maneuver），创建了一个团队来统一跨本地细分市场的用户支持体验。该团队构建了一个名为 Turnkey 的内部支持平台，与 Encore 的方法相反，它将客户支持工具泛化，减轻了每个本地细分市场实施和支持的负担。
3. 迁移到 Turnkey 的挑战：在将 Creator Support 页面迁移到 Turnkey 时，Spotify 面临了一个挑战，因为 Encore 和 Turnkey 对康威定律的不同处理方式。Spotify 希望在 Turnkey 系统中保持 MastheadHeader 和 MastheadFooter 组件的一致性，这些组件对于统一 Spotify for Artists 用户体验至关重要。
4. 外观模式的应用：为了解决这个问题，Spotify 使用了外观模式，创建了 S4X-Masthead，这是一个定制的外观模式，用于维护两个系统之间 Masthead 组件的一致性。S4X-Masthead 导出了三个 React 组件：MastheadHeader、MastheadFooter 和 MastheadProvider，目的是防止客户端应用程序之间的代码重复和实现漂移。
5. S4X-Masthead 的作用：这些组件集中管理了 Spotify for Artists 界面中的导航和实用操作，如语言选择、登录/登出、链接到网站的不同区域、联系信息和法律声明等。MastheadProvider 用于向每个应用程序公开关键上下文，包括用户会话和本地化偏好。
6. 外观模式的优势：使用外观模式可以清晰地沟通，因为它是一个已经建立得很好的概念，有丰富的参考资料。外观模式提供了一个简单接口，用于更复杂的子系统，减少了维护成本，降低了错误风险，并简化了客户端和实现类之间的依赖关系。
7. 未来的考虑：尽管 S4X-Masthead 是朝着正确方向迈出的一步，但项目的未来仍有更多的工作要做。Spotify 计划进一步合并这两个项目的想法，以简化系统。

外观模式前：S4X-Masthead
S4X-Masthead 输出了三个 React 组件：MastheadHeader、MastheadFooter 和 MastheadProvider。这些组件的目的是防止客户端应用程序之间的重复和漂移。通过集中这些元素，我们可以保持用户体验的一致性，例如在一个地方修复错误或进行设计更改，而不是将更改级联到 Spotify for Artists 的所有子界面。

• MastheadHeader 和 MastheadFooter 是用户界面组件，可在每个 Spotify for Artists 表面共同提供各种导航和实用操作。其中包括语言选择、登录/注销、网站不同区域的链接、联系信息和法律免责声明等元素。
• MastheadProvider 用于向每个应用程序公开一些关键上下文，包括用户会话和本地化首选项。这些数据来自 MastheadHeader 和 MastheadFooter 组件中的操作，但也可以在应用程序页面中使用。

随着消费者数量的增加，协调变更的沟通成本也会呈指数级增长。

利用Facade模式
使用像 "门面"（facade）模式这样的成熟模式的好处之一是，它能让交流变得清晰明了。在实现和文档方面，已经有大量的资料可供参考。细节争论的摩擦力要大得多。

正如门面模式的发明者所描述的那样，该模式 "为子系统中更通用的设施提供了一个单一、简化的接口"。他们说，这种模式通常在三种情况下使用：

• 你想为复杂的子系统提供一个简单的接口。
• 客户与抽象实现类之间存在许多依赖关系。
• 想将子系统分层。

只有简洁了才能更好低集成，这一点在构建跨团队的系统时非常重要，因为随着消费者数量的增加，协调变更的沟通成本也会呈指数级增长。虽然我们的系统只有两个团队，但他们在组织层次结构中彼此相距甚远，这就导致成本增加。

facade模式提供的这种简洁性对于保持一致的用户体验是不可或缺的。

为复杂的子系统提供简单的接口：

1、降低维护成本
对于像 S4X-Masthead 这样的外观，客户端系统必须维护的唯一变化就是版本更新。由于内容是在运行时通过我们的 CMS 动态提供的，因此这仅限于底层组件或其设计的结构更改。动态交付的内容包括翻译后的副本、菜单内容和图像资源。

2、降低错误风险
简单的设计更容易理解，理解可以防止错误。通过抽象获得单个集成点、使用标准 Spotify Web 库堆栈并实现众所周知的设计模式（外观）可以简化系统。这种简化降低了理解障碍，从而降低了犯错误的风险。

3、 抽象的客户端和实现类之间存在许多依赖关系。
S4X-Masthead 减少了客户端管理的依赖项数量。它们不是直接与第三方翻译服务集成，也不是让团队手动同步 UI 并将更改复制到标头，而是作为单一依赖项交付给客户端。

4、 对子系统进行分层。
S4X-Masthead 与组件的 CMS 集成。 CMS 通过另一个第三方服务处理翻译。如果将来实施细节发生变化，S4X-Masthead 可以进行更改，并且可能不需要下游客户端知道。

虽然这是朝着正确方向迈出的一步，但该项目的未来仍有更多工作要做。首先，我们的 S4X-Masthead 是 Spotify 共享第二多的标头项目。我们追随消费者应用程序的脚步，该应用程序也有标头包。虽然这些项目的范围存在一些重大差异，但要整合想法并进一步简化，还有大量工作要做。