[[321589]]

科技界的大多數(shù)新生事物都只是一波又一波的潮流：說(shuō)話和做事的模式來(lái)了又走，沒(méi)有留下永恒的印記。微內(nèi)核，IA-64 架構(gòu)，對(duì)象請(qǐng)求代理，20 世紀(jì) 90 年代的神經(jīng)網(wǎng)絡(luò)，這些東西都已經(jīng)不復(fù)存在，也不會(huì)再回來(lái)了。時(shí)間已經(jīng)證明了哪些東西是曇花一現(xiàn)，為了說(shuō)明問(wèn)題，我們必須追溯到很久以前。

今天的我們很難想象，在鼎盛時(shí)期，那些技術(shù)有多么的受歡迎。它們有很多極具魅力、真誠(chéng)且聰明的倡導(dǎo)者，倡導(dǎo)者們得到了看似合理的基本原理論證的支持，這些論證證明了他們選擇的技術(shù)必然會(huì)取得勝利。這些潮流催生了運(yùn)動(dòng)、宣言、會(huì)議和公司。但請(qǐng)不要把這些潮流與蓄意欺詐混為一談，后者要少見得多。推動(dòng)這些技術(shù)潮流的動(dòng)機(jī)是發(fā)自內(nèi)心的真誠(chéng)，不管它們以何種方式出場(chǎng)，二者產(chǎn)生的結(jié)果是完全不同的。

另一方面，一些重要的新技術(shù)是革命性的：它們強(qiáng)大而持久的變化為技術(shù)采用者帶來(lái)了長(zhǎng)期的優(yōu)勢(shì)。面向?qū)ο缶幊?、硬件虛擬化、萬(wàn)維網(wǎng)、公有云、CI/CD 和 20 世紀(jì) 90 年代的神經(jīng)網(wǎng)絡(luò)（深度學(xué)習(xí)的重生）現(xiàn)在成了計(jì)算機(jī)世界永久的組成部分，而它們?cè)?jīng)“混跡”在潮流之中，難以區(qū)分。我們被技術(shù)浪潮所包圍，在它們展露頭角之前，我們并不知道如何用它們來(lái)獲得成功。

與其他科技公司一樣，Slack 希望在正確的時(shí)間采用革命性的技術(shù)，避免把過(guò)多的精力浪費(fèi)在追逐潮流上。Slack 采取了什么樣的戰(zhàn)略來(lái)確保做到這一點(diǎn)？這篇文章介紹了 Slack 用來(lái)解決這個(gè)問(wèn)題的方法。

1. 區(qū)分潮流和革命

我們不能依靠個(gè)別領(lǐng)導(dǎo)者的直覺(jué)來(lái)區(qū)分哪個(gè)才是贏家。相反，我們要積極地探索新事物，雖然我們也知道這些嘗試大部分都不會(huì)有任何回報(bào)。但為了讓我們的投入偏向于有用的新事物，避免踩太多潮流的坑，我們應(yīng)該在早期就要無(wú)情地扼殺那些沒(méi)有價(jià)值的實(shí)驗(yàn)。我們希望每件事都去嘗試一下，這意味著我們?nèi)匀灰c潮流為伍。我們希望最終能夠乘著潮流到達(dá)彼岸，我們與潮流打交道的經(jīng)驗(yàn)不斷為我們提供積極的回報(bào)。

2. 技術(shù)采用曲線

我們創(chuàng)建了一個(gè)描述性的新技術(shù)采用曲線模型。

這是一條典型的 S 曲線，描述了技術(shù)的采用隨時(shí)間變化的情況。S 形反映了技術(shù)采用的變化。一開始，當(dāng)只有幾個(gè)實(shí)驗(yàn)者在做實(shí)驗(yàn)時(shí)，我們別無(wú)選擇，只能慢慢地接受。稍后，當(dāng)情況變得清晰的時(shí)候，就會(huì)有更多的人參與進(jìn)來(lái)，我們會(huì)在中間陡峭向上傾斜的部分快速地將新技術(shù)應(yīng)用到生產(chǎn)中。當(dāng)大多數(shù)有成果的試驗(yàn)圓滿完成，就會(huì)剩下寥寥無(wú)幾難啃的“硬骨頭”。于是，在周期接近結(jié)束時(shí)，采用速度又慢了下來(lái)。

我們把這三個(gè)階段畫出來(lái)：

