技術選型--因地制宜、量體裁衣

標籤：

——摘自《HTML5移動Web開發實戰》 c12  12.2

1、技術成熟度等級

一項技術是否成熟，決定了你的應用是否穩定。特別是新的技術通常意味著缺乏穩定性，在需要保證正確性和穩定性的情境（比如面向金融或者面向數量巨大的終端使用者的應用），選擇新技術時一定要謹慎再謹慎，對於一些不關鍵的容錯性高的情境（比如內部系統），選擇新技術的風險就會小很多。

2、文檔

由於程式員基本都是由人類構成，因此文檔好壞基本上制約著程式員的工作效率。無論你看到某項技術吹的再天花亂墜，請一定記得看看它的文檔是否健全優雅，樣本是否清晰易懂，否則你發現有坑時，說不定你已經踩進去了。

3、適用情境

不同種類的技術工具一定有它適用的針對性情境，即便是號稱“大一統”和“全能”的架構技術，也有它所不適用的地方，比如YUI功能齊全，但在短平快的廣告宣傳頁使用它就顯得殺雞用牛刀了，同理，目標相似的技術也會有不同的地方，在這方面必須要結合你自己的應用具體情況來分析，比如sugar.js和underscore.js都是用於對原生JavaScript對象提供實用函數，sugar就能提供更加“直覺式”的編程體驗，而underscore則對於混合編程環境提供了sugar無法提供的衝突處理。

4、應用規模

如果你的應用代碼規模很大，你不得不考慮組織代碼的方式，是選擇模組化（CMD/AMD）還是用繼承樹（closure library）？打包工具、壓縮公用程式和校正工具這些東西隨著應用規模的上升都不得不逐漸提上你的議程，一項技術是否滿足打包壓縮模組化等需求，也是你需要考慮的地方。

5、學習曲線

學習曲線通常是工程師或者工程師頭兒在技術選型時經常忽略的地方。比如在你自己非常瞭解一項技術A時，經常會選擇它或者與它相關的技術，而忽略和你合作的人對A的認知情況。由於學習一項技術總是需要時間，因此對於整個團隊而言，學習曲線陡峭的技術很可能成為開發效率的殺手，而作為技術選型者自己卻很難意識到。但另一方面，學習曲線陡峭的技術通常來是較革新的，並且長期來看是高效率的，因此如果你的應用是一個長期不斷維護的項目，嘗試較革新的能反映技術趨勢的工具也未嘗不可。

6、社區力量

如果你是開源運動的忠實擁護者（或者說你是沒有那麼多錢尋求支援人員的窮人），那麼一項技術的社區力量是否強大很大程度上影響了你踩了坑是否有人幫你。jQuery之所以如此流行，也離不開社區的力量，無數人在為jQuery貢獻教程、跑測試和報bug，在論壇裡或問答網站裡解答具體的問題……如果你不幸選擇了一項沒有社區支援甚至作者本人都不響應的開源技術，那麼遇到問題的時候你就可以去買點手帕抹淚吧。

同樣的，如果你自己在開發或維護某個開源項目，那麼除了寫代碼，培育其社區也是極其重要的工作。

7、技術缺點

所有的技術都有缺點，做決定前，一是要認清這項技術的缺點，二是要考慮你是否能接受它的缺點。

8、團隊水平

這個說起來讓人難堪，但你不得不承認任何團隊中的人員水平都是有高有低的，一個團隊的平均水平也是有高有低的。如果一項技術過於簡單，二團隊水平又非常高，很可能出現重造輪子甚至辱罵原作者這樣的事兒，而相反在選用技術過於複雜，團隊水平不高的情況，則非常容易出現誤用亂用最後甚至導致代碼不可維護的情況出現。

9、相容性

對於前端開發人員來講，相容性尤為重要。幾乎所有前端技術都會提供一個相容性列表，認真研讀它，並和你自己應用需要相容的瀏覽器和裝置做好仔細調研對比，這是一個門當戶對的問題，光有愛情是不夠的。

10、迭代周期

通常來講，不同公司的產品迭代速度是有很大差別的，這種節奏對技術選型也有很大影響。比如在迭代周期慢的傳統軟體公司，如果選用更新頻繁的技術，那麼很可能上一個版本的應用中出現的bug在下一次更新前都無法解決，而對於迭代周期比較快的互連網公司影響則沒那麼大。迭代周期快的產品對較新的更新頻繁的技術容忍度會高很多。

技術選型--因地制宜、量體裁衣