技術選型指南

這是一篇綜合類技術選型指南，試圖為你提供一份比較通用的技術選型思維框架。當你需要進行技術選型時，可以參照它來設計自己的決策樹。這其中你需要考慮的主要維度包括目標產品、目標用戶、目標團隊和技術本身，下面我將分別細述，并在此基礎上介紹一些反模式。

維度

這是最重要的維度。產品本身的特征將影響技術選型時的很多因素。

短生命周期產品和長生命周期產品

短生命周期的產品通常要求快速起步：門檻低、書寫自由、不強制遵循任何最佳實踐。當它的使命結束時，代碼會被直接拋棄。所以，對于這類產品，“快糙猛”的技術是較好的選擇，當然，能做到“快精猛”更佳。

而長生命周期的產品則會強烈要求可維護性，因為它們在很長時間內都是不可報廢的。甚至對于一些生命線產品，連重寫都會要求在重寫期間線上系統平穩過渡，一點點遷移到新技術。

這種要求對團隊的工程化能力是個極端的考驗。如果沒有相應的工程能力，其代價甚至會高于用新技術重新寫一個功能相同的系統。

探索型的產品和守成型的產品

探索型產品往往也是短周期產品，但是同時也有自己的特點。它要求快速，但往往同時會要求高質量。探索型的產品如果證明了可行性，那么過渡到長生命周期的可能性很大。

這就要求它最好是一個微內核系統，提前留出一些擴展的空間。當然，設計微內核系統對架構師的能力具有相當的考驗，如果沒有一個優秀的架構師，建議還是不要刻意做任何預留，優先保障系統的簡單性。

除此之外，探索型產品的技術棧必須支持可靠的、自動化的重構。因為探索型產品的迭代速度很快，如果完全靠人工去添加功能并手動重構，那么一旦出現 BUG，將給此產品的用戶體驗帶來嚴重的負面影響。

所以，除非由于人才儲備等原因而被迫做出折中，否則探索型產品的技術棧一定要快速而嚴謹。

當然，“大力出奇跡”定律也是成立的。也就是說，如果你有決心也有力量在將來對這個探索型產品進行徹底的重寫，那么采用快糙猛的技術快速把它搭建起來，也未嘗不可。如果你的業務確實能如預期般爆發，那么只要把重點放在系統延展性等方面即可；但是如果不能如預期般爆發，可能就會導致維護成本在中期開始飆升，在競爭中處于劣勢。這是一種“不成功便成仁”的策略。據我所知某獨角獸企業就是在業務起來之后通過巨額投入來償還技術債的。但這對于 CTO 的技術直覺是一項極大的考驗，不要輕易效仿。

而對守成型產品的選型則會側重于與現有技術棧的相似程度和無縫整合能力。如果整合時需要借助很多技巧，那么可能你就是在給自己挖坑。

在引入新技術的過程中，要盡可能符合現有的開發流程、基礎設施和開發習慣。當然，如果現有的這些已經嚴重過時，那么應該找新老技術的專家，共同幫你設計一個路線圖，讓你可以平穩地引入新技術，這份投資絕對值得。如果老技術已經有新版本，則應該優先考慮升級它。不要幻想換個技術棧就能解決一切問題，事實上，它帶來的問題往往會更多。

邊緣產品和生命線產品

在人員的學習能力和意愿允許的前提下，邊緣產品是最佳的試驗場，適合探索各種候選技術，試驗各種激進方案，積累經驗教訓。其影響范圍可控，即使失控也不會帶來太大的損失。當然，即使探索，也應該有計劃地探索，不要每個邊緣產品都采用不同的技術方案，那樣會給人才供應帶來巨大的挑戰。

而生命線產品則應該穩妥優先，采用保守方案。所以應該優先采用團隊內部積累了一定經驗或具有穩定的強力外援的技術。

所有的生命線產品幾乎必然是長周期產品，所以其可維護性同樣是重中之重。

產品維度總結

