技术选型指南
這是一篇綜合類技術(shù)選型指南，試圖為你提供一份比較通用的技術(shù)選型思維框架。當(dāng)你需要進(jìn)行技術(shù)選型時(shí)，可以參照它來設(shè)計(jì)自己的決策樹。這其中你需要考慮的主要維度包括目標(biāo)產(chǎn)品、目標(biāo)用戶、目標(biāo)團(tuán)隊(duì)和技術(shù)本身，下面我將分別細(xì)述，并在此基礎(chǔ)上介紹一些反模式。
維度
目標(biāo)產(chǎn)品
這是最重要的維度。產(chǎn)品本身的特征將影響技術(shù)選型時(shí)的很多因素。
短生命周期產(chǎn)品和長生命周期產(chǎn)品
短生命周期的產(chǎn)品通常要求快速起步：門檻低、書寫自由、不強(qiáng)制遵循任何最佳實(shí)踐。當(dāng)它的使命結(jié)束時(shí)，代碼會被直接拋棄。所以，對于這類產(chǎn)品，“快糙猛”的技術(shù)是較好的選擇，當(dāng)然，能做到“快精猛”更佳。
而長生命周期的產(chǎn)品則會強(qiáng)烈要求可維護(hù)性，因?yàn)樗鼈冊诤荛L時(shí)間內(nèi)都是不可報(bào)廢的。甚至對于一些生命線產(chǎn)品，連重寫都會要求在重寫期間線上系統(tǒng)平穩(wěn)過渡，一點(diǎn)點(diǎn)遷移到新技術(shù)。
這種要求對團(tuán)隊(duì)的工程化能力是個(gè)極端的考驗(yàn)。如果沒有相應(yīng)的工程能力，其代價(jià)甚至?xí)哂谟眯录夹g(shù)重新寫一個(gè)功能相同的系統(tǒng)。
探索型的產(chǎn)品和守成型的產(chǎn)品
探索型產(chǎn)品往往也是短周期產(chǎn)品，但是同時(shí)也有自己的特點(diǎn)。它要求快速，但往往同時(shí)會要求高質(zhì)量。探索型的產(chǎn)品如果證明了可行性，那么過渡到長生命周期的可能性很大。
這就要求它最好是一個(gè)微內(nèi)核系統(tǒng)，提前留出一些擴(kuò)展的空間。當(dāng)然，設(shè)計(jì)微內(nèi)核系統(tǒng)對架構(gòu)師的能力具有相當(dāng)?shù)目简?yàn)，如果沒有一個(gè)優(yōu)秀的架構(gòu)師，建議還是不要刻意做任何預(yù)留，優(yōu)先保障系統(tǒng)的簡單性。
除此之外，探索型產(chǎn)品的技術(shù)棧必須支持可靠的、自動(dòng)化的重構(gòu)。因?yàn)樘剿餍彤a(chǎn)品的迭代速度很快，如果完全靠人工去添加功能并手動(dòng)重構(gòu)，那么一旦出現(xiàn) BUG，將給此產(chǎn)品的用戶體驗(yàn)帶來嚴(yán)重的負(fù)面影響。
所以，除非由于人才儲備等原因而被迫做出折中，否則探索型產(chǎn)品的技術(shù)棧一定要快速而嚴(yán)謹(jǐn)。
當(dāng)然，“大力出奇跡”定律也是成立的。也就是說，如果你有決心也有力量在將來對這個(gè)探索型產(chǎn)品進(jìn)行徹底的重寫，那么采用快糙猛的技術(shù)快速把它搭建起來，也未嘗不可。如果你的業(yè)務(wù)確實(shí)能如預(yù)期般爆發(fā)，那么只要把重點(diǎn)放在系統(tǒng)延展性等方面即可；但是如果不能如預(yù)期般爆發(fā)，可能就會導(dǎo)致維護(hù)成本在中期開始飆升，在競爭中處于劣勢。這是一種“不成功便成仁”的策略。據(jù)我所知某獨(dú)角獸企業(yè)就是在業(yè)務(wù)起來之后通過巨額投入來償還技術(shù)債的。但這對于 CTO 的技術(shù)直覺是一項(xiàng)極大的考驗(yàn)，不要輕易效仿。
而對守成型產(chǎn)品的選型則會側(cè)重于與現(xiàn)有技術(shù)棧的相似程度和無縫整合能力。如果整合時(shí)需要借助很多技巧，那么可能你就是在給自己挖坑。
在引入新技術(shù)的過程中，要盡可能符合現(xiàn)有的開發(fā)流程、基礎(chǔ)設(shè)施和開發(fā)習(xí)慣。當(dāng)然，如果現(xiàn)有的這些已經(jīng)嚴(yán)重過時(shí)，那么應(yīng)該找新老技術(shù)的專家，共同幫你設(shè)計(jì)一個(gè)路線圖，讓你可以平穩(wěn)地引入新技術(shù)，這份投資絕對值得。如果老技術(shù)已經(jīng)有新版本，則應(yīng)該優(yōu)先考慮升級它。不要幻想換個(gè)技術(shù)棧就能解決一切問題，事實(shí)上，它帶來的問題往往會更多。
邊緣產(chǎn)品和生命線產(chǎn)品
在人員的學(xué)習(xí)能力和意愿允許的前提下，邊緣產(chǎn)品是最佳的試驗(yàn)場，適合探索各種候選技術(shù)，試驗(yàn)各種激進(jìn)方案，積累經(jīng)驗(yàn)教訓(xùn)。其影響范圍可控，即使失控也不會帶來太大的損失。當(dāng)然，即使探索，也應(yīng)該有計(jì)劃地探索，不要每個(gè)邊緣產(chǎn)品都采用不同的技術(shù)方案，那樣會給人才供應(yīng)帶來巨大的挑戰(zhàn)。
而生命線產(chǎn)品則應(yīng)該穩(wěn)妥優(yōu)先，采用保守方案。所以應(yīng)該優(yōu)先采用團(tuán)隊(duì)內(nèi)部積累了一定經(jīng)驗(yàn)或具有穩(wěn)定的強(qiáng)力外援的技術(shù)。
所有的生命線產(chǎn)品幾乎必然是長周期產(chǎn)品，所以其可維護(hù)性同樣是重中之重。
產(chǎn)品維度總結(jié)
在目標(biāo)產(chǎn)品維度上，低價(jià)值產(chǎn)品優(yōu)先考慮門檻低的技術(shù)，但是高價(jià)值產(chǎn)品應(yīng)該盡早進(jìn)行投資性技術(shù)積累，優(yōu)先考慮天花板高的技術(shù)，這樣才不至于在若干年之后被迫重寫。如果工程化能力不足，這種重寫往往會成為災(zāi)難。
目標(biāo)用戶
用戶的特點(diǎn)對于技術(shù)選型具有顯著的影響，甚至可能會導(dǎo)致產(chǎn)品不可用。
瀏覽器版本
在前端領(lǐng)域，瀏覽器版本是永遠(yuǎn)的痛，但這是需要權(quán)衡的。高版本瀏覽器甚至是單一的低版本瀏覽器會顯著節(jié)省開發(fā)成本，但是可能會損失一些用戶。該怎么解決呢？當(dāng)然不能拍腦袋決定。
如果你們已經(jīng)有同領(lǐng)域的線上系統(tǒng)，那么應(yīng)該統(tǒng)計(jì)這些線上系統(tǒng)的訪問情況，得出一個(gè)最準(zhǔn)確的、針對目標(biāo)客戶群的統(tǒng)計(jì)，然后分析一下不同版本的瀏覽器有多大價(jià)值，有沒有可能通過非技術(shù)手段讓用戶使用你們的目標(biāo)瀏覽器。即使沒有線上系統(tǒng)，也可以隨機(jī)對目標(biāo)用戶群發(fā)一些調(diào)查問卷，確定他們的實(shí)際使用情況，以及安裝新版瀏覽器的可能性。
下下之策是查一下百度公布的全網(wǎng)瀏覽器數(shù)據(jù)，然后說“我們要支持某某瀏覽器，它還有 10% 市場占有率呢！”，這是懶。
用戶帶寬
同樣是前端領(lǐng)域，文件的下載體積可能會被一些人當(dāng)做亮點(diǎn)進(jìn)行宣傳，但是你要清楚，現(xiàn)在已經(jīng)是 4G 時(shí)代了，更不用說很多企業(yè)內(nèi)部應(yīng)用都是千兆帶寬。就算能比候選技術(shù)小 100k，在 4G 帶寬下（假設(shè)現(xiàn)實(shí)帶寬是 2MB/s）也就是 100 毫秒，有誰能感覺到這部分差異？ 這就是一個(gè)明顯的“誤導(dǎo)讀者”的例子。
可訪問性
在產(chǎn)品的用戶群體中，不但有健康人，還有色盲以及盲人等殘疾人。特別是對于面向消費(fèi)者的產(chǎn)品，盡可能的考慮這些人的需求不但能體現(xiàn)出產(chǎn)品的“人文關(guān)懷”，而且也在一定程度上擴(kuò)大客戶群。比如蘋果和微軟等大公司都把可訪問性放在了核心位置。如果你決定要實(shí)現(xiàn)可訪問性，那么就應(yīng)該把它作為一項(xiàng)需求，納入到選型時(shí)要考慮的因素中。
之所以要把它納入到技術(shù)選型過程中，是因?yàn)樘砑涌稍L問性支持的代價(jià)比較高，而很多第三方庫并沒有提供這方面的支持。所以應(yīng)該提早考慮。
國際化
與可訪問性相似，國際化也是一個(gè)后期添加代價(jià)比較高，但很多候選技術(shù)卻沒有提供支持的特性。
如果你的產(chǎn)品在預(yù)期生命周期的相當(dāng)一段時(shí)間內(nèi)需要供多語言用戶使用，那么，在初期選型時(shí)，就要把候選技術(shù)的國際化能力和質(zhì)量納入你的主要考量。
訪問頻度
用戶的訪問頻度對前后端的技術(shù)選型都有很大影響。
比如說一個(gè)一年只用一次的功能，考慮其性能很可能是沒有必要的，在一小時(shí)內(nèi)跑完和在一分鐘內(nèi)跑完往往沒有顯著的價(jià)值差異。但是這兩種技術(shù)方案卻可能有著硬盤占用、編程復(fù)雜性、運(yùn)維復(fù)雜性等方面的成本差異。你需要考慮：那種能在一分鐘內(nèi)跑完的技術(shù)是否能給你帶來足夠的價(jià)值。
對于前端來說，頻繁訪問的、面向消費(fèi)者的應(yīng)用通常會要求更高的流暢度，那么在技術(shù)選型時(shí)，就要選擇流暢度更高的技術(shù)。但是這個(gè)流暢度一定要設(shè)計(jì)一個(gè)仿真的場景，親自驗(yàn)證一下，甚至做一些灰度發(fā)布在現(xiàn)實(shí)場景下進(jìn)行驗(yàn)證，而不要只看其官網(wǎng)宣稱的流暢度。比如阿里的閑魚團(tuán)隊(duì)就對 Flutter 技術(shù)進(jìn)行了長時(shí)間的灰度驗(yàn)證，最終替換成了完全使用 Flutter 的版本，堪稱對新技術(shù)進(jìn)行選型的模范。
用戶維度總結(jié)
要特別小心，不要根據(jù)錯(cuò)誤的、片面的信息作出決策。很多第三方的技術(shù)選型指南背后都有著它們自己的場景，但大多數(shù)都不會給你寫清楚，有的甚至復(fù)雜到想給你寫清楚都做不到。甚至有些選型指南還有著強(qiáng)烈的主觀立場，為了證明自己的預(yù)設(shè)立場甚至不惜造假。所以，你要先清點(diǎn)出你們的產(chǎn)品最應(yīng)該重視的那些指標(biāo)，然后拿這些指標(biāo)對候選技術(shù)進(jìn)行可行性測試，甚至為此專門開啟一些 SPIKE 項(xiàng)目，而不要迷信第三方選型指南。
目標(biāo)團(tuán)隊(duì)
目標(biāo)團(tuán)隊(duì)的因素確實(shí)很重要，但并不像你認(rèn)為的那么重要。除非你的人才供應(yīng)真的有問題（難道不應(yīng)該先反思一下是不是錢給少了？），否則應(yīng)該優(yōu)先考慮提升團(tuán)隊(duì)能力，而不是削足適履。
技術(shù)背景
目標(biāo)團(tuán)隊(duì)的技術(shù)背景對新技術(shù)的選型確實(shí)很重要，但是沒必要去精確匹配。
比如 Java 團(tuán)隊(duì)要做前端，選擇 GWT 看似很好，但 GWT 也有自己的問題，幾乎完全無法利用前端生態(tài)。他們更好的選擇可能是 Angular：從語言上，TypeScript 跟 Java 有諸多相似之處；從架構(gòu)模式上，對 MVC 的理解稍微往前推一步就是 Angular 的 MVVM 模式；從特性上，依賴注入不要太熟悉；從生態(tài)上，你可以自由決定是否使用前端生態(tài)，取長補(bǔ)短。
同樣，前端團(tuán)隊(duì)如果打算自己寫 BFF，也不一定非要在 Node 生態(tài)下打轉(zhuǎn)。你完全可以使用 Java 世界的 Reactor 或者 WebFlux 進(jìn)行響應(yīng)式編程。這樣可以和后端的其它 Java 體系更好地進(jìn)行集成，并減少運(yùn)維的復(fù)雜度。
團(tuán)隊(duì)規(guī)模
團(tuán)隊(duì)規(guī)?？赡苁菆F(tuán)隊(duì)維度中對技術(shù)選型影響最大的因素。
四位開發(fā)人員以下的小規(guī)模團(tuán)隊(duì)，如果大家都很專業(yè)，那么其溝通成本就很低，在技術(shù)選型上可以更傾向于選擇靈活的技術(shù)，因?yàn)檩^高的人員能力和較低的溝通成本，可以讓靈活的框架更好地發(fā)揮其作用，最終更加高效、高質(zhì)量的推出產(chǎn)品。這種場景通常出現(xiàn)在由牛人組成的創(chuàng)業(yè)團(tuán)隊(duì)中。
如果開發(fā)人員經(jīng)驗(yàn)不足或者做事不夠?qū)I(yè)，就需要更強(qiáng)的約束，特別是對于職場新鮮人，在早期養(yǎng)成好的開發(fā)習(xí)慣是非常重要的。而開發(fā)習(xí)慣中最重要的一點(diǎn)就是：約束 —— 知道不該做什么。這時(shí)候，偏向自由的技術(shù)可能會一時(shí)爽，但最終會構(gòu)筑一個(gè)玻璃天花板，導(dǎo)致遲遲無法突破到下一個(gè)層次。
如果團(tuán)隊(duì)規(guī)模過大，那么首要的選擇是用 DDD 等宏觀技術(shù)把問題域細(xì)分，使其可以被小規(guī)模團(tuán)隊(duì)承接。如果暫時(shí)還做不到，就要考慮建設(shè)完善的基礎(chǔ)設(shè)施和交付紀(jì)律，來為團(tuán)隊(duì)協(xié)作提供自動(dòng)化保障。如果這些都做不到，就應(yīng)該選擇強(qiáng)約束性的具體技術(shù)，讓大家避免犯錯(cuò)，或者盡早發(fā)現(xiàn)錯(cuò)誤。在爭取到時(shí)間之后，再逐漸深入化解根本性原因。
組織架構(gòu)
康威定律深刻地影響著很多方面，技術(shù)選型也不例外。特別是做宏觀技術(shù)選型時(shí)，必須考慮它在最終技術(shù)架構(gòu)中的位置，以及與團(tuán)隊(duì)溝通結(jié)構(gòu)的匹配程度。即使是一項(xiàng)很先進(jìn)的技術(shù)，假如它與體系中的其它技術(shù)棧不匹配，也可能導(dǎo)致翻車。
當(dāng)選擇多個(gè)第三方庫的時(shí)候更要加倍小心，因?yàn)樗鼈冮_發(fā)時(shí)互相不知道彼此的存在，特別是對于一些較新的技術(shù)，可能都沒人把它們搭配使用過。
除了開發(fā)架構(gòu)之外，還要考慮更廣泛的運(yùn)維架構(gòu)。假如你們引入了 DevOps，可能這個(gè)問題會得到一定程度的緩解。假如沒有，那就要充分考慮上下游環(huán)節(jié)的人員能力和配套設(shè)施是否完備。比如如果運(yùn)維部門缺乏 NodeJS 運(yùn)維技能，就不要盲目引入基于 NodeJS 的后端，一定要拿到他們“我能”的承諾之后再開始。
除非你是個(gè)前后端 + DevOps 全棧，否則就需要盡早對組織架構(gòu)方面的因素進(jìn)行驗(yàn)證并排除風(fēng)險(xiǎn)。也就是說，在一個(gè)可控的演習(xí)環(huán)境中，用一個(gè)小型案例，完整地走一遍開發(fā)、上線、發(fā)新版的流程。在這個(gè)過程中，一些顯著的風(fēng)險(xiǎn)將會暴露出來，要評估其影響，來決定如何選型。
人員流動(dòng)性
人員流動(dòng)帶來的損失比大多數(shù)人所認(rèn)為的要大得多。人員流動(dòng)會帶走知識和文化。企業(yè)要避免損失，就要把這些知識和文化盡可能記錄在代碼中。
當(dāng)然，這并不意味著應(yīng)該要求大量寫注釋，而應(yīng)該使用那些能留存知識的技術(shù)，比如類型系統(tǒng)和規(guī)范化命名。類型系統(tǒng)和規(guī)范化命名可以半強(qiáng)制性地要求開發(fā)人員把原本只存在于自己腦子里的知識記錄到代碼中。如果更有追求一點(diǎn)，可以再嘗試普及單元測試。這樣，當(dāng)他離開的時(shí)候，即使沒有文檔，這些知識也仍然能留存下來。從效果上說，代碼往往比文檔和注釋更好。
而文化的留存則更加困難，事實(shí)上，代碼中的奇葩注釋往往留存的是負(fù)面文化。應(yīng)該在代碼中留存的文化，是嚴(yán)謹(jǐn)、專業(yè)的工作態(tài)度。雖然自由也是文化的一部分，甚至在管理領(lǐng)域是非常值得向往的文化，但在工程領(lǐng)域，它往往是一種負(fù)面文化，因?yàn)檐浖_發(fā)領(lǐng)域并沒有公認(rèn)的法律甚至道德。你可以想象一下管理領(lǐng)域中沒有約束的自由會導(dǎo)致怎樣的后果。
所以，要想應(yīng)對人員流動(dòng)的風(fēng)險(xiǎn)，除非你有信心留存知識與文化，否則就應(yīng)該在技術(shù)選型時(shí)，傾向于選擇更加嚴(yán)謹(jǐn)?shù)?、隱式信息更少的技術(shù)。
團(tuán)隊(duì)維度總結(jié)
鞋子好不好，只有腳知道。錯(cuò)誤的選型，也只能由團(tuán)隊(duì)自身來承受。阿波羅神廟上鐫刻著一句警世名言——了解你自己。所以，請先客觀認(rèn)識自己的團(tuán)隊(duì)，然后再據(jù)此進(jìn)行選型，千萬不要懶于思考，盲從潮流。
技術(shù)本身
對技術(shù)本身的考量，主要是代入其它維度之后，看其匹配程度。
技術(shù)本身在選型中可能反而是最不重要的一個(gè)維度。這些年的歷史早已證明：優(yōu)秀的技術(shù)未必能流行起來；很多技術(shù)的流行，也并非是由于其優(yōu)秀。
明確的定位
一項(xiàng)優(yōu)秀的技術(shù)，應(yīng)該有其明確的定位和發(fā)展路線。這些定位能清楚地表明自己要做什么、不做什么。而其發(fā)展路線應(yīng)該至少有一年以上的提前規(guī)劃，而且在定位上要能與其前輩做出有效區(qū)隔，而不是亦步亦趨，沒有自己的特長。
代碼質(zhì)量
雖然流行的未必優(yōu)秀，優(yōu)秀的也未必流行，但技術(shù)選型不是趕時(shí)髦。所以，在條件允許的情況下，還是應(yīng)該盡可能選擇優(yōu)秀的技術(shù)。代碼質(zhì)量高的技術(shù)，將來技術(shù)本身由于維護(hù)成本飆升而被放棄的可能性也較小。
衡量代碼質(zhì)量的標(biāo)準(zhǔn)有很多，其中最常用、也比較有效的是單元測試的覆蓋率。而那些從一開始就具有比較完備的單元測試的代碼庫，往往優(yōu)于后補(bǔ)測試的代碼庫。因?yàn)檫@證明的是開發(fā)組的工程化能力和意識，而這些是該技術(shù)長期可維護(hù)性的根本保障。當(dāng)然，除非該技術(shù)特別復(fù)雜或應(yīng)用場景的容錯(cuò)性特別小，否則也不必苛求超過 90% 的覆蓋率。
維護(hù)團(tuán)隊(duì)
維護(hù)團(tuán)隊(duì)的規(guī)模和能力，對于一項(xiàng)技術(shù)在長跑中的表現(xiàn)非常重要。在歷史上如流星般劃過的技術(shù)數(shù)不勝數(shù)，但最終能長期留下來的卻不多。維護(hù)一項(xiàng)技術(shù)的成本遠(yuǎn)高于創(chuàng)建它，所以如果沒有一個(gè)健康、可持續(xù)的商業(yè)模式，一個(gè)像 Linus 那樣的志愿者，以及一個(gè)愿意出錢的超級大金主，那么它在未來的競爭中落敗只是遲早的事。除非這項(xiàng)技術(shù)的需求集足夠小而穩(wěn)定，否則這些因素缺一不可。
社區(qū)
社區(qū)的質(zhì)量，決定著這項(xiàng)技術(shù)長遠(yuǎn)的未來，一些草根型技術(shù)的隱患就在于此。如果社區(qū)人員的素質(zhì)過低，喜歡無原則的站隊(duì)，而不能理性的對該技術(shù)提出尖銳的意見甚至批評，那么這個(gè)社區(qū)遲早會衰落。這類社區(qū)有一個(gè)顯著地特征就是喜歡宣揚(yáng)它“包治百病”，也就是說它適合一切場景，而不會先問你一些問題再?zèng)Q定是否要推薦給你。另一個(gè)特征就是喜歡通過刻意選取某些標(biāo)準(zhǔn)來做出片面的對比，這種行為在學(xué)術(shù)界屬于學(xué)術(shù)造假行為，但在我們工業(yè)界卻被習(xí)以為常，這不能不說是我們的悲哀。
好的社區(qū)應(yīng)該是一個(gè)君子社區(qū)。他們會自覺遵守共同的、理性的行為規(guī)范。會把精力放在對技術(shù)本身做貢獻(xiàn)，而不是通過詭辯、群毆等手段來攻擊競爭技術(shù)。社區(qū)的主要領(lǐng)導(dǎo)者會對社區(qū)的不良行為提出批評、做出約束，甚至為社區(qū)成員的不良行為道歉，而不是放任不管。
技術(shù)維度總結(jié)
不要把技術(shù)看得太重。對所有的主觀性宣傳文章，留一些心眼，多問一句——那缺點(diǎn)呢？將來決定你們是否會掉在坑里的，就是它的缺點(diǎn)。
對于那些會如實(shí)告訴你缺點(diǎn)的宣傳文章，請高看一眼，因?yàn)樽髡呤钦娴南Ｍ麑δ銈儓F(tuán)隊(duì)的未來負(fù)責(zé)。
對于功利社區(qū)，請務(wù)必小心；對于君子社區(qū)，請自覺維護(hù)。
反模式
有一些技術(shù)選型策略可能會導(dǎo)致災(zāi)難性的失敗，這些選型中存在一些共同的反模式，比如：
輿論驅(qū)動(dòng)選型
人云亦云，盲目聽信外人或者某些布道師的主觀性言論，這就是輿論驅(qū)動(dòng)選型。它往往會帶來災(zāi)難。
做任何決策時(shí)，如果要借助參考資料，請記住：最重要的不是它告訴了你什么，而是它對你隱瞞了什么，這些隱瞞的信息最終會置你于險(xiǎn)境。
特別是當(dāng)該資料的作者對某項(xiàng)技術(shù)具有顯著的傾向性時(shí)，請深入想想，他向你推薦的每一項(xiàng)優(yōu)點(diǎn)是否真的“對你”有價(jià)值，以及它背后的代價(jià)是什么。比如，推崇“自由”的技術(shù)往往不夠“嚴(yán)謹(jǐn)”，如果你的產(chǎn)品需要嚴(yán)謹(jǐn)，那么請把“自由”看做減分項(xiàng)而不是加分項(xiàng)。比如，推崇“體積小”的技術(shù)在現(xiàn)在動(dòng)輒幾T硬盤、幾M帶寬的環(huán)境下，到底對你來說有多大價(jià)值？它是不是因?yàn)闆]有其它的優(yōu)點(diǎn)了才把這種細(xì)枝末節(jié)亮出來吸引你？
即使是調(diào)查報(bào)告之類的客觀參考資料，也需要了解其背景。比如一份只發(fā)給程序員的調(diào)查報(bào)告，可能會發(fā)現(xiàn) Chrome 的使用率超過了 99%，但顯然它對你的面向普通用戶的產(chǎn)品毫無價(jià)值，只會給你帶來風(fēng)險(xiǎn)。同時(shí)，要注意很多調(diào)查報(bào)告的設(shè)計(jì)是有主觀傾向性的，甚至題目的排列順序都會給最終結(jié)果帶來 10% 以上的偏差。所以，一定要仔細(xì)分析其中立性、客觀性以及調(diào)查對象在你的目標(biāo)場景下的代表性。
單一指標(biāo)驅(qū)動(dòng)選型
根據(jù)任何一個(gè)單一指標(biāo)進(jìn)行選型都會給你帶來災(zāi)難，更何況很多指標(biāo)并不適合作為選型的依據(jù)。
有些指標(biāo)很容易操縱，比如 GitHub 倉庫上的 Star 就是很容易操縱的，在淘寶網(wǎng)上還有專門購買 GitHub Star 的服務(wù)，而 GitHub 的年度報(bào)告中也已經(jīng)不再把 Star 作為主要指標(biāo)使用。即使是那些不容易造假的指標(biāo)，比如 commit 數(shù)量，其實(shí)也不適合作為主要指標(biāo)使用，它可能意味著作者具有良好的工程習(xí)慣和足夠勤奮，但也可能意味著代碼庫質(zhì)量堪憂，因此不斷推出補(bǔ)丁。
當(dāng)然，有一些客觀指標(biāo)還是比較適合作為主要指標(biāo)來使用的，但也不要盲目相信數(shù)字。比如單元測試中覆蓋率較高的項(xiàng)目，確實(shí)通常質(zhì)量比較好，但是我也見過一些只有調(diào)用卻沒有斷言的測試，那些測試的覆蓋率也會很高，但卻是假的。所以，如果要評估其質(zhì)量，最好還是親自打開看一看。
即使你選出了一些主要指標(biāo)，并且確信它們沒有造假，也仍然不能簡單地把它們加起來或加權(quán)平均來得出一個(gè)數(shù)字進(jìn)行比較。你要綜合評估這些指標(biāo)對你的目標(biāo)產(chǎn)品、目標(biāo)用戶、目標(biāo)團(tuán)隊(duì)的價(jià)值。如果技術(shù)選型只是個(gè)數(shù)字游戲，那還要你干嘛？
話語權(quán)驅(qū)動(dòng)選型
這幾乎是最糟的選型，但卻屢見不鮮。技術(shù)棧的更迭往往會帶來話語權(quán)的變化，而這將給公司帶來災(zāi)難。
對于高級技術(shù)決策者，需要有戰(zhàn)略定力，應(yīng)該以一種規(guī)范的、用事實(shí)說話的方式來控制技術(shù)選型的副作用。我曾見過一幫程序員“偷襲珍珠港”導(dǎo)致架構(gòu)師被迫辭職的慘劇，我當(dāng)時(shí)的意見是：這是 CTO 的鍋。團(tuán)隊(duì)由于選擇技術(shù)棧而產(chǎn)生了話語權(quán)之爭，說明制度設(shè)計(jì)和文化建設(shè)出了大問題，這只能由 CTO 背鍋。
所以，如果你是個(gè)技術(shù)決策者，那么應(yīng)該盡早站出來，發(fā)揮你的職權(quán)和非職權(quán)影響力，抑制這些負(fù)面文化，而不是任由其發(fā)展，最終破壞公司的總體技術(shù)路線，甚至技術(shù)氛圍。
粉絲驅(qū)動(dòng)選型
對于生命線產(chǎn)品，最糟糕的選型莫過于粉絲驅(qū)動(dòng)選型了，這次可沒有“幾乎”。對于技術(shù)人員來講，最重要的特質(zhì)是客觀冷靜，這樣才能配得上“專業(yè)”二字。而拜大神，當(dāng)作玩笑尚可，如果讓它影響到你的決策，那么你就應(yīng)該趁早隱退了，免得將來被迫引咎辭職。
雖然也曾被人稱作“大神”，但我一般會提出反對，至少不作正面回應(yīng)。我已工作二十多年，太清楚業(yè)界百態(tài)了。實(shí)際上，很少有人真的配得上大神的稱號，舉世可能只有 Anders Hejlsberg、Bob 大叔、Martin Fowler、Jeff Dean 等少數(shù)幾位。不過我相信如果你當(dāng)面叫他們大神，他們也會反感的。
就算是對于這些舉世公認(rèn)的大神，也不應(yīng)該成為你技術(shù)選型的依據(jù)，頂多是相信他們會珍惜名譽(yù)、不會粗制濫造而已，因?yàn)榧词故蔷芬踩匀挥兄鞔_的適用范圍，超出這個(gè)范圍它也可能會成為毒藥。
當(dāng)然，對于邊緣產(chǎn)品，進(jìn)行粉絲驅(qū)動(dòng)選型也未嘗不可，甚至可能更好。只是得記住，要做就請做好，別給你的偶像丟臉，更不要做好之后就覺得公司一定要把它應(yīng)用于生命線產(chǎn)品中。
決策樹
如果我在這篇文章的最后部分給你一棵決策樹，你會不會很高興？
很抱歉，寫這一章的目的，就是為了告訴你：我不會給你任何決策樹。請根據(jù)我提供的思維框架，自行設(shè)計(jì)適合你們自己的決策樹，及時(shí)更新它，并且不要盲目相信量化的評估結(jié)果。
文/ThoughtWorks汪志成
更多精彩洞見，請關(guān)注微信公眾號：ThoughtWorks洞見
轉(zhuǎn)載于:https://juejin.im/post/5cad5c01f265da03b85833e8
總結(jié)
- 上一篇： SSH工具Secure Shell Cl
- 下一篇： 邀您共赴数据库学术顶会ICDE 2019