當我們說起開源軟體的時候，想必大家都有豐富的使用經歷，小到Node.js的一個元件庫，大到一套辦公軟體如LibreOffice，再如Linux作業系統，可以說無奇不有，浩如煙海。就拿我們常用的Github來說，官方的資料顯示已經有超過三千八百萬個專案託管在上面。
在我們日常的專案中，開源軟體或者框架也被廣泛的應用，從前端到後臺，從WEB伺服器到資料庫，每一種型別都有很多可以使用的開源軟體。
假設現在需要開始一個專案或者準備引入一樣新的技術，面臨這麼多的選擇，就算是老司機，可能會覺得難以取捨。
流行的就是最好的嗎？
還是該嘗試一下最新的技術？技術的最新趨勢是什麼？
舉一個實際的列子，有一個遺留的線上電商系統，前端使用了jQuery和JSP以及一些老舊的模板技術，每當改動一個小的功能，往往需要非常的小心和充分的測試。前端程式碼已經非常難以維護和擴充套件，沒有模組化管理，沒有層次結構。同時，伴隨著業務的快速發展，業務方也希望對頁面進行不定期改版和試點，使之能夠適應快速的市場變化，要求統一介面風格，開發成本低。
IT團隊領導考慮引入一項新的技術，希望實現模組化程式碼管理，前後端分離，提升開發效率，未來更好的向微服務轉換。你作為團隊TechLeader，來負責實施，該如何評估和選擇呢？
首先要考慮的是實際需求和應用場景，弄清楚要解決的問題是什麼，再來看每種軟體的優缺點是什麼，是否能夠幫助解決實際的問題。我的一個原則就是KISS（保持簡單），能夠用一個包庫解決的不要用一個框架，能夠用一個框架解決的不要用一個應用，誰能滿足需求而且更加簡單，就用誰。
業務的快速變化，轉化成技術的語言可能就是快速迭代，如果有模組化管理，實現業務的耦合，顯然有助於提升交付速度；試點和改版可能就是更多的偏向前端，顯然實現前後端分離，可以更好的滿足這一點。再來看看現在比較流行的技術，現代的前端框架幾乎都能夠滿足這兩點需求，比如AngularJs、ReactJs、VueJs等。
究竟該如何選擇？
沒有比較就沒有差異。你最先想到的可能是軟體的特性。這個文件中一般會有描述，也會找到文章的總結，比如VueJs的《對比其他框架》。結合實際的情況，我認為可以從以下幾個方面來入手。這時我們不妨做一個表格，從多個維度來進行考察，並給每一項進行評分。
首先是看軟體特性是否滿足需求，下面這些維度都是可以參考的。
- 版權協議：這個主要是看能否修改原始碼，能否閉源使用，請看文章底部的參考資料。
- 相容性：和現有技術棧的相容性，比如JDK的版本要求，Node的版本，以及是否可以重用已有的程式碼和功能。
- 擴充套件性：是否有設計擴充套件點，容易進行二次開發；隨著規模的增加，是否會提高複雜度，導致程式碼難以駕馭。
- 替代性：是否有同型別其他功能相似的軟體，可能會同時進行試點進行比較。
這個時候，我們的評估表看起來可能是這樣的。
對於統一介面風格，提升開發效率，我們則可以選擇定製化一套StyleGuide，來進行重複利用。可以參考一位同事的這篇文章“《風格指南驅動開發》”。
其次，我們要看目前團隊的技術能力，例如：
- 學習成本：學習曲線是否陡峭，能否在短時間內掌握並運用，影響的是專案的進度。
- 現有資源：開發團隊是否願意學習新技術，或者有團隊成員已經掌握了該項技術；公司範圍內能否協調到專家資源支援。
- 網路資源：部落格、專業網站、公眾號等上的分享和總結也比較具有參考價值。
舉個例子，假設現在有5個開發，如果大家對三個框架都不熟悉，可以選擇VueJs。如果有兩個人對AngularJs有一些使用經驗，可以優先考慮AngularJs。按照上面的維度記錄之後，可能的結果是這樣的：
第三，從社群支援來看。例如：
- 活躍度：是否有豐富的相關技術問題的討論和分享，碰到坑時可以尋求幫助，比如郵件列表、論壇、stackoverflow。
- 更新：版本更新是否頻繁，是否有嚴重的安全問題或缺陷。
- 應用廣泛性：有哪些公司在使用該技術，是否有案例分享。
- 生態圈：選擇一個軟體或者技術的時候，往往有它自己的生態圈，相關的工具也是需要考慮的。比如Hadoop，相關的軟體或工具就非常多。
第四，文件和培訓
- 官方文件：除了使用文件，原始碼也是比較重要的，原始碼是否組織的比較好，易於理解，在後續解決技術問題的時候會有比較明顯的作用。
- 商業支援：如培訓、付費支援，如果開發團隊技術能力還不錯，則顯得不是那麼重要。
- 成熟的案例：別的公司或者團隊是怎麼應用的，有哪些坑。> Talk is cheap, show me the code.
結合應用再寫個小Demo，功能不用那麼完善，給團隊秀一秀程式碼，讓大家有個客觀的認識，對工作量的估算也會比較有幫助。
對於上面的案例，如果現在來選擇，Vue會是首選，相對簡單。
React makes it painless to create interactive UIs.
如果碰到評估完之後，兩種可選方案區別不太明顯，不相上下，那就丟硬幣了（不如讓團隊投票吧）。最後就是進行技術評審了，給專家團隊或者領導演示你的方案，展示Demo，讓他們更加有信心，並獲得支援。