在上一篇文章中已經介紹了大前端關於狀態管理、UI元件、小程式、跨平臺和框架層的內容。在本文中，我會繼續介紹程式語言、工程化、監控、測試和服務端，同時也會對下半年大前端可以關注的部分進行展望。

結合個人和團隊經歷對2019上半年做個技術總結，將各類技術框架/語言/工具分作兩個維度：

• 技術採用生命週期
• 技術方向

 

程式語言 

來自statesofjs的統計，在類JS程式語言上，ES6遙遙領先，TypeScript也獲得接近半數的使用量。其次是Flow、Reason、Elm和ClojureScript。

 

目前主流程式語言已經是ES6/7+Babel的組合，用過ES6/7後基本沒法再回到原始的ES5時代了，出現了類和模組的概念方便JS程式碼模組化載入，再加上各種語法糖用的快樂的飛起。async await的語法也替代promise的寫法，使得程式碼邏輯變得更加簡潔。ES的規範依舊在快速迭代，每年都會出一個更新的版本，引入不少語言特性，同時有Babel加持可以將新的語法都轉譯成ES5版本執行在瀏覽器中。

 

TypeScript是作為2019年的程式語言的大黑馬受到極大關注，現在有大量框架例如Mobx、Vue3.x都是用TypeScript進行編寫，由於TypeScript引入型別能夠做到靜態檢查，因此解決了大量JS執行時型別錯誤，對於大型專案的程式碼安全性有很大的幫助。引入TypeScript需要團隊對於新的特性有充分的瞭解，好好利用其中的精華，否則就會變成僅僅把.js字尾改成.ts而已。

 

在2019 stateofcss也有關於CSS特性使用情況的統計，每個特性的外圈代表聽過過的數量，內圈表示真正使用過的數量。

 

其實CSS特性的使用覆蓋面很大因素取決於瀏覽器的支援程度，瀏覽器支援越好越容易獲得更高的使用率。可以看到幾個高使用率的CSS特性在瀏覽器支援方面都非常好，除去Opera Mini和少量IE11，其他主流瀏覽器都能完美支援。

 

一個有趣的現象是在佈局方面Flexbox使用率要高於Grid，可能的原因在於在低版本瀏覽器的支援方面Flexbox要更好，但其實在當前主流瀏覽器的支援度上已經沒有區別。另一個因素可能是React Native也是推薦使用Flexbox來做佈局，具有較大的群眾基礎吧。

CSS in JS的理念應該來自React Native，最開始接觸的時候相當顛覆，在JS檔案中直接寫相應的CSS定義，使得元件內聚化達到極致，解決了css全域性汙染的問題。在web前端，css in js有很多的實現方式，但目前來看還是比較早期，傳統的Less、Sass的這類css預處理框架已經能夠比較好的解決一些問題，從程式設計習慣上也一脈相承，因此css in js理念不錯，但要得到推廣還需要時間。

CSS Houdini 提出了一個前無古人的的設想：開放 CSS 的 API 給開發者，開發者可以通過這套介面自行擴充套件 CSS，並提供相應的工具允許開發者介入瀏覽器渲染引擎的樣式和佈局流程中。簡單的說houdini可以讓大家去寫css 的polyfill從而極大的改善css新特性引入的速度。不過諷刺的是，它本身也需要瀏覽器支援，w3c標準還處於working draft，大多數瀏覽器都還沒很好支援，大家可以期待一下～

工程化

提到工程化先拿騰訊直播團隊分享過的一張圖來鎮樓，很多小夥伴會狹隘的認為工程化就是webpack或者gulp打包而已，其實這個應該涵蓋從專案建立、開發、編譯、打包、測試、釋出、監控全流程。

 

專案初始化 專案腳手架目前已經非常普遍，例如create-react-app或者vue-cli都是官方標準的腳手架工具。對於一些稍大的公司都建議自己包裝一套自己的腳手架，這樣可以沉澱很多最佳實踐，例如工程目錄結構、lint配置、監控配置、打點配置等等，因此腳手架是落地前端架構標準化不可或缺的一環。

本地開發 lint的規範一定要在專案初期就落地，可以直接拿airbnb的規範或者再定製化一下。lint可以極大的提升程式碼質量，至少從程式碼風格來看可以保證統一。 Sonar的引入可以進一步提升程式碼質量，幫助分析出潛在的問題，同時分析程式碼的重複率，過長的高數等等，這些都是所謂的程式碼bad smell，如果任其發展下去，專案維護成本會直線上升。 Mock工具的必要性在前後端聯調時就能充分提現，很多時候由於前後端介面定義不清晰導致聯調過程就是一個扯皮過程，如果缺乏mock工具，前端也會淪為後端介面除錯的觸發器，前端頁面點一下，後端除錯大半天，前端小夥伴們傷不起啊。Mock工具至少要有介面定義和本地mock的能力，能夠極大提升大家研發體驗。