我們并不是第一波發(fā)現(xiàn)技術(shù)采用遵循這種 S 型曲線的人。Everett Rogers 在 1962 年的《創(chuàng)新擴(kuò)散理論》（diffusion of innovation）一書中就已提出了這一模型。不過(guò)，Rogers 并沒(méi)有提到 Erlang 或者 MongoDB，因?yàn)樗且晃晦r(nóng)村社會(huì)學(xué)家，他觀察的是農(nóng)業(yè)技術(shù)采用的模式。但事實(shí)證明，計(jì)算機(jī)領(lǐng)域與人類活動(dòng)的其他領(lǐng)域并沒(méi)有太大的不同。

為了讓這個(gè)抽象的概念更具象一些，我們將例舉一些已經(jīng)在 Slack 經(jīng)歷了探索、擴(kuò)張和遷移階段的技術(shù)。

3. React

從 2015 年發(fā)布第一個(gè)穩(wěn)定版本以來(lái)，React 席卷了前端開發(fā)領(lǐng)域。虛擬 DOM 和單向數(shù)據(jù)綁定讓它成為開發(fā) Slack 桌面用戶界面的一項(xiàng)引人注目的技術(shù)。

• 2016 年，對(duì)于 Slack 的前端開發(fā)來(lái)說(shuō)，React 還只是一項(xiàng)陌生的技術(shù)。在第一階段，對(duì) React 感興趣的工程師開始嘗試使用它，將它用在試驗(yàn)項(xiàng)目中。當(dāng)他們確信 React 可以為 Slack 帶來(lái)重要的價(jià)值時(shí)，他們開發(fā)了一個(gè)有說(shuō)服力的演示項(xiàng)目，使用 React 重建了 Slack 的表情選擇器。這個(gè)使用 React 開發(fā)的 Slack UI（之前有延遲感）比之前表現(xiàn)得更好。原型比理論驗(yàn)證或白板草圖更容易讓開發(fā)者接受。
• 當(dāng)我們的團(tuán)隊(duì)意識(shí)到 React 將會(huì)對(duì)我們的代碼庫(kù)產(chǎn)生重大影響時(shí)，只是做一些零碎的小手術(shù)是無(wú)法讓 React 的性能優(yōu)勢(shì)得以體現(xiàn)的。但進(jìn)行大規(guī)模的重寫也是不可能的，因?yàn)轱L(fēng)險(xiǎn)與回報(bào)比不允許我們這么做。當(dāng) React 進(jìn)入第二階段，一個(gè)真正的遷移項(xiàng)目開始啟動(dòng)了。項(xiàng)目制定了一個(gè)計(jì)劃，并配備了大量的開發(fā)人員。隨著項(xiàng)目的進(jìn)行，有很多團(tuán)隊(duì)也選擇了新的視圖樣式。但在這個(gè)中間階段，很多舊的視圖仍然存在，并需要維護(hù)。
• 在第三階段，我們將客戶端代碼庫(kù)中的遺留視圖清理干凈。我們終于在 2019 年 7 月發(fā)布了一個(gè)只使用 React 的桌面版 Slack。

4. Hack

在服務(wù)器端，我們從 2016 年開始從 PHP 遷移到 Hack。這次遷移的一個(gè)關(guān)鍵部分是在我們的 PHP 代碼中逐步引入類型：

• 在 2017 年，我們進(jìn)入了第一階段，一些類型愛好者開始在代碼庫(kù)中使用簡(jiǎn)單的類型。
• 有些人在代碼進(jìn)入生產(chǎn)環(huán)境之前發(fā)現(xiàn)這些類型可以捕獲 bug，于是也開始使用類型。這無(wú)意中就讓 Hack 的類型系統(tǒng)進(jìn)入了第二階段（其他用戶也受到了影響）。不過(guò)，新的類型注釋也帶來(lái)了一些問(wèn)題，于是我們展開了一場(chǎng)有關(guān)標(biāo)準(zhǔn)靜態(tài)類型與動(dòng)態(tài)類型的討論。通過(guò)討論和積累經(jīng)驗(yàn)，我們達(dá)成了一個(gè)大致的共識(shí)——加大類型使用規(guī)模利大于弊，并且大多數(shù)團(tuán)隊(duì)都選擇使用類型。在第二階段，我們做出了更大的努力進(jìn)行代碼遷移，讓新加入的代碼可以使用靜態(tài)類型。
• 困難的部分留給了第三階段。對(duì) Slack 自身的內(nèi)部對(duì)象變量進(jìn)行合理化調(diào)整，并對(duì)一些復(fù)雜的核心模塊進(jìn)行轉(zhuǎn)換，這些都是非常耗時(shí)的。

5. Vitess

Vitess 是一個(gè)用來(lái)進(jìn)行 MySQL 水平擴(kuò)展的集群系統(tǒng)，在進(jìn)行數(shù)據(jù)分片策略演化過(guò)程中，我們選擇了它。

