在上一篇文章中已經介紹了大前端關於狀態管理、UI組件、小程序、跨平台和框架層的內容。在本文中，我會繼續介紹編程語言、工程化、監控、測試和服務端，同時也會對下半年大前端可以關注的部分進行展望。
結合個人和團隊經歷對2019上半年做個技術總結，將各類技術框架/語言/工具分作兩個維度：
- 技術采用生命周期
- 技術方向
編程語言
來自
statesofjs的統計，在類JS編程語言上，ES6遙遙領先，TypeScript也獲得接近半數的使用量。其次是Flow、Reason、Elm和ClojureScript。
目前主流編程語言已經是ES6/7+Babel的組合，用過ES6/7后基本沒法再回到原始的ES5時代了，出現了類和模塊的概念方便JS代碼模塊化加載，再加上各種語法糖用的快樂的飛起。async await的語法也替代promise的寫法，使得代碼邏輯變得更加簡潔。ES的規范依舊在快速迭代，每年都會出一個更新的版本，引入不少語言特性，同時有Babel加持可以將新的語法都轉譯成ES5版本運行在瀏覽器中。
在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大廠，能夠從系統底層開始抹平各端差異，具有一個強大的技術架構來支持，長期來看還是挺值得期待的。
阿里前端委員會四大技術方向 以下內容摘抄自圓心的分享文稿
-
搭建服務：可以看到整個搭建服務無論是在中后台還是整個無線端，以及 PC 端都有大量場景，這樣大量場景需要把整個框架標准化，希望把里面的元件、組件以及模塊標准化，還希望把這樣的服務能夠服務於今天所有無論是中后台也好，C 端頁面也好，希望有這樣的體系——服務化標准化的方式服務，打通整個體系，這就是為什么把搭建服務認為是面向未來最重要的方向。
-
Serverless：可以讓前端更加貼近業務，可以讓更多能力下沉。前端轉到 Node 體系有一個很大的挑戰，但是到了 Serverless 我們可以不用關注部署，不用關注運維，不需要關注所有的 DevOps，也不需要關注底層數據庫的狀態，他會讓我們前后端整個的體系像前后端分層一樣又往前邁一步。
-
智能化：因為在 AI 來臨的時候，我們能否從一個 Design 變成一個 Code？今天每個公司的前端都有大量的設計、大量原代碼，我們通過大量設計稿和原代碼進行機器學習，讓中間的布局可學習，讓中間的元件可學習，我相信未來 D2C 一定能夠解決前端生產力瓶頸，讓前端從今天大量低端開發、手工工作中解放出來，將精力轉移到很多領域深度的參與、深度的突破。
-
IDE：今天阿里的前端我們做了叫工程中台，工程中台做到了前端代碼從提交到發布的管控，當然包括中間提交之后整個代碼的編譯、構建、檢測以及發布。但是在前台的部分，每個團隊都有一個工具，而這個工具在各團隊之間割裂的，無法復用。因為工程不僅僅是提交到發布，前端工程化應該從編碼開始到發布，應該是一個完整的鏈路、完整的格局
前端技術棧標准化 前端發展到現在，整個技術棧依舊處於百花齊放的階段，但是對於公司或者團隊而言，需要逐步從草莽時代走向正規軍時代，這就需要在技術棧標准化上做一些事情。例如對於一個10人左右的前端團隊而言，如果還是三大前端框架並存，那么技術沉淀、代碼復用都無從談起。所以對於一個前端團隊而言，標准化的技術棧是非常重要的，需要統一的腳手架、lint配置、mock工具、編程語言、框架、監控等等。
寫在最后
大前端的技術非常繁雜，由於個人和團隊精力有限，總是有不少遺漏還需要各位小伙伴們補充。對於各個技術所處的采用生命周期也限於個人的體驗，總是難免有些爭議，我只能盡可能做到相對合理。
將各個技術放在不同的生命周期中，本意不是去貶低某項技術，其實恰恰相反，能夠出現在Laggards周期往往說明這個技術得到歲月的洗禮，經過長時間的驗證。只是一個時代總是有一個時代主流的技術，這個總結期望大家能夠不斷自省審視當前的技術棧，保持在業界主流對於未來項目維護、吸引人才都是很有幫助的。
無論什么樣的技術總會有過時的那一天，身為碼農還是要持續不斷學習，不要僅僅修煉術的方面停留在各種技術的使用之上，還要多多修煉道的方面，能夠撥開技術的表面，看清它背后的原理以及解決問題的本質。
有興趣同學可以關注微信公眾號奶爸碼農，不定期分享關於投資、理財、IT的信息：
