網際網路公司和團隊的技術選型

　　網際網路技術爆炸的時代

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

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

　　選擇開發效率還是執行效率是個老生常談的問題。對於不同階段的公司和專案會有不同的選擇。新的商業專案更趨向於選擇開發效率優先。因為商業模式的儘早驗證比其他因素更重要。

　　但是假如是成熟的商業模式，預見規模會很快擴大到很大，則可以選擇執行效率優先。另規模化專案比如雲服務平臺、大公司的基礎元件更趨向於選擇執行效率優先。

　　成熟和常見技術優先

　　成熟和常見技術指那些被大部分人知道並學習很多年的技術，比如網頁程式語言 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 位高階工程師解答遇到的所有相關問題，這位工程師需要從原始碼級別理解這項技術。優先選擇成熟技術。

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

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

　　沒有銀彈

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