互聯網公司和團隊的技術選型

互聯網技術爆炸的時代

現在同一個問題，解決的方式有很多種。同樣是應用層開發，有數不盡的語言和框架可以選擇。這雖然有好處，但也帶來了諸多麻煩。比如，團隊成員對技術 選型意見的不一致；解決同一問題工具選擇周期的增長；很難客觀完整的對比可選方案；社區對哪個語言、哪個框架更好爭論的永不休止。究竟如何做技術選型是困 擾很多人的問題。之前我也有很多疑惑和思考，最近整理如下。

效率：開發效率優先還是運行效率優先

選擇開發效率還是執行效率是個老生常談的問題。對于不同階段的公司和項目會有不同的選擇。新的商業項目更趨向于選擇開發效率優先。因為商業模式的盡早驗證比其他因素更重要。
但是假如是成熟的商業模式，預見規模會很快擴大到很大，則可以選擇運行效率優先。另規模化項目比如云服務平臺、大公司的基礎組件更趨向于選擇運行效率優先。

成熟和常見技術優先

成熟和常見技術指那些被大部分人知道并學習很多年的技術，比如網頁編程語言 PHP 、關系型數據庫 MySQL 、Web 服務語言 Java 。好處在于招聘成本、溝通學習成本會很低。大部分問題已經被很多人解決過很多次。很容易找到相關的技術文檔。這樣帶來的是開發效率的提升。

小眾技術不等于新技術

很多人會混淆小眾技術和新技術。雖然有時候他們之間交叉很多。

小眾技術指那些? 小眾技術一般針對特定領域問題設計。比如 Erlang 針對軟實時控制系統設計；Rails 針對快速 MVC Restful 互聯網應用開發而設計；Grunt、Gulp 針對前端自動化設計。

成熟的小眾技術

有一些小眾技術及時誕生了很多年，由于適用性比較窄，也不廣為人知。但是這不意味著這種技術不成熟。Erlang、Lisp、Lua、Node.js 都是成熟的小眾技術。成熟的小眾技術解決特定領域問題非常高效。

適度嘗試新技術

一般情況，新技術都是在借鑒了所有已有技術基礎上的重新設計和創新。一部分新技術會成為未來的主流技術，雖然這個過程比較緩慢，需要很多推廣才能吸 引很多開發者使用。并且技術本身由于越來越多的人使用，不斷自我迭代，修正優化。所以，需要根據自我情況思考是不是有更好的新技術解決現有問題，提升開發 和運行效率。

避免重造輪子

對于工程師或者手工藝人，創造東西給他們帶來成就感、或者會對自己的業績、績效有影響。所以，很多新出技術并沒有明顯的創新和優勢。只是把輪子重新制造一遍。這常發生在資源充足、人員冗余的大公司。試問哪個大互聯網公司沒有幾套 RPC 框架？

團隊大小對技術選型的影響

1 人團隊、10 人以下團隊、10 人以上團隊對于技術選型有 很大區別。1 人團隊幾乎不需要考慮技術選型的問題，選擇喜歡的即可。10 人以下團隊則可以更多嘗試新技術和小眾技術，因為招聘培訓成本還不會很高。10 人以上團隊則需要更多考慮團隊擴展成本，而不單單是開發效率和執行效率問題、盡量少引入不成熟的新技術。在大公司的技術選型和創新過程類似，可以是自上而 下，也可以是自下而上。

團隊成員經驗對技術選型的影響

團隊技術選型自然會選擇團隊所有成員熟悉的技術，否則會出現開發節奏問題。比如所有人熟悉 Java，小部分人熟悉 Scala 的情況下，需要忍痛割愛選擇即使從其他層面考慮更適合的 Scala 語言。一般情況下，某項技術至少需要 1 – 2 位高級工程師解答遇到的所有相關問題，這位工程師需要從源碼級別理解這項技術。優先選擇成熟技術。

技術幫派之正視技術的優點和缺點

技術爆炸和開發者社區的增長必然會導致一個問題，技術幫派。需要注意的是需要正視某項技術的優缺點和使用場景。盡量避免“技術幫派”對正確優化技術選型的影響。

沒有銀彈

沒有任何一項技術可以適用在所有場景，所以不同場景下的技術沒有可比性。沒有銀彈和最好的語言和框架。