在目標產品維度上，低價值產品優先考慮門檻低的技術，但是高價值產品應該盡早進行投資性技術積累，優先考慮天花板高的技術，這樣才不至于在若干年之后被迫重寫。如果工程化能力不足，這種重寫往往會成為災難。

用戶的特點對于技術選型具有顯著的影響，甚至可能會導致產品不可用。

瀏覽器版本

在前端領域，瀏覽器版本是永遠的痛，但這是需要權衡的。高版本瀏覽器甚至是單一的低版本瀏覽器會顯著節省開發成本，但是可能會損失一些用戶。該怎么解決呢？當然不能拍腦袋決定。

如果你們已經有同領域的線上系統，那么應該統計這些線上系統的訪問情況，得出一個最準確的、針對目標客戶群的統計，然后分析一下不同版本的瀏覽器有多大價值，有沒有可能通過非技術手段讓用戶使用你們的目標瀏覽器。即使沒有線上系統，也可以隨機對目標用戶群發一些調查問卷，確定他們的實際使用情況，以及安裝新版瀏覽器的可能性。

下下之策是查一下百度公布的全網瀏覽器數據，然后說“我們要支持某某瀏覽器，它還有 10% 市場占有率呢！”，這是懶。

用戶帶寬

同樣是前端領域，文件的下載體積可能會被一些人當做亮點進行宣傳，但是你要清楚，現在已經是 4G 時代了，更不用說很多企業內部應用都是千兆帶寬。就算能比候選技術小 100k，在 4G 帶寬下（假設現實帶寬是 2MB/s）也就是 100 毫秒，有誰能感覺到這部分差異？這就是一個明顯的“誤導讀者”的例子。

可訪問性

在產品的用戶群體中，不但有健康人，還有色盲以及盲人等殘疾人。特別是對于面向消費者的產品，盡可能的考慮這些人的需求不但能體現出產品的“人文關懷”，而且也在一定程度上擴大客戶群。比如蘋果和微軟等大公司都把可訪問性放在了核心位置。如果你決定要實現可訪問性，那么就應該把它作為一項需求，納入到選型時要考慮的因素中。

之所以要把它納入到技術選型過程中，是因為添加可訪問性支持的代價比較高，而很多第三方庫并沒有提供這方面的支持。所以應該提早考慮。

國際化

與可訪問性相似，國際化也是一個后期添加代價比較高，但很多候選技術卻沒有提供支持的特性。

如果你的產品在預期生命周期的相當一段時間內需要供多語言用戶使用，那么，在初期選型時，就要把候選技術的國際化能力和質量納入你的主要考量。

訪問頻度

用戶的訪問頻度對前后端的技術選型都有很大影響。

比如說一個一年只用一次的功能，考慮其性能很可能是沒有必要的，在一小時內跑完和在一分鐘內跑完往往沒有顯著的價值差異。但是這兩種技術方案卻可能有著硬盤占用、編程復雜性、運維復雜性等方面的成本差異。你需要考慮：那種能在一分鐘內跑完的技術是否能給你帶來足夠的價值。

對于前端來說，頻繁訪問的、面向消費者的應用通常會要求更高的流暢度，那么在技術選型時，就要選擇流暢度更高的技術。但是這個流暢度一定要設計一個仿真的場景，親自驗證一下，甚至做一些灰度發布在現實場景下進行驗證，而不要只看其官網宣稱的流暢度。比如阿里的閑魚團隊就對 Flutter 技術進行了長時間的灰度驗證，最終替換成了完全使用 Flutter 的版本，堪稱對新技術進行選型的模范。

用戶維度總結

要特別小心，不要根據錯誤的、片面的信息作出決策。很多第三方的技術選型指南背后都有著它們自己的場景，但大多數都不會給你寫清楚，有的甚至復雜到想給你寫清楚都做不到。甚至有些選型指南還有著強烈的主觀立場，為了證明自己的預設立場甚至不惜造假。所以，你要先清點出你們的產品最應該重視的那些指標，然后拿這些指標對候選技術進行可行性測試，甚至為此專門開啟一些 SPIKE 項目，而不要迷信第三方選型指南。

