當(dāng)我們說起開源軟件的時候，想必大家都有豐富的使用經(jīng)歷，小到Node.js的一個組件庫，大到一套辦公軟件如LibreOffice，再如Linux操作系統(tǒng)，可以說無奇不有，浩如煙海。就拿我們常用的Github來說，官方的數(shù)據(jù)顯示已經(jīng)有超過三千八百萬個項目托管在上面。

在我們?nèi)粘５捻椖恐校_源軟件或者框架也被廣泛的應(yīng)用，從前端到后臺，從WEB服務(wù)器到數(shù)據(jù)庫，每一種類型都有很多可以使用的開源軟件。

假設(shè)現(xiàn)在需要開始一個項目或者準(zhǔn)備引入一樣新的技術(shù)，面臨這么多的選擇，就算是老司機，可能會覺得難以取舍。

流行的就是最好的嗎？

還是該嘗試一下最新的技術(shù)？技術(shù)的最新趨勢是什么？

舉一個實際的列子，有一個遺留的在線電商系統(tǒng)，前端使用了jQuery和JSP以及一些老舊的模板技術(shù)，每當(dāng)改動一個小的功能，往往需要非常的小心和充分的測試。前端代碼已經(jīng)非常難以維護和擴展，沒有模塊化管理，沒有層次結(jié)構(gòu)。同時，伴隨著業(yè)務(wù)的快速發(fā)展，業(yè)務(wù)方也希望對頁面進行不定期改版和試點，使之能夠適應(yīng)快速的市場變化，要求統(tǒng)一界面風(fēng)格，開發(fā)成本低。

IT團隊領(lǐng)導(dǎo)考慮引入一項新的技術(shù)，希望實現(xiàn)模塊化代碼管理，前后端分離，提升開發(fā)效率，未來更好的向微服務(wù)轉(zhuǎn)換。你作為團隊TechLeader，來負(fù)責(zé)實施，該如何評估和選擇呢？

首先要考慮的是實際需求和應(yīng)用場景，弄清楚要解決的問題是什么，再來看每種軟件的優(yōu)缺點是什么，是否能夠幫助解決實際的問題。一個原則就是KISS（保持簡單），能夠用一個包庫解決的不要用一個框架，能夠用一個框架解決的不要用一個應(yīng)用，誰能滿足需求而且更加簡單，就用誰。

業(yè)務(wù)的快速變化，轉(zhuǎn)化成技術(shù)的語言可能就是快速迭代，如果有模塊化管理，實現(xiàn)業(yè)務(wù)的耦合，顯然有助于提升交付速度；試點和改版可能就是更多的偏向前端，顯然實現(xiàn)前后端分離，可以更好的滿足這一點。再來看看現(xiàn)在比較流行的技術(shù)，現(xiàn)代的前端框架幾乎都能夠滿足這兩點需求，比如AngularJs、ReactJs、VueJs等。

究竟該如何選擇？

沒有比較就沒有差異。你最先想到的可能是軟件的特性。這個文檔中一般會有描述，也會找到文章的總結(jié)，比如VueJs的。結(jié)合實際的情況，我認(rèn)為可以從以下幾個方面來入手。這時我們不妨做一個表格，從多個維度來進行考察，并給每一項進行評分。

首先是看軟件特性是否滿足需求，下面這些維度都是可以參考的。

• 版權(quán)協(xié)議：這個主要是看能否修改源代碼，能否閉源使用，請看文章底部的參考資料。
• 兼容性：和現(xiàn)有技術(shù)棧的兼容性，比如JDK的版本要求，Node的版本，以及是否可以重用已有的代碼和功能。
• 擴展性：是否有設(shè)計擴展點，容易進行二次開發(fā)；隨著規(guī)模的增加，是否會提高復(fù)雜度，導(dǎo)致代碼難以駕馭。
• 替代性：是否有同類型其他功能相似的軟件，可能會同時進行試點進行比較。

這個時候，我們的評估表看起來可能是這樣的。

對于統(tǒng)一界面風(fēng)格，提升開發(fā)效率，我們則可以選擇定制化一套StyleGuide，來進行重復(fù)利用。可以參考一位同事的這篇文章“”。

其次，我們要看目前團隊的技術(shù)能力，例如：

• 學(xué)習(xí)成本：學(xué)習(xí)曲線是否陡峭，能否在短時間內(nèi)掌握并運用，影響的是項目的進度。
• 現(xiàn)有資源：開發(fā)團隊是否愿意學(xué)習(xí)新技術(shù)，或者有團隊成員已經(jīng)掌握了該項技術(shù)；公司范圍內(nèi)能否協(xié)調(diào)到專家資源支持。
• 網(wǎng)絡(luò)資源：博客、專業(yè)網(wǎng)站、公眾號等上的分享和總結(jié)也比較具有參考價值。

舉個例子，假設(shè)現(xiàn)在有5個開發(fā)，如果大家對三個框架都不熟悉，可以選擇VueJs。如果有兩個人對AngularJs有一些使用經(jīng)驗，可以優(yōu)先考慮AngularJs。按照上面的維度記錄之后，可能的結(jié)果是這樣的：

第三，從社區(qū)支持來看。例如：

• 活躍度：是否有豐富的相關(guān)技術(shù)問題的討論和分享，碰到坑時可以尋求幫助，比如郵件列表、論壇、stackoverflow。
• 更新：版本更新是否頻繁，是否有嚴(yán)重的安全問題或缺陷。
• 應(yīng)用廣泛性：有哪些公司在使用該技術(shù)，是否有案例分享。
• 生態(tài)圈：選擇一個軟件或者技術(shù)的時候，往往有它自己的生態(tài)圈，相關(guān)的工具也是需要考慮的。比如Hadoop，相關(guān)的軟件或工具就非常多。

第四，文檔和培訓(xùn)

• 官方文檔：除了使用文檔，源代碼也是比較重要的，源代碼是否組織的比較好，易于理解，在后續(xù)解決技術(shù)問題的時候會有比較明顯的作用。
• 商業(yè)支持：如培訓(xùn)、付費支持，如果開發(fā)團隊技術(shù)能力還不錯，則顯得不是那么重要。
• 成熟的案例：別的公司或者團隊是怎么應(yīng)用的，有哪些坑。> Talk is cheap, show me the code.

結(jié)合應(yīng)用再寫個小Demo，功能不用那么完善，給團隊秀一秀代碼，讓大家有個客觀的認(rèn)識，對工作量的估算也會比較有幫助。

對于上面的案例，如果現(xiàn)在來選擇，Vue會是首選，相對簡單。

React makes it painless to create interactive UIs.

如果碰到評估完之后，兩種可選方案區(qū)別不太明顯，不相上下，那就丟硬幣了（不如讓團隊投票吧）。最后就是進行技術(shù)評審了，給專家團隊或者領(lǐng)導(dǎo)演示你的方案，展示Demo，讓他們更加有信心，并獲得支持。

本文轉(zhuǎn)自（）

【歲末特惠活動火熱進行中，最后的瘋狂，趕緊搶！】

活動時間：12月1日-12月31日