打包 前端工程打包工具強烈推薦webpack 4，強大的外掛能力能夠讓你做幾乎任何事情。webpack4中引入了更為強大智慧的code split能力，能夠極大縮減包大小，經過實踐通常減小幅度都在30%-50%，而且在打包速度上也有很大改進，通常也有30%的提升。

監控

當老闆給你發一個線上問題的截圖，你本地又無法重現，又沒有足夠的日誌，這時候是不是鬱悶，和老闆信任的小船說翻就翻了。

監控從能力來看分為幾個階段： 第一階段：硬體運維能力，例如伺服器執行情況，CPU、記憶體、磁碟、網路等等，在拓機情況下能夠快速響應。 第二階段：應用服務的監控，例如服務可用性、異常流量監控、頁面介面的響應時間、App crash等等。 第三階段：核心業務指標監控，例如業務核心鏈路資料同比環比的對比等等。 第四階段：全鏈路的資料監控，從客戶端、前端到服務層，到資料層，能夠通過唯一id串聯起來，可以方便回溯使用者操作，重現問題現場。

很顯然要做到監控這四個階段需要做大量的基礎設施，往往大廠都有一套完備的輪子。對於小團隊而言，採用開源方案能夠快速補全能力。

Cat 是美團開源的業界良心監控方案，對於前後端都有不錯的監控能力，資料收集也很完備，能夠提供實時的效能指標、健康狀況、實時告警等資料，在多家網際網路公司也得到實踐，實屬拯救碼農頭髮的必備工具，你值得擁有～

umeng 作為移動端行為分析工具已經有非常廣泛的使用，不過對於大廠而言使用者資料非常關鍵，如果有能力還是建議自研，畢竟使用者的行為資料是核心資產，將來可以基於這些資料做推薦、分析等等有價值的事情。

lighthouse/perf curve/perf budget 這些都是作為效能監控的工具，不僅僅可以得到線上環境真實資料，還能在開發階段提前預警效能問題、落地效能優化的最佳實踐，也是小夥伴們不可或缺的好伴侶～

測試

這裡通常指的是自動化測試而非手工測試，從測試覆蓋範圍可以分為單元測試、UI測試、介面測試和功能自動化測試。我所經歷的公司或團隊，幾乎沒有能把自動化測試能夠做好的，時間和需求頻繁變更往往是最大的藉口，不過程式設計師內心都不願意寫測試用例的吧（手動捂臉）。

從落地難易程度來看，介面測試和單元測試最好落地，介面不說了難度不高收益還不錯，主要需要對資料準備有些要求。單元測試首推Jest，同時還能統計出覆蓋率，但是單元測試要明確好可以測試的範圍，一般業務邏輯和底層通用方法比較適合。所以業務邏輯程式碼從UI層程式碼抽離非常重要，這時候redux這類狀態管理框架就有了天然優勢了，裡面reducer、action部分就可以單測覆蓋。

UI的測試一般對於元件庫有點幫助，簡單的做法就是通過snapshot進行dom對比，簡單粗暴。功能自動化很少能夠落地，appium或者selenium都是其中翹楚，需要看業務情況，如果有頻繁頁面改動，一開始功能自動化寫的爽，後續維護成本大的驚人，而且由於功能覆蓋時間差，還是需要大量手動測試的。

服務端

自從出現Node之後，前端技術正式進入服務端開發，從而讓前端的小夥伴們可以進行全棧的開發，技術棧的範疇變的更大，對於業務的把控能力也變強了。

Node可以帶來幾個明顯的好處 第一，可以作為BFF(Backend for Frontend)層，解決前後端介面頻繁變更的問題，通過BFF層可以實現更加靈活的介面，介面欄位的過濾，介面的聚合等等 第二，可以用做SSR(Server Side Render)，通過Node層同構直出，可以將前端渲染程式碼放在服務端，實現首屏的服務端渲染，提升首屏渲染時間 第三，基於“只要能用JS實現，最終都會用JS實現”定律，Node讓前端同學可以用JS擼後端程式碼，這個掌控一切的感覺太爽了~

Node也存在一些缺點 第一，需要額外的伺服器，很多場景下Node層僅僅做介面透傳的工作，對於伺服器是一種浪費，而且作為一個核心節點如果一旦掛掉整個應用都不可用 第二，需要對Node服務有一整套的打包、部署、監控等能力，這個對於前端同學來說提出了較高的運維能力的要求，這些事情往往讓前端同學苦不堪言