目標團隊的因素確實很重要，但并不像你認為的那么重要。除非你的人才供應真的有問題（難道不應該先反思一下是不是錢給少了？），否則應該優先考慮提升團隊能力，而不是削足適履。

技術背景

目標團隊的技術背景對新技術的選型確實很重要，但是沒必要去精確匹配。

比如 Java 團隊要做前端，選擇 GWT 看似很好，但 GWT 也有自己的問題，幾乎完全無法利用前端生態。他們更好的選擇可能是 Angular：從語言上，TypeScript 跟 Java 有諸多相似之處；從架構模式上，對 MVC 的理解稍微往前推一步就是 Angular 的 MVVM 模式；從特性上，依賴注入不要太熟悉；從生態上，你可以自由決定是否使用前端生態，取長補短。

同樣，前端團隊如果打算自己寫 BFF，也不一定非要在 Node 生態下打轉。你完全可以使用 Java 世界的 Reactor 或者 WebFlux 進行響應式編程。這樣可以和后端的其它 Java 體系更好地進行集成，并減少運維的復雜度。

團隊規模

團隊規模可能是團隊維度中對技術選型影響最大的因素。

四位開發人員以下的小規模團隊，如果大家都很專業，那么其溝通成本就很低，在技術選型上可以更傾向于選擇靈活的技術，因為較高的人員能力和較低的溝通成本，可以讓靈活的框架更好地發揮其作用，最終更加高效、高質量的推出產品。這種場景通常出現在由牛人組成的創業團隊中。

如果開發人員經驗不足或者做事不夠專業，就需要更強的約束，特別是對于職場新鮮人，在早期養成好的開發習慣是非常重要的。而開發習慣中最重要的一點就是：約束 —— 知道不該做什么。這時候，偏向自由的技術可能會一時爽，但最終會構筑一個玻璃天花板，導致遲遲無法突破到下一個層次。

如果團隊規模過大，那么首要的選擇是用 DDD 等宏觀技術把問題域細分，使其可以被小規模團隊承接。如果暫時還做不到，就要考慮建設完善的基礎設施和交付紀律，來為團隊協作提供自動化保障。如果這些都做不到，就應該選擇強約束性的具體技術，讓大家避免犯錯，或者盡早發現錯誤。在爭取到時間之后，再逐漸深入化解根本性原因。

組織架構

康威定律深刻地影響著很多方面，技術選型也不例外。特別是做宏觀技術選型時，必須考慮它在最終技術架構中的位置，以及與團隊溝通結構的匹配程度。即使是一項很先進的技術，假如它與體系中的其它技術棧不匹配，也可能導致翻車。

當選擇多個第三方庫的時候更要加倍小心，因為它們開發時互相不知道彼此的存在，特別是對于一些較新的技術，可能都沒人把它們搭配使用過。

除了開發架構之外，還要考慮更廣泛的運維架構。假如你們引入了 DevOps，可能這個問題會得到一定程度的緩解。假如沒有，那就要充分考慮上下游環節的人員能力和配套設施是否完備。比如如果運維部門缺乏 NodeJS 運維技能，就不要盲目引入基于 NodeJS 的后端，一定要拿到他們“我能”的承諾之后再開始。

除非你是個前后端 + DevOps 全棧，否則就需要盡早對組織架構方面的因素進行驗證并排除風險。也就是說，在一個可控的演習環境中，用一個小型案例，完整地走一遍開發、上線、發新版的流程。在這個過程中，一些顯著的風險將會暴露出來，要評估其影響，來決定如何選型。

人員流動性

人員流動帶來的損失比大多數人所認為的要大得多。人員流動會帶走知識和文化。企業要避免損失，就要把這些知識和文化盡可能記錄在代碼中。

當然，這并不意味著應該要求大量寫注釋，而應該使用那些能留存知識的技術，比如類型系統和規范化命名。類型系統和規范化命名可以半強制性地要求開發人員把原本只存在于自己腦子里的知識記錄到代碼中。如果更有追求一點，可以再嘗試普及單元測試。這樣，當他離開的時候，即使沒有文檔，這些知識也仍然能留存下來。從效果上說，代碼往往比文檔和注釋更好。