• 第一階段開始時(shí)，我們對(duì) Vitess 的能力進(jìn)行了嚴(yán)格的評(píng)審。我們花了很多時(shí)間在手動(dòng)管理自有分片解決方案上，而 Vitess 的自動(dòng)化能力解決了我們的大部分痛點(diǎn)。Vitess 團(tuán)隊(duì)最終確信這項(xiàng)技術(shù)是值得采用的。
• 將一些低風(fēng)險(xiǎn)的工作負(fù)載（如 RSS 提要）遷移到 Vitess 的工作始于第二階段。在第二階段早期不太需要 Vitess 團(tuán)隊(duì)之外的人參與，但因?yàn)槭且粋€(gè)新的數(shù)據(jù)存儲(chǔ)系統(tǒng)，所以仍然需要運(yùn)維支持。隨著越來(lái)越多的表被遷移到 Vitess，我們逐漸降低了風(fēng)險(xiǎn)，讓 Vitess 滿足了我們的應(yīng)用場(chǎng)景需求。我們開發(fā)了用于回填的工具，制定了一些在遷移過(guò)程中會(huì)用到的術(shù)語(yǔ)（例如把重復(fù)數(shù)據(jù)叫作“暗讀”），總結(jié)了可能會(huì)出現(xiàn)的各種問(wèn)題。
• 我們已經(jīng)遷移了數(shù)百個(gè)表，總計(jì)超過(guò)了查詢工作負(fù)載的 50%，但在第三階段仍然要處理一些“難表”和“長(zhǎng)尾表”。一些關(guān)鍵表存在復(fù)雜的依賴關(guān)系和查詢模式，它們比在第二階段遷移的表更難處理。另外，我們有一些“長(zhǎng)尾表”，進(jìn)行逐張手動(dòng)遷移很不值得，因此我們正在開發(fā)工具進(jìn)行批量遷移。

6. LibSlack

與以上那些經(jīng)歷了各個(gè)采用階段的技術(shù)相比，我們的跨平臺(tái) C++ 客戶端庫(kù)并沒(méi)有走到第三階段，并且最終停止了。

• 在第一階段，LibSlack 工程師驗(yàn)證了業(yè)務(wù)邏輯和數(shù)據(jù)緩存可共享客戶端庫(kù)的概念，并深入開展了編譯和交付跨平臺(tái)庫(kù)的相關(guān)工作。
• 然而，該項(xiàng)目在第二階段并沒(méi)有取得進(jìn)展。庫(kù)與我們的桌面客戶端之間的技術(shù)和戰(zhàn)略不兼容性變得很明顯。事實(shí)證明，在我們的 iOS 和 Android 客戶端中使用 LibSlack 庫(kù)重新實(shí)現(xiàn)現(xiàn)有的邏輯和緩存會(huì)非常麻煩。不過(guò)，由于 Windows 手機(jī)的停產(chǎn)，Slack 需要維護(hù)的客戶代碼庫(kù)減少了一份。

到最后我們并沒(méi)有進(jìn)行全面的遷移。我們將從 LibSlack 中學(xué)到的東西以各種方式應(yīng)用到移動(dòng)和桌面客戶端開發(fā)工作中。代碼工件并沒(méi)有被長(zhǎng)期采用，但這個(gè)項(xiàng)目讓我們學(xué)會(huì)了應(yīng)該如何構(gòu)建客戶端以及如何組織我們的工程團(tuán)隊(duì)。

7. 曲線分析

需要注意的是，這個(gè)模型是描述性的，而不是說(shuō)明性的。我們并不是想要強(qiáng)迫人們接受這個(gè) S 型曲線，盡管我們想要這樣。實(shí)際上，這是一個(gè)自然的過(guò)程。早期的探索階段不可能像中期階段那樣迅速地進(jìn)行，最后的階段也不可能像中期階段那樣迅速地進(jìn)行全面采用。這三個(gè)階段并不是任何里程碑、過(guò)程、工具或 Slack 工程人員作用的結(jié)果。它們是技術(shù)變革的一部分，不管我們有沒(méi)有注意到它們，它們都會(huì)存在。

現(xiàn)在，我們已經(jīng)注意到了它們，我們可以利用它們，讓我們的努力更加卓有成效。每個(gè)階段的戰(zhàn)術(shù)和戰(zhàn)略是不一樣的。

8. 第一階段：探索