服務端最近可以持續關注GraphQL/Serverless，這兩項技術對於前後端的架構設計都會帶來深遠的影響。

2019年下半年展望

 

中後臺的重塑 針對中後臺業務特點，缺乏詳盡的互動設計，缺乏足夠的前端資源，頁面樣式相對統一，業界提出通過少量程式碼或者無程式碼方式搭建中後臺前端系統。目前有的一些最佳實踐：Fusion Design，飛冰，Ant Design Pro。大家都是從幾個方向去實現中後臺前端系統的無程式碼化，Ant Design Pro基於Ant Design提供了一整套中後臺的網站框架和頁面模板，對於快速搭建很有幫助。Fusion Design和飛冰是通過打通設計和編碼環節，直接從sketch文件匯出相應的頁面程式碼，也是極大的釋放了前端同學碼頁面的工作量。

 

 

Flutter跨平臺解決方案 Flutter作為一個跨多端(iOS，Android，PC，Embedded)，具有美觀、快速、高效、開放的特點，目前在閒魚、貝殼、阿里等公司都有落地場景，作為下一代跨平臺解決方案我們可以持續關注，它具有一個非常巨集大的野心，背靠Google大廠，能夠從系統底層開始抹平各端差異，具有一個強大的技術架構來支援，長期來看還是挺值得期待的。

 

阿里前端委員會四大技術方向 以下內容摘抄自圓心的分享文稿

1. 搭建服務：可以看到整個搭建服務無論是在中後臺還是整個無線端，以及 PC 端都有大量場景，這樣大量場景需要把整個框架標準化，希望把裡面的元件、元件以及模組標準化，還希望把這樣的服務能夠服務於今天所有無論是中後臺也好，C 端頁面也好，希望有這樣的體系——服務化標準化的方式服務，打通整個體系，這就是為什麼把搭建服務認為是面向未來最重要的方向。

2. Serverless：可以讓前端更加貼近業務，可以讓更多能力下沉。前端轉到 Node 體系有一個很大的挑戰，但是到了 Serverless 我們可以不用關注部署，不用關注運維，不需要關注所有的 DevOps，也不需要關注底層資料庫的狀態，他會讓我們前後端整個的體系像前後端分層一樣又往前邁一步。

3. 智慧化：因為在 AI 來臨的時候，我們能否從一個 Design 變成一個 Code？今天每個公司的前端都有大量的設計、大量原始碼，我們通過大量設計稿和原始碼進行機器學習，讓中間的佈局可學習，讓中間的元件可學習，我相信未來 D2C 一定能夠解決前端生產力瓶頸，讓前端從今天大量低端開發、手工工作中解放出來，將精力轉移到很多領域深度的參與、深度的突破。

4. IDE：今天阿里的前端我們做了叫工程中臺，工程中臺做到了前端程式碼從提交到釋出的管控，當然包括中間提交之後整個程式碼的編譯、構建、檢測以及釋出。但是在前臺的部分，每個團隊都有一個工具，而這個工具在各團隊之間割裂的，無法複用。因為工程不僅僅是提交到釋出，前端工程化應該從編碼開始到釋出，應該是一個完整的鏈路、完整的格局

前端技術棧標準化 前端發展到現在，整個技術棧依舊處於百花齊放的階段，但是對於公司或者團隊而言，需要逐步從草莽時代走向正規軍時代，這就需要在技術棧標準化上做一些事情。例如對於一個10人左右的前端團隊而言，如果還是三大前端框架並存，那麼技術沉澱、程式碼複用都無從談起。所以對於一個前端團隊而言，標準化的技術棧是非常重要的，需要統一的腳手架、lint配置、mock工具、程式語言、框架、監控等等。

寫在最後

大前端的技術非常繁雜，由於個人和團隊精力有限，總是有不少遺漏還需要各位小夥伴們補充。對於各個技術所處的採用生命週期也限於個人的體驗，總是難免有些爭議，我只能儘可能做到相對合理。

將各個技術放在不同的生命週期中，本意不是去貶低某項技術，其實恰恰相反，能夠出現在Laggards週期往往說明這個技術得到歲月的洗禮，經過長時間的驗證。只是一個時代總是有一個時代主流的技術，這個總結期望大家能夠不斷自省審視當前的技術棧，保持在業界主流對於未來專案維護、吸引人才都是很有幫助的。

無論什麼樣的技術總會有過時的那一天，身為碼農還是要持續不斷學習，不要僅僅修煉術的方面停留在各種技術的使用之上，還要多多修煉道的方面，能夠撥開技術的表面，看清它背後的原理以及解決問題的本質。

有興趣同學可以關注微信公眾號奶爸碼農，不定期分享關於投資、理財、IT的資訊：