而文化的留存則更加困難，事實上，代碼中的奇葩注釋往往留存的是負面文化。應該在代碼中留存的文化，是嚴謹、專業的工作態度。雖然自由也是文化的一部分，甚至在管理領域是非常值得向往的文化，但在工程領域，它往往是一種負面文化，因為軟件開發領域并沒有公認的法律甚至道德。你可以想象一下管理領域中沒有約束的自由會導致怎樣的后果。

所以，要想應對人員流動的風險，除非你有信心留存知識與文化，否則就應該在技術選型時，傾向于選擇更加嚴謹的、隱式信息更少的技術。

團隊維度總結

鞋子好不好，只有腳知道。錯誤的選型，也只能由團隊自身來承受。阿波羅神廟上鐫刻著一句警世名言——了解你自己。所以，請先客觀認識自己的團隊，然后再據此進行選型，千萬不要懶于思考，盲從潮流。

對技術本身的考量，主要是代入其它維度之后，看其匹配程度。

技術本身在選型中可能反而是最不重要的一個維度。這些年的歷史早已證明：優秀的技術未必能流行起來；很多技術的流行，也并非是由于其優秀。

明確的定位

一項優秀的技術，應該有其明確的定位和發展路線。這些定位能清楚地表明自己要做什么、不做什么。而其發展路線應該至少有一年以上的提前規劃，而且在定位上要能與其前輩做出有效區隔，而不是亦步亦趨，沒有自己的特長。

代碼質量

雖然流行的未必優秀，優秀的也未必流行，但技術選型不是趕時髦。所以，在條件允許的情況下，還是應該盡可能選擇優秀的技術。代碼質量高的技術，將來技術本身由于維護成本飆升而被放棄的可能性也較小。

衡量代碼質量的標準有很多，其中最常用、也比較有效的是單元測試的覆蓋率。而那些從一開始就具有比較完備的單元測試的代碼庫，往往優于后補測試的代碼庫。因為這證明的是開發組的工程化能力和意識，而這些是該技術長期可維護性的根本保障。當然，除非該技術特別復雜或應用場景的容錯性特別小，否則也不必苛求超過 90% 的覆蓋率。

維護團隊

維護團隊的規模和能力，對于一項技術在長跑中的表現非常重要。在歷史上如流星般劃過的技術數不勝數，但最終能長期留下來的卻不多。維護一項技術的成本遠高于創建它，所以如果沒有一個健康、可持續的商業模式，一個像 Linus 那樣的志愿者，以及一個愿意出錢的超級大金主，那么它在未來的競爭中落敗只是遲早的事。除非這項技術的需求集足夠小而穩定，否則這些因素缺一不可。

社區

社區的質量，決定著這項技術長遠的未來，一些草根型技術的隱患就在于此。如果社區人員的素質過低，喜歡無原則的站隊，而不能理性的對該技術提出尖銳的意見甚至批評，那么這個社區遲早會衰落。這類社區有一個顯著地特征就是喜歡宣揚它“包治百病”，也就是說它適合一切場景，而不會先問你一些問題再決定是否要推薦給你。另一個特征就是喜歡通過刻意選取某些標準來做出片面的對比，這種行為在學術界屬于學術造假行為，但在我們工業界卻被習以為常，這不能不說是我們的悲哀。

好的社區應該是一個君子社區。他們會自覺遵守共同的、理性的行為規范。會把精力放在對技術本身做貢獻，而不是通過詭辯、群毆等手段來攻擊競爭技術。社區的主要領導者會對社區的不良行為提出批評、做出約束，甚至為社區成員的不良行為道歉，而不是放任不管。

技術維度總結

不要把技術看得太重。對所有的主觀性宣傳文章，留一些心眼，多問一句——那缺點呢？將來決定你們是否會掉在坑里的，就是它的缺點。

對于功利社區，請務必小心；對于君子社區，請自覺維護。

