阿里蔡崇信說：我們知道阿里落後了，因為我們忘記了我們真正的客戶是誰。我們的客戶是使用我們的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（康威定律）成為現實。康威定律是指組織結構和它們所產出的系統設計之間的相互影響。 以下是文章的主要內容概述：
- 統一使用者體驗的挑戰：Spotify 的設計系統 Encore 採用了“本地系統”方法，允許不同的系統（如 Creator、Ads、Consumer 等）在共享基礎上構建，並提供定製化體驗。
- 支援體驗的統一：Spotify 採用逆向康威操作（Inverse Conway Maneuver），建立了一個團隊來統一跨本地細分市場的使用者支援體驗。該團隊構建了一個名為 Turnkey 的內部支援平臺，與 Encore 的方法相反，它將客戶支援工具泛化，減輕了每個本地細分市場實施和支援的負擔。
- 遷移到 Turnkey 的挑戰：在將 Creator Support 頁面遷移到 Turnkey 時，Spotify 面臨了一個挑戰，因為 Encore 和 Turnkey 對康威定律的不同處理方式。Spotify 希望在 Turnkey 系統中保持 MastheadHeader 和 MastheadFooter 元件的一致性，這些元件對於統一 Spotify for Artists 使用者體驗至關重要。
- 外觀模式的應用：為了解決這個問題，Spotify 使用了外觀模式，建立了 S4X-Masthead，這是一個定製的外觀模式，用於維護兩個系統之間 Masthead 元件的一致性。S4X-Masthead 匯出了三個 React 元件：MastheadHeader、MastheadFooter 和 MastheadProvider，目的是防止客戶端應用程式之間的程式碼重複和實現漂移。
- S4X-Masthead 的作用：這些元件集中管理了 Spotify for Artists 介面中的導航和實用操作，如語言選擇、登入/登出、連結到網站的不同區域、聯絡資訊和法律宣告等。MastheadProvider 用於向每個應用程式公開關鍵上下文，包括使用者會話和本地化偏好。
- 外觀模式的優勢：使用外觀模式可以清晰地溝通，因為它是一個已經建立得很好的概念，有豐富的參考資料。外觀模式提供了一個簡單介面，用於更復雜的子系統，減少了維護成本，降低了錯誤風險，並簡化了客戶端和實現類之間的依賴關係。
- 未來的考慮：儘管 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 共享第二多的標頭專案。我們追隨消費者應用程式的腳步，該應用程式也有標頭包。雖然這些專案的範圍存在一些重大差異，但要整合想法並進一步簡化，還有大量工作要做。