第一階段是無(wú)門檻進(jìn)入。當(dāng)工程師第一次開始調(diào)研他們感興趣的技術(shù)時(shí)，不需要任何許可授予過(guò)程或儀式。在 Slack，這樣的事情一天可能會(huì)發(fā)生幾十次：有人發(fā)現(xiàn)了新技術(shù)，或者發(fā)明了新東西，然后就開始研究它們。他們可能是因?yàn)樽x過(guò)關(guān)于 Elixir、Cassandra、WebAssembly 或 TCR 的博文，或者下載了一些軟件，編譯打包，四處看看，瀏覽一些介紹性的材料，還可能嘗試把它們應(yīng)用到日常工作中。

大多數(shù)的探索工作都在這個(gè)階段進(jìn)行。在這個(gè)階段，為了避免在不必要的事情上花費(fèi)太多精力，我們要懂得放棄掉一些東西。不過(guò)確實(shí)還是有一些東西被用到了實(shí)際的工作流程和代碼庫(kù)中。有時(shí)，工程師可以直接應(yīng)用某些解決方案，因?yàn)樗鼈兘鉀Q了一些局部問(wèn)題。有時(shí)候會(huì)出現(xiàn)更加令人興奮的結(jié)果：某些解決方案也解決了其他團(tuán)隊(duì)所面臨的問(wèn)題。這個(gè)階段的工程師相信他們知道一些其他人不知道的東西：一些事情可以用更好的方式來(lái)做。一旦他們的工作開始影響到其他人，我們就進(jìn)入了第二階段。

9. 第二階段：擴(kuò)張

進(jìn)入第二階段，工程師就有點(diǎn)可憐了！因?yàn)樗麄儸F(xiàn)在正試圖改變其他工程師的行為，這將涉及溝通、說(shuō)服，如果一切進(jìn)行得順利的話，他們還需要做大量的技術(shù)工作。對(duì)于大多數(shù)項(xiàng)目來(lái)說(shuō)，第二階段是最困難、最耗時(shí)、最令人沮喪的階段。在技術(shù)周期中，這是“產(chǎn)品與市場(chǎng)匹配”階段，很多進(jìn)入該階段的項(xiàng)目無(wú)法成功地走完這個(gè)階段。

在 Slack，用戶團(tuán)隊(duì)可以自由選擇是否要依賴你的系統(tǒng)，很少有例外。如果你習(xí)慣了“基礎(chǔ)設(shè)施驅(qū)動(dòng)”的公司，那么我們的情況可能會(huì)讓你大吃一驚。在其他公司，領(lǐng)導(dǎo)層會(huì)在第二階段產(chǎn)品市場(chǎng)適應(yīng)得出結(jié)論之前就選出了贏家和輸家。他們之所以這么做，是為了提供清晰的信息（比如未來(lái)會(huì)怎樣、我們應(yīng)該采用哪個(gè)系統(tǒng)）和降低成本，因?yàn)樵谶@一階段需要支持更多的做事方式。

雖然這些都是合理的目標(biāo)，但 Slack 并沒(méi)有選擇這種方式。我們優(yōu)先考慮的是適應(yīng)潮流的能力，而不是適應(yīng)的速度。因此，我們（有意地）將促進(jìn)其他團(tuán)隊(duì)采用新技術(shù)的主要負(fù)擔(dān)放在了小部分人身上。雖然這可能會(huì)讓這些人感到沮喪，但我們知道沒(méi)有其他更好的辦法。為了清除這一障礙，我們不得不選擇更加有效的方法。如果新技術(shù)真的像我們所希望的那么美妙，那么它們應(yīng)該能夠幫助依賴它們的團(tuán)隊(duì)順利完成工作。反過(guò)來(lái)，這種結(jié)果會(huì)促使他們采用和推廣這些新技術(shù)。

第二階段的一些工作更像是產(chǎn)品工作，而不是工程工作。你需要研究用戶，以便確定哪些問(wèn)題是重要的。你需要按照用戶所期望的方式將你的解決方案的價(jià)值與之前的實(shí)踐聯(lián)系起來(lái)。你需要想辦法縮小當(dāng)前實(shí)踐與你正在做出的改變之間的差距，讓用戶更容易接受。

在第二階段取得的成功最終會(huì)導(dǎo)致一些自發(fā)式的采用，用戶可以自由地選擇是否采用新技術(shù)。當(dāng)新系統(tǒng)成為事實(shí)上的標(biāo)準(zhǔn)，第二階段就接近尾聲了。偶然性地遇到這種采用情況是很不尋常的，因?yàn)檫@真的很難，而且并不是每個(gè)工程師都具備相關(guān)的技能。

10. 第三階段：遷移