反模式

有一些技術選型策略可能會導致災難性的失敗，這些選型中存在一些共同的反模式，比如：

人云亦云，盲目聽信外人或者某些布道師的主觀性言論，這就是輿論驅動選型。它往往會帶來災難。

做任何決策時，如果要借助參考資料，請記住：最重要的不是它告訴了你什么，而是它對你隱瞞了什么，這些隱瞞的信息最終會置你于險境。

即使是調查報告之類的客觀參考資料，也需要了解其背景。比如一份只發給程序員的調查報告，可能會發現 Chrome 的使用率超過了 99%，但顯然它對你的面向普通用戶的產品毫無價值，只會給你帶來風險。同時，要注意很多調查報告的設計是有主觀傾向性的，甚至題目的排列順序都會給最終結果帶來 10% 以上的偏差。所以，一定要仔細分析其中立性、客觀性以及調查對象在你的目標場景下的代表性。

根據任何一個單一指標進行選型都會給你帶來災難，更何況很多指標并不適合作為選型的依據。

當然，有一些客觀指標還是比較適合作為主要指標來使用的，但也不要盲目相信數字。比如單元測試中覆蓋率較高的項目，確實通常質量比較好，但是我也見過一些只有調用卻沒有斷言的測試，那些測試的覆蓋率也會很高，但卻是假的。所以，如果要評估其質量，最好還是親自打開看一看。

即使你選出了一些主要指標，并且確信它們沒有造假，也仍然不能簡單地把它們加起來或加權平均來得出一個數字進行比較。你要綜合評估這些指標對你的目標產品、目標用戶、目標團隊的價值。如果技術選型只是個數字游戲，那還要你干嘛？

這幾乎是最糟的選型，但卻屢見不鮮。技術棧的更迭往往會帶來話語權的變化，而這將給公司帶來災難。

對于高級技術決策者，需要有戰略定力，應該以一種規范的、用事實說話的方式來控制技術選型的副作用。我曾見過一幫程序員“偷襲珍珠港”導致架構師被迫辭職的慘劇，我當時的意見是：這是 CTO 的鍋。團隊由于選擇技術棧而產生了話語權之爭，說明制度設計和文化建設出了大問題，這只能由 CTO 背鍋。

所以，如果你是個技術決策者，那么應該盡早站出來，發揮你的職權和非職權影響力，抑制這些負面文化，而不是任由其發展，最終破壞公司的總體技術路線，甚至技術氛圍。

對于生命線產品，最糟糕的選型莫過于粉絲驅動選型了，這次可沒有“幾乎”。對于技術人員來講，最重要的特質是客觀冷靜，這樣才能配得上“專業”二字。而拜大神，當作玩笑尚可，如果讓它影響到你的決策，那么你就應該趁早隱退了，免得將來被迫引咎辭職。

雖然也曾被人稱作“大神”，但我一般會提出反對，至少不作正面回應。我已工作二十多年，太清楚業界百態了。實際上，很少有人真的配得上大神的稱號，舉世可能只有 Anders Hejlsberg、Bob 大叔、Martin Fowler、Jeff Dean 等少數幾位。不過我相信如果你當面叫他們大神，他們也會反感的。

就算是對于這些舉世公認的大神，也不應該成為你技術選型的依據，頂多是相信他們會珍惜名譽、不會粗制濫造而已，因為即使是精品也仍然有著明確的適用范圍，超出這個范圍它也可能會成為毒藥。

當然，對于邊緣產品，進行粉絲驅動選型也未嘗不可，甚至可能更好。只是得記住，要做就請做好，別給你的偶像丟臉，更不要做好之后就覺得公司一定要把它應用于生命線產品中。

決策樹

如果我在這篇文章的最后部分給你一棵決策樹，你會不會很高興？

很抱歉，寫這一章的目的，就是為了告訴你：我不會給你任何決策樹。請根據我提供的思維框架，自行設計適合你們自己的決策樹，及時更新它，并且不要盲目相信量化的評估結果。

運維 web前端

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。