對近期前端圈口水之爭的一些思考

寫在前面

1.大漠窮秋同窗以略顯偏激的ng對比vue一文引發網絡上的口誅筆伐，最終以致歉信和辭職信了結
2.知乎上未知姓名同窗回答爲何使用React的問題，其中夾雜着一些對vue的我的觀點，引來了vue做者的討伐

以上兩點剛好同時出如今了個人視線中，由此我想站在一個作業務開發的前端視角來思考，當咱們在分析一個框架適不適合一個項目時，我須要以怎樣的維度來分析？

首先講點題外給各位，做爲吃瓜羣衆，我是很開心的，由於我所處的前端圈子比較狂躁，起碼比沒新聞強，說明咱們前端正在蓬勃發展，處在其中會讓我有一種興奮感。其實關於網絡上的爭吵你們不用太較真，某些人的觀點和見解僅僅是商業行爲，前端圈也不能說混亂，由於咱們處的大環境就是商業社會，你們都是趨利而已，任何環境都同樣，前端也不例外。

很少說了，進入主題。

進行前端技術選型我所思考的幾個維度

• 法律風險

• 穩定性

• 上手難度及社區生態

• 開發工具及流程閉環

• 可維護性及可擴展性

• 團隊合做並行提效

• 與新標準的融合度

• 方便調優及監控

法律風險

這一個因素可能小公司會忽略，但請千萬不要，由於法律上出了問題，每每對你的團隊帶來的經濟損失是超大的，尤爲是作企業級的產品，法律風險永遠是要考慮的第一要素。前段時間Apache 軟件基金會(ASF, Apache Software Foundation)將『BSD+專利許可證』列爲 Category-X License，這個意思是說，全部 License 爲 『BSD+專利許可證』的軟件都會受到影響，大概的意思就是『BSD+專利許可證』不被ASF官方承認，可能會有潛在的法律風險，這一舉措對 Facebook 旗下的軟件影響巨大，特別是對於前端領域的 React 框架，所以，這個措施引起了一些用 React 的大廠的關注，我廠的法務部也在第一時間介入研究這個舉措的影響度，最終的解決方案目前還不清晰，不過React官方仍是表態不會修改 License，ASF 仍舊把 Facebook 這個 License 列爲非官方推薦的 License。若是對法律層面不清晰，引起了著做權官司，對於阿里這個航空母艦會面臨多少錢的訴訟，即便不會馬上引起訴訟，但確定要作技術替換，這須要投入多少成本都是不可估量的。在前公司，設計海報時使用了方正字體也接到過訴訟，這些其實都屬於法律層面須要注意的。總而言之，在作技術選型時，我首先考慮的就是所用的框架的 License 是否是存在法律風險。

穩定性

當一個框架已經超過了1.0版，或者說已經fix掉不少bug（從github的issue記錄能夠查看），這個時候能夠理解爲這個框架的穩定性是相對較好的。穩定，是一個軟件系統的生死線，若是一個系統連基本的穩定都沒有，這個軟件系統能夠說是一擊即潰，對於開源框架的技術選型穩定性也是相當重要的一環。

上手難度及社區生態

其實上手的難度是因人而異的，對於我所負責的採購業務團隊，外包同窗可能比較多並且離職率也高，爲了業務的高效運轉，作技術選型時上手難度不得不作爲一個因素來考量。好比我在採購平臺的前端開發中，引入基本的構建工具和組件庫後一直想要引入數據流框架，可是發現Flux的思想以及跟React之間的關係，確實不便於新人去理解，因此我遲遲沒有引入數據流，大部分場景仍是鼓勵你們手寫 fetch + setState，這樣迭代了將近1年，發現技術上的諮詢確實不多，由於引入的新概念少，新人在理解業務以後可以快速上手。社區生態其實就是看一下 stackoverflow 或者 segmentfalut 上問題的 tag 數，當使用這個技術時可否經過搜索引擎快速查找到解決方案，這個是衡量這個技術是否社區活躍的重要因素，這個也有助於效率。

開發工具及流程閉環

這個因素的意思是，當你選用某一個技術時，是否是配套的工具不少很方便，開發的流程能不可以基於這些工具完成一個健康的閉環，也就是說在使用這個技術以後，它附帶的腳手架、構建、壓縮、單測等工具能不可以覆蓋你一個項目的整個生命週期，從設計、開發、測試、發佈、運維等各方面都能覆蓋到。好比 vue 和 angular 這方面就比 React 要強一些，React 主要 focus 視圖層，而 vue 官方就會直接推薦一整套解決方案，從路由、腳手架等，不過 React 後來也加入了一些官方的東西，好比 create-react-app 這個腳手架的引入。

可維護性及可擴展性

這個概念可能會讓人感受到比較虛。舉個例子，你使用 jQuery 開發了一個 app，過了兩年 React 開始上馬大家的業務了，這個使用 jQuery 所寫的代碼還能不能繼續維護甚至基於 React 技術進行擴展。這個因素其實仍是跟人相關，厲害的人寫得代碼是有設計感在裏面的，是有模式的，不管將來更換什麼樣的框架，但代碼的核心思想在那，代碼結構就在那，API設計的好，即便你過去是用jQuery寫得 dialog，但這個 dialog 必需要支持後續的 React 風格，可能僅僅須要一層簡單的封裝就能夠搞定了，因此技術的維護性和擴展性，在框架那一層是大可能是沒有問題的，關鍵仍是寫代碼的人，因此你團隊代碼的API設計、模式分層要把控好。

團隊合做並行提效

這個點思考的是這樣的場景。好比，某一天你的業務忽然緊急起來，使用這個框架能不可以讓你達到投入越多的人，就能在保證質量的前提下更快的完成任務。在這個點我感受 React 作得足夠優秀，由於 React 的概念不多，API也精簡，你們都是經過組件化的思惟模式來寫代碼，當業務繁忙的時候，原本是兩我的負責20個組件，可能經過簡單溝通以後再投入2我的，就是四我的負責20個組件，這樣就可以經過加人來達到提高速度的目的，相比較之下 vue 和 angularjs 在這個方面就不如 React。

與新標準的融合度

業務是發展的，技術是面向將來的。你所用的技術是否跟業界新規範有必定的融合這一點比較重要，直接關係着將來你的項目是否可以方便升級而且不會帶來不少潛在的bug，好比 React 本來是 createClass，後來就推崇使用 ES6 的繼承機制，這就是一個很好的趨勢，說明這個框架是面向將來的，其實在前端領域不少框架這一點作得都不錯。可是若是作不到這一點，我會以爲這個框架前途未卜。

方便調優及監控

其實這個點是比較細的，落地到技術細節來講就是這個框架在設計的時候有沒有考慮一些 hook 機制或者中間件機制，方不方便你在一些關鍵的節點插入監控腳原本獲知當前的性能數據以及達到性能優化的目的，其實這個屬於優化的範疇，基本上是在軟件工程的中後期纔會涉及，有一句話我認爲很是有道理，『過早的優化是萬惡之源』，其實性能因素並不適合過早的去考慮，它每每是隨着工程以及業務的發展逐步引入的，過早的由於考慮性能而下降了你項目的效率實際上是不明智的，由於你所考慮的性能問題不必定之後就會出現，但也不能說不考慮性能，你應該爲將來優化埋下一些小種子。

以上就是我所考慮的幾個技術選型的維度，也但願對於技術選型有本身獨特看法的同窗跟我交流。