建站
咨詢
售后
建站咨詢
新聞中心
科技界的大多數(shù)新生事物都只是一波又一波的潮流：說話和做事的模式來了又走，沒有留下永恒的印記。微內(nèi)核，IA-64 架構(gòu)，對象請求代理，20 世紀(jì) 90 年代的神經(jīng)網(wǎng)絡(luò)，這些東西都已經(jīng)不復(fù)存在，也不會再回來了。時間已經(jīng)證明了哪些東西是曇花一現(xiàn)，為了說明問題，我們必須追溯到很久以前。
為高陵等地區(qū)用戶提供了全套網(wǎng)頁設(shè)計(jì)制作服務(wù)，及高陵網(wǎng)站建設(shè)行業(yè)解決方案。主營業(yè)務(wù)為網(wǎng)站制作、成都網(wǎng)站建設(shè)、高陵網(wǎng)站設(shè)計(jì)，以傳統(tǒng)方式定制建設(shè)網(wǎng)站，并提供域名空間備案等一條龍服務(wù)，秉承以專業(yè)、用心的態(tài)度為用戶提供真誠的服務(wù)。我們深信只要達(dá)到每一位用戶的要求，就會得到認(rèn)可，從而選擇與我們長期合作。這樣，我們也可以走得更遠(yuǎn)！
今天的我們很難想象，在鼎盛時期，那些技術(shù)有多么的受歡迎。它們有很多極具魅力、真誠且聰明的倡導(dǎo)者，倡導(dǎo)者們得到了看似合理的基本原理論證的支持，這些論證證明了他們選擇的技術(shù)必然會取得勝利。這些潮流催生了運(yùn)動、宣言、會議和公司。但請不要把這些潮流與蓄意欺詐混為一談，后者要少見得多。推動這些技術(shù)潮流的動機(jī)是發(fā)自內(nèi)心的真誠，不管它們以何種方式出場，二者產(chǎn)生的結(jié)果是完全不同的。
另一方面，一些重要的新技術(shù)是革命性的：它們強(qiáng)大而持久的變化為技術(shù)采用者帶來了長期的優(yōu)勢。面向?qū)ο缶幊?、硬件虛擬化、萬維網(wǎng)、公有云、CI/CD 和 20 世紀(jì) 90 年代的神經(jīng)網(wǎng)絡(luò)（深度學(xué)習(xí)的重生）現(xiàn)在成了計(jì)算機(jī)世界永久的組成部分，而它們曾經(jīng)“混跡”在潮流之中，難以區(qū)分。我們被技術(shù)浪潮所包圍，在它們展露頭角之前，我們并不知道如何用它們來獲得成功。
與其他科技公司一樣，Slack 希望在正確的時間采用革命性的技術(shù)，避免把過多的精力浪費(fèi)在追逐潮流上。Slack 采取了什么樣的戰(zhàn)略來確保做到這一點(diǎn)？這篇文章介紹了 Slack 用來解決這個問題的方法。
1. 區(qū)分潮流和革命
我們不能依靠個別領(lǐng)導(dǎo)者的直覺來區(qū)分哪個才是贏家。相反，我們要積極地探索新事物，雖然我們也知道這些嘗試大部分都不會有任何回報(bào)。但為了讓我們的投入偏向于有用的新事物，避免踩太多潮流的坑，我們應(yīng)該在早期就要無情地扼殺那些沒有價(jià)值的實(shí)驗(yàn)。我們希望每件事都去嘗試一下，這意味著我們?nèi)匀灰c潮流為伍。我們希望最終能夠乘著潮流到達(dá)彼岸，我們與潮流打交道的經(jīng)驗(yàn)不斷為我們提供積極的回報(bào)。
2. 技術(shù)采用曲線
我們創(chuàng)建了一個描述性的新技術(shù)采用曲線模型。
這是一條典型的 S 曲線，描述了技術(shù)的采用隨時間變化的情況。S 形反映了技術(shù)采用的變化。一開始，當(dāng)只有幾個實(shí)驗(yàn)者在做實(shí)驗(yàn)時，我們別無選擇，只能慢慢地接受。稍后，當(dāng)情況變得清晰的時候，就會有更多的人參與進(jìn)來，我們會在中間陡峭向上傾斜的部分快速地將新技術(shù)應(yīng)用到生產(chǎn)中。當(dāng)大多數(shù)有成果的試驗(yàn)圓滿完成，就會剩下寥寥無幾難啃的“硬骨頭”。于是，在周期接近結(jié)束時，采用速度又慢了下來。
我們把這三個階段畫出來：
我們并不是第一波發(fā)現(xiàn)技術(shù)采用遵循這種 S 型曲線的人。Everett Rogers 在 1962 年的《創(chuàng)新擴(kuò)散理論》（diffusion of innovation）一書中就已提出了這一模型。不過，Rogers 并沒有提到 Erlang 或者 MongoDB，因?yàn)樗且晃晦r(nóng)村社會學(xué)家，他觀察的是農(nóng)業(yè)技術(shù)采用的模式。但事實(shí)證明，計(jì)算機(jī)領(lǐng)域與人類活動的其他領(lǐng)域并沒有太大的不同。
為了讓這個抽象的概念更具象一些，我們將例舉一些已經(jīng)在 Slack 經(jīng)歷了探索、擴(kuò)張和遷移階段的技術(shù)。
3. React
從 2015 年發(fā)布第一個穩(wěn)定版本以來，React 席卷了前端開發(fā)領(lǐng)域。虛擬 DOM 和單向數(shù)據(jù)綁定讓它成為開發(fā) Slack 桌面用戶界面的一項(xiàng)引人注目的技術(shù)。
- 2016 年，對于 Slack 的前端開發(fā)來說，React 還只是一項(xiàng)陌生的技術(shù)。在第一階段，對 React 感興趣的工程師開始嘗試使用它，將它用在試驗(yàn)項(xiàng)目中。當(dāng)他們確信 React 可以為 Slack 帶來重要的價(jià)值時，他們開發(fā)了一個有說服力的演示項(xiàng)目，使用 React 重建了 Slack 的表情選擇器。這個使用 React 開發(fā)的 Slack UI（之前有延遲感）比之前表現(xiàn)得更好。原型比理論驗(yàn)證或白板草圖更容易讓開發(fā)者接受。
- 當(dāng)我們的團(tuán)隊(duì)意識到 React 將會對我們的代碼庫產(chǎn)生重大影響時，只是做一些零碎的小手術(shù)是無法讓 React 的性能優(yōu)勢得以體現(xiàn)的。但進(jìn)行大規(guī)模的重寫也是不可能的，因?yàn)轱L(fēng)險(xiǎn)與回報(bào)比不允許我們這么做。當(dāng) React 進(jìn)入第二階段，一個真正的遷移項(xiàng)目開始啟動了。項(xiàng)目制定了一個計(jì)劃，并配備了大量的開發(fā)人員。隨著項(xiàng)目的進(jìn)行，有很多團(tuán)隊(duì)也選擇了新的視圖樣式。但在這個中間階段，很多舊的視圖仍然存在，并需要維護(hù)。
- 在第三階段，我們將客戶端代碼庫中的遺留視圖清理干凈。我們終于在 2019 年 7 月發(fā)布了一個只使用 React 的桌面版 Slack。
4. Hack
在服務(wù)器端，我們從 2016 年開始從 PHP 遷移到 Hack。這次遷移的一個關(guān)鍵部分是在我們的 PHP 代碼中逐步引入類型：
- 在 2017 年，我們進(jìn)入了第一階段，一些類型愛好者開始在代碼庫中使用簡單的類型。
- 有些人在代碼進(jìn)入生產(chǎn)環(huán)境之前發(fā)現(xiàn)這些類型可以捕獲 bug，于是也開始使用類型。這無意中就讓 Hack 的類型系統(tǒng)進(jìn)入了第二階段（其他用戶也受到了影響）。不過，新的類型注釋也帶來了一些問題，于是我們展開了一場有關(guān)標(biāo)準(zhǔn)靜態(tài)類型與動態(tài)類型的討論。通過討論和積累經(jīng)驗(yàn)，我們達(dá)成了一個大致的共識——加大類型使用規(guī)模利大于弊，并且大多數(shù)團(tuán)隊(duì)都選擇使用類型。在第二階段，我們做出了更大的努力進(jìn)行代碼遷移，讓新加入的代碼可以使用靜態(tài)類型。
- 困難的部分留給了第三階段。對 Slack 自身的內(nèi)部對象變量進(jìn)行合理化調(diào)整，并對一些復(fù)雜的核心模塊進(jìn)行轉(zhuǎn)換，這些都是非常耗時的。
5. Vitess
Vitess 是一個用來進(jìn)行 MySQL 水平擴(kuò)展的集群系統(tǒng)，在進(jìn)行數(shù)據(jù)分片策略演化過程中，我們選擇了它。
- 第一階段開始時，我們對 Vitess 的能力進(jìn)行了嚴(yán)格的評審。我們花了很多時間在手動管理自有分片解決方案上，而 Vitess 的自動化能力解決了我們的大部分痛點(diǎn)。Vitess 團(tuán)隊(duì)最終確信這項(xiàng)技術(shù)是值得采用的。
- 將一些低風(fēng)險(xiǎn)的工作負(fù)載（如 RSS 提要）遷移到 Vitess 的工作始于第二階段。在第二階段早期不太需要 Vitess 團(tuán)隊(duì)之外的人參與，但因?yàn)槭且粋€新的數(shù)據(jù)存儲系統(tǒng)，所以仍然需要運(yùn)維支持。隨著越來越多的表被遷移到 Vitess，我們逐漸降低了風(fēng)險(xiǎn)，讓 Vitess 滿足了我們的應(yīng)用場景需求。我們開發(fā)了用于回填的工具，制定了一些在遷移過程中會用到的術(shù)語（例如把重復(fù)數(shù)據(jù)叫作“暗讀”），總結(jié)了可能會出現(xiàn)的各種問題。
- 我們已經(jīng)遷移了數(shù)百個表，總計(jì)超過了查詢工作負(fù)載的 50%，但在第三階段仍然要處理一些“難表”和“長尾表”。一些關(guān)鍵表存在復(fù)雜的依賴關(guān)系和查詢模式，它們比在第二階段遷移的表更難處理。另外，我們有一些“長尾表”，進(jìn)行逐張手動遷移很不值得，因此我們正在開發(fā)工具進(jìn)行批量遷移。
6. LibSlack
與以上那些經(jīng)歷了各個采用階段的技術(shù)相比，我們的跨平臺 C++ 客戶端庫并沒有走到第三階段，并且最終停止了。
- 在第一階段，LibSlack 工程師驗(yàn)證了業(yè)務(wù)邏輯和數(shù)據(jù)緩存可共享客戶端庫的概念，并深入開展了編譯和交付跨平臺庫的相關(guān)工作。
- 然而，該項(xiàng)目在第二階段并沒有取得進(jìn)展。庫與我們的桌面客戶端之間的技術(shù)和戰(zhàn)略不兼容性變得很明顯。事實(shí)證明，在我們的 iOS 和 Android 客戶端中使用 LibSlack 庫重新實(shí)現(xiàn)現(xiàn)有的邏輯和緩存會非常麻煩。不過，由于 Windows 手機(jī)的停產(chǎn)，Slack 需要維護(hù)的客戶代碼庫減少了一份。
到最后我們并沒有進(jìn)行全面的遷移。我們將從 LibSlack 中學(xué)到的東西以各種方式應(yīng)用到移動和桌面客戶端開發(fā)工作中。代碼工件并沒有被長期采用，但這個項(xiàng)目讓我們學(xué)會了應(yīng)該如何構(gòu)建客戶端以及如何組織我們的工程團(tuán)隊(duì)。
7. 曲線分析
需要注意的是，這個模型是描述性的，而不是說明性的。我們并不是想要強(qiáng)迫人們接受這個 S 型曲線，盡管我們想要這樣。實(shí)際上，這是一個自然的過程。早期的探索階段不可能像中期階段那樣迅速地進(jìn)行，最后的階段也不可能像中期階段那樣迅速地進(jìn)行全面采用。這三個階段并不是任何里程碑、過程、工具或 Slack 工程人員作用的結(jié)果。它們是技術(shù)變革的一部分，不管我們有沒有注意到它們，它們都會存在。
現(xiàn)在，我們已經(jīng)注意到了它們，我們可以利用它們，讓我們的努力更加卓有成效。每個階段的戰(zhàn)術(shù)和戰(zhàn)略是不一樣的。
8. 第一階段：探索
第一階段是無門檻進(jìn)入。當(dāng)工程師第一次開始調(diào)研他們感興趣的技術(shù)時，不需要任何許可授予過程或儀式。在 Slack，這樣的事情一天可能會發(fā)生幾十次：有人發(fā)現(xiàn)了新技術(shù)，或者發(fā)明了新東西，然后就開始研究它們。他們可能是因?yàn)樽x過關(guān)于 Elixir、Cassandra、WebAssembly 或 TCR 的博文，或者下載了一些軟件，編譯打包，四處看看，瀏覽一些介紹性的材料，還可能嘗試把它們應(yīng)用到日常工作中。
大多數(shù)的探索工作都在這個階段進(jìn)行。在這個階段，為了避免在不必要的事情上花費(fèi)太多精力，我們要懂得放棄掉一些東西。不過確實(shí)還是有一些東西被用到了實(shí)際的工作流程和代碼庫中。有時，工程師可以直接應(yīng)用某些解決方案，因?yàn)樗鼈兘鉀Q了一些局部問題。有時候會出現(xiàn)更加令人興奮的結(jié)果：某些解決方案也解決了其他團(tuán)隊(duì)所面臨的問題。這個階段的工程師相信他們知道一些其他人不知道的東西：一些事情可以用更好的方式來做。一旦他們的工作開始影響到其他人，我們就進(jìn)入了第二階段。
9. 第二階段：擴(kuò)張
進(jìn)入第二階段，工程師就有點(diǎn)可憐了！因?yàn)樗麄儸F(xiàn)在正試圖改變其他工程師的行為，這將涉及溝通、說服，如果一切進(jìn)行得順利的話，他們還需要做大量的技術(shù)工作。對于大多數(shù)項(xiàng)目來說，第二階段是最困難、最耗時、最令人沮喪的階段。在技術(shù)周期中，這是“產(chǎn)品與市場匹配”階段，很多進(jìn)入該階段的項(xiàng)目無法成功地走完這個階段。
在 Slack，用戶團(tuán)隊(duì)可以自由選擇是否要依賴你的系統(tǒng)，很少有例外。如果你習(xí)慣了“基礎(chǔ)設(shè)施驅(qū)動”的公司，那么我們的情況可能會讓你大吃一驚。在其他公司，領(lǐng)導(dǎo)層會在第二階段產(chǎn)品市場適應(yīng)得出結(jié)論之前就選出了贏家和輸家。他們之所以這么做，是為了提供清晰的信息（比如未來會怎樣、我們應(yīng)該采用哪個系統(tǒng)）和降低成本，因?yàn)樵谶@一階段需要支持更多的做事方式。
雖然這些都是合理的目標(biāo)，但 Slack 并沒有選擇這種方式。我們優(yōu)先考慮的是適應(yīng)潮流的能力，而不是適應(yīng)的速度。因此，我們（有意地）將促進(jìn)其他團(tuán)隊(duì)采用新技術(shù)的主要負(fù)擔(dān)放在了小部分人身上。雖然這可能會讓這些人感到沮喪，但我們知道沒有其他更好的辦法。為了清除這一障礙，我們不得不選擇更加有效的方法。如果新技術(shù)真的像我們所希望的那么美妙，那么它們應(yīng)該能夠幫助依賴它們的團(tuán)隊(duì)順利完成工作。反過來，這種結(jié)果會促使他們采用和推廣這些新技術(shù)。
第二階段的一些工作更像是產(chǎn)品工作，而不是工程工作。你需要研究用戶，以便確定哪些問題是重要的。你需要按照用戶所期望的方式將你的解決方案的價(jià)值與之前的實(shí)踐聯(lián)系起來。你需要想辦法縮小當(dāng)前實(shí)踐與你正在做出的改變之間的差距，讓用戶更容易接受。
在第二階段取得的成功最終會導(dǎo)致一些自發(fā)式的采用，用戶可以自由地選擇是否采用新技術(shù)。當(dāng)新系統(tǒng)成為事實(shí)上的標(biāo)準(zhǔn)，第二階段就接近尾聲了。偶然性地遇到這種采用情況是很不尋常的，因?yàn)檫@真的很難，而且并不是每個工程師都具備相關(guān)的技能。
10. 第三階段：遷移
自發(fā)式的采用最終會逐步減少，最后剩下一些頑固的人，他們似乎很抵制新的做事方式。一些后臺運(yùn)行的系統(tǒng)尤其沒有動力去做出改變，因?yàn)樗鼈兊拈_發(fā)度不夠活躍。在某些情況下，我們到了后期才發(fā)現(xiàn)一些舊系統(tǒng)在某些方面按照舊有方式運(yùn)行會更好。最后，總是會有一些頑固的用戶堅(jiān)持使用老方法。
雖然我們一直在討論“技術(shù)采用曲線”，但實(shí)際上在第三階段會出現(xiàn)一個分岔口。即使非常成功的項(xiàng)目也不可能徹底采用全新的技術(shù)。例如，在 Slack，我們已經(jīng)廣泛地采用 gRPC 作為內(nèi)部的 API 技術(shù)。但是，我們不太可能構(gòu)建一個全新的基于 gRPC 的 memcached。memcached 的自定義協(xié)議很不錯，并得到了客戶端的良好支持。這種例外并不意味著采用 gRPC 是失敗的。
對于其他一些情況，采用多種技術(shù)的成本（工程師的認(rèn)知負(fù)擔(dān)、運(yùn)行舊系統(tǒng)的負(fù)擔(dān)）太高，所以我們有必要徹底采用新技術(shù)。對于這樣的項(xiàng)目，我們需要制定一個應(yīng)對頑固派的計(jì)劃，不同的情況需要采用不同的策略。長時間沒有發(fā)生改動的系統(tǒng)可能需要使用代理，并逐步對其進(jìn)行遷移。如果頑固派的存在是因?yàn)樾孪到y(tǒng)缺乏必要的功能，那就需要增強(qiáng)新系統(tǒng)，或者對新系統(tǒng)進(jìn)行封裝，模擬舊系統(tǒng)的功能。
對于對舊系統(tǒng)產(chǎn)生了情感依戀的情況，進(jìn)行面對面的溝通通常比高風(fēng)險(xiǎn)的公開辯論有效得多。請溫柔些，如果你的新系統(tǒng)足夠成功，總有一天它也會成為舊系統(tǒng)。
11. 技術(shù)人的期望
作為 Slack 的工程師和工程負(fù)責(zé)人，我們對彼此的期望是什么呢?
- 首先，我們要去做一些探索工作。外面的世界很大，我們偶爾也要抬頭看看外面發(fā)生了什么。但沒有人可以做到探索一切，也沒有人可以做到一直在探索新事物。我們有對外部的承諾和內(nèi)部的路線圖，這些事情仍然具有高優(yōu)先級。不過，我們還是要分出一些能量用于探索新事物。
- 在成為其他團(tuán)隊(duì)技術(shù)產(chǎn)品的用戶時，我們要講道理。提供底層技術(shù)支持的團(tuán)隊(duì)需要將他們的系統(tǒng)向前推進(jìn)，有時候，這會給上層的用戶帶來成本。如果這種成本是不合理的，或者當(dāng)它朝著與你的團(tuán)隊(duì)需求相反的方向發(fā)展時，你需要以他們能夠理解的方式與他們溝通。
- 有時候，我們需要避免依賴無法滿足我們需求的底層技術(shù)。在設(shè)定團(tuán)隊(duì)技術(shù)發(fā)展方向時需要注意這一點(diǎn)。不過，這并意味著一定是他們做錯了什么，我們需要用成熟和專業(yè)的方式來應(yīng)對這種依賴分離。
- 當(dāng)我們試圖推動他人做出改變時，我們會對試圖理解和使用新系統(tǒng)的團(tuán)隊(duì)抱持以用戶為中心的態(tài)度。他們的快樂是你成功的唯一晴雨表，包括溝通、需求收集、反饋、迭代、有目的性的培訓(xùn)和技能分享。
如果有疑問，請記?。耗阋獙夹g(shù)采用的成功與否負(fù)責(zé)，而從長遠(yuǎn)來看，這是由你的產(chǎn)品的用戶來決定的。
分享名稱：在正確的時間采用革命性的技術(shù)，Slack技術(shù)演進(jìn)模式實(shí)錄
當(dāng)前地址：http://www.dlmjj.cn/article/ccisooi.html