自發(fā)式的采用最終會(huì)逐步減少，最后剩下一些頑固的人，他們似乎很抵制新的做事方式。一些后臺(tái)運(yùn)行的系統(tǒng)尤其沒(méi)有動(dòng)力去做出改變，因?yàn)樗鼈兊拈_發(fā)度不夠活躍。在某些情況下，我們到了后期才發(fā)現(xiàn)一些舊系統(tǒng)在某些方面按照舊有方式運(yùn)行會(huì)更好。最后，總是會(huì)有一些頑固的用戶堅(jiān)持使用老方法。

雖然我們一直在討論“技術(shù)采用曲線”，但實(shí)際上在第三階段會(huì)出現(xiàn)一個(gè)分岔口。即使非常成功的項(xiàng)目也不可能徹底采用全新的技術(shù)。例如，在 Slack，我們已經(jīng)廣泛地采用 gRPC 作為內(nèi)部的 API 技術(shù)。但是，我們不太可能構(gòu)建一個(gè)全新的基于 gRPC 的 memcached。memcached 的自定義協(xié)議很不錯(cuò)，并得到了客戶端的良好支持。這種例外并不意味著采用 gRPC 是失敗的。

對(duì)于其他一些情況，采用多種技術(shù)的成本（工程師的認(rèn)知負(fù)擔(dān)、運(yùn)行舊系統(tǒng)的負(fù)擔(dān)）太高，所以我們有必要徹底采用新技術(shù)。對(duì)于這樣的項(xiàng)目，我們需要制定一個(gè)應(yīng)對(duì)頑固派的計(jì)劃，不同的情況需要采用不同的策略。長(zhǎng)時(shí)間沒(méi)有發(fā)生改動(dòng)的系統(tǒng)可能需要使用代理，并逐步對(duì)其進(jìn)行遷移。如果頑固派的存在是因?yàn)樾孪到y(tǒng)缺乏必要的功能，那就需要增強(qiáng)新系統(tǒng)，或者對(duì)新系統(tǒng)進(jìn)行封裝，模擬舊系統(tǒng)的功能。

對(duì)于對(duì)舊系統(tǒng)產(chǎn)生了情感依戀的情況，進(jìn)行面對(duì)面的溝通通常比高風(fēng)險(xiǎn)的公開辯論有效得多。請(qǐng)溫柔些，如果你的新系統(tǒng)足夠成功，總有一天它也會(huì)成為舊系統(tǒng)。

11. 技術(shù)人的期望

作為 Slack 的工程師和工程負(fù)責(zé)人，我們對(duì)彼此的期望是什么呢?

• 首先，我們要去做一些探索工作。外面的世界很大，我們偶爾也要抬頭看看外面發(fā)生了什么。但沒(méi)有人可以做到探索一切，也沒(méi)有人可以做到一直在探索新事物。我們有對(duì)外部的承諾和內(nèi)部的路線圖，這些事情仍然具有高優(yōu)先級(jí)。不過(guò)，我們還是要分出一些能量用于探索新事物。
• 在成為其他團(tuán)隊(duì)技術(shù)產(chǎn)品的用戶時(shí)，我們要講道理。提供底層技術(shù)支持的團(tuán)隊(duì)需要將他們的系統(tǒng)向前推進(jìn)，有時(shí)候，這會(huì)給上層的用戶帶來(lái)成本。如果這種成本是不合理的，或者當(dāng)它朝著與你的團(tuán)隊(duì)需求相反的方向發(fā)展時(shí)，你需要以他們能夠理解的方式與他們溝通。
• 有時(shí)候，我們需要避免依賴無(wú)法滿足我們需求的底層技術(shù)。在設(shè)定團(tuán)隊(duì)技術(shù)發(fā)展方向時(shí)需要注意這一點(diǎn)。不過(guò)，這并意味著一定是他們做錯(cuò)了什么，我們需要用成熟和專業(yè)的方式來(lái)應(yīng)對(duì)這種依賴分離。
• 當(dāng)我們?cè)噲D推動(dòng)他人做出改變時(shí)，我們會(huì)對(duì)試圖理解和使用新系統(tǒng)的團(tuán)隊(duì)抱持以用戶為中心的態(tài)度。他們的快樂(lè)是你成功的唯一晴雨表，包括溝通、需求收集、反饋、迭代、有目的性的培訓(xùn)和技能分享。

如果有疑問(wèn)，請(qǐng)記?。耗阋獙?duì)技術(shù)采用的成功與否負(fù)責(zé)，而從長(zhǎng)遠(yuǎn)來(lái)看，這是由你的產(chǎn)品的用戶來(lái)決定的。