?2016-2026 Matools All rights reserved,
粵ICP備17059708號
在上一篇 <https://www.cnblogs.com/wdsunny/p/11278157.html>
文章中已經(jīng)介紹了大前端關于狀態(tài)管理、UI組件、小程序、跨平臺和框架層的內(nèi)容。在本文中，我會繼續(xù)介紹編程語言、工程化、監(jiān)控、測試和服務端，同時也會對下半年大前端可以關注的部分進行展望。
結(jié)合個人和團隊經(jīng)歷對2019上半年做個技術總結(jié)，將各類技術框架/語言/工具分作兩個維度：
* 技術采用生命周期
* 技術方向
?
編程語言?
來自statesofjs
<https://link.juejin.im?target=https%3A%2F%2F2018.stateofjs.com%2Fjavascript-flavors%2Foverview%2F>
的統(tǒng)計，在類JS編程語言上，ES6遙遙領先，TypeScript也獲得接近半數(shù)的使用量。其次是Flow、Reason、Elm和ClojureScript。
?
目前主流編程語言已經(jīng)是ES6/7+Babel的組合，用過ES6/7后基本沒法再回到原始的ES5時代了，出現(xiàn)了類和模塊的概念方便JS代碼模塊化加載，再加上各種語法糖用的快樂的飛起。async
await的語法也替代promise的寫法，使得代碼邏輯變得更加簡潔。ES的規(guī)范依舊在快速迭代，每年都會出一個更新的版本，引入不少語言特性，同時有Babel加持可以將新的語法都轉(zhuǎn)譯成ES5版本運行在瀏覽器中。
?
TypeScript是作為2019年的編程語言的大黑馬受到極大關注，現(xiàn)在有大量框架例如Mobx、Vue3.x都是用TypeScript進行編寫，由于TypeScript引入類型能夠做到靜態(tài)檢查，因此解決了大量JS運行時類型錯誤，對于大型項目的代碼安全性有很大的幫助。引入TypeScript需要團隊對于新的特性有充分的了解，好好利用其中的精華，否則就會變成僅僅把.js后綴改成.ts而已。
?
在2019 stateofcss
<https://link.juejin.im?target=https%3A%2F%2F2019.stateofcss.com%2F>
也有關于CSS特性使用情況的統(tǒng)計，每個特性的外圈代表聽過過的數(shù)量，內(nèi)圈表示真正使用過的數(shù)量。
?
其實CSS特性的使用覆蓋面很大因素取決于瀏覽器的支持程度，瀏覽器支持越好越容易獲得更高的使用率。可以看到幾個高使用率的CSS特性在瀏覽器支持方面都非常好，除去Opera
Mini和少量IE11，其他主流瀏覽器都能完美支持。
?
一個有趣的現(xiàn)象是在布局方面Flexbox使用率要高于Grid，可能的原因在于在低版本瀏覽器的支持方面Flexbox要更好，但其實在當前主流瀏覽器的支持度上已經(jīng)沒有區(qū)別。另一個因素可能是React
Native也是推薦使用Flexbox來做布局，具有較大的群眾基礎吧。
CSS in JS的理念應該來自React
Native，最開始接觸的時候相當顛覆，在JS文件中直接寫相應的CSS定義，使得組件內(nèi)聚化達到極致，解決了css全局污染的問題。在web前端，css in
js有很多的實現(xiàn)方式，但目前來看還是比較早期，傳統(tǒng)的Less、Sass的這類css預處理框架已經(jīng)能夠比較好的解決一些問題，從編程習慣上也一脈相承，因此css
in js理念不錯，但要得到推廣還需要時間。
CSS Houdini
?提出了一個前無古人的的設想：開放?CSS?的?API?給開發(fā)者，開發(fā)者可以通過這套接口自行擴展?CSS，并提供相應的工具允許開發(fā)者介入瀏覽器渲染引擎的樣式和布局流程中。簡單的說houdini可以讓大家去寫css
的polyfill從而極大的改善css新特性引入的速度。不過諷刺的是，它本身也需要瀏覽器支持，w3c標準還處于working
draft，大多數(shù)瀏覽器都還沒很好支持，大家可以期待一下～
工程化
提到工程化先拿騰訊直播團隊分享過的一張圖來鎮(zhèn)樓，很多小伙伴會狹隘的認為工程化就是webpack或者gulp打包而已，其實這個應該涵蓋從項目創(chuàng)建、開發(fā)、編譯、打包、測試、發(fā)布、監(jiān)控全流程。
?
項目初始化
項目腳手架目前已經(jīng)非常普遍，例如create-react-app或者vue-cli都是官方標準的腳手架工具。對于一些稍大的公司都建議自己包裝一套自己的腳手架，這樣可以沉淀很多最佳實踐，例如工程目錄結(jié)構(gòu)、lint配置、監(jiān)控配置、打點配置等等，因此腳手架是落地前端架構(gòu)標準化不可或缺的一環(huán)。
本地開發(fā) lint的規(guī)范一定要在項目初期就落地，可以直接拿airbnb的規(guī)范或者再定制化一下。lint可以極大的提升代碼質(zhì)量，至少從代碼風格來看可以保證統(tǒng)一。
Sonar的引入可以進一步提升代碼質(zhì)量，幫助分析出潛在的問題，同時分析代碼的重復率，過長的高數(shù)等等，這些都是所謂的代碼bad
smell，如果任其發(fā)展下去，項目維護成本會直線上升。Mock
工具的必要性在前后端聯(lián)調(diào)時就能充分提現(xiàn)，很多時候由于前后端接口定義不清晰導致聯(lián)調(diào)過程就是一個扯皮過程，如果缺乏mock工具，前端也會淪為后端接口調(diào)試的觸發(fā)器，前端頁面點一下，后端調(diào)試大半天，前端小伙伴們傷不起啊。Mock工具至少要有接口定義和本地mock的能力，能夠極大提升大家研發(fā)體驗。
打包 前端工程打包工具強烈推薦webpack 4，強大的插件能力能夠讓你做幾乎任何事情。webpack4中引入了更為強大智能的code
split能力，能夠極大縮減包大小，經(jīng)過實踐通常減小幅度都在30%-50%，而且在打包速度上也有很大改進，通常也有30%的提升。
監(jiān)控
當老板給你發(fā)一個線上問題的截屏，你本地又無法重現(xiàn)，又沒有足夠的日志，這時候是不是郁悶，和老板信任的小船說翻就翻了。
監(jiān)控從能力來看分為幾個階段： 第一階段：硬件運維能力，例如服務器運行情況，CPU、內(nèi)存、磁盤、網(wǎng)絡等等，在拓機情況下能夠快速響應。
第二階段：應用服務的監(jiān)控，例如服務可用性、異常流量監(jiān)控、頁面接口的響應時間、App crash等等。
第三階段：核心業(yè)務指標監(jiān)控，例如業(yè)務核心鏈路數(shù)據(jù)同比環(huán)比的對比等等。
第四階段：全鏈路的數(shù)據(jù)監(jiān)控，從客戶端、前端到服務層，到數(shù)據(jù)層，能夠通過唯一id串聯(lián)起來，可以方便回溯用戶操作，重現(xiàn)問題現(xiàn)場。
很顯然要做到監(jiān)控這四個階段需要做大量的基礎設施，往往大廠都有一套完備的輪子。對于小團隊而言，采用開源方案能夠快速補全能力。
Cat
是美團開源的業(yè)界良心監(jiān)控方案，對于前后端都有不錯的監(jiān)控能力，數(shù)據(jù)收集也很完備，能夠提供實時的性能指標、健康狀況、實時告警等數(shù)據(jù)，在多家互聯(lián)網(wǎng)公司也得到實踐，實屬拯救碼農(nóng)頭發(fā)的必備工具，你值得擁有～
umeng
作為移動端行為分析工具已經(jīng)有非常廣泛的使用，不過對于大廠而言用戶數(shù)據(jù)非常關鍵，如果有能力還是建議自研，畢竟用戶的行為數(shù)據(jù)是核心資產(chǎn)，將來可以基于這些數(shù)據(jù)做推薦、分析等等有價值的事情。
lighthouse/perf curve/perf budget
這些都是作為性能監(jiān)控的工具，不僅僅可以得到線上環(huán)境真實數(shù)據(jù)，還能在開發(fā)階段提前預警性能問題、落地性能優(yōu)化的最佳實踐，也是小伙伴們不可或缺的好伴侶～
測試
這里通常指的是自動化測試而非手工測試，從測試覆蓋范圍可以分為單元測試、UI測試、接口測試和功能自動化測試。我所經(jīng)歷的公司或團隊，幾乎沒有能把自動化測試能夠做好的，時間和需求頻繁變更往往是最大的借口，不過程序員內(nèi)心都不愿意寫測試用例的吧（手動捂臉）。
從落地難易程度來看，接口測試和單元測試最好落地，接口不說了難度不高收益還不錯，主要需要對數(shù)據(jù)準備有些要求。單元測試首推Jest
，同時還能統(tǒng)計出覆蓋率，但是單元測試要明確好可以測試的范圍，一般業(yè)務邏輯和底層通用方法比較適合。所以業(yè)務邏輯代碼從UI層代碼抽離非常重要，這時候redux這類狀態(tài)管理框架就有了天然優(yōu)勢了，里面reducer、action部分就可以單測覆蓋。
UI的測試一般對于組件庫有點幫助，簡單的做法就是通過snapshot進行dom對比，簡單粗暴。功能自動化很少能夠落地，appium或者selenium都是其中翹楚，需要看業(yè)務情況，如果有頻繁頁面改動，一開始功能自動化寫的爽，后續(xù)維護成本大的驚人，而且由于功能覆蓋時間差，還是需要大量手動測試的。
服務端
自從出現(xiàn)Node之后，前端技術正式進入服務端開發(fā)，從而讓前端的小伙伴們可以進行全棧的開發(fā)，技術棧的范疇變的更大，對于業(yè)務的把控能力也變強了。
Node可以帶來幾個明顯的好處 第一，可以作為BFF(Backend for
Frontend)層，解決前后端接口頻繁變更的問題，通過BFF層可以實現(xiàn)更加靈活的接口，接口字段的過濾，接口的聚合等等 第二，可以用做SSR(Server
Side Render)，通過Node層同構(gòu)直出，可以將前端渲染代碼放在服務端，實現(xiàn)首屏的服務端渲染，提升首屏渲染時間
第三，基于“只要能用JS實現(xiàn)，最終都會用JS實現(xiàn)”定律，Node讓前端同學可以用JS擼后端代碼，這個掌控一切的感覺太爽了~
Node也存在一些缺點
第一，需要額外的服務器，很多場景下Node層僅僅做接口透傳的工作，對于服務器是一種浪費，而且作為一個核心節(jié)點如果一旦掛掉整個應用都不可用
第二，需要對Node服務有一整套的打包、部署、監(jiān)控等能力，這個對于前端同學來說提出了較高的運維能力的要求，這些事情往往讓前端同學苦不堪言
服務端最近可以持續(xù)關注GraphQL/Serverless，這兩項技術對于前后端的架構(gòu)設計都會帶來深遠的影響。
2019年下半年展望
?
中后臺的重塑
針對中后臺業(yè)務特點，缺乏詳盡的交互設計，缺乏足夠的前端資源，頁面樣式相對統(tǒng)一，業(yè)界提出通過少量代碼或者無代碼方式搭建中后臺前端系統(tǒng)。目前有的一些最佳實踐：Fusion
Design，飛冰，Ant Design Pro。大家都是從幾個方向去實現(xiàn)中后臺前端系統(tǒng)的無代碼化，Ant Design Pro基于Ant
Design提供了一整套中后臺的網(wǎng)站框架和頁面模板，對于快速搭建很有幫助。Fusion
Design和飛冰是通過打通設計和編碼環(huán)節(jié)，直接從sketch文檔導出相應的頁面代碼，也是極大的釋放了前端同學碼頁面的工作量。
?
?
Flutter跨平臺解決方案 Flutter作為一個跨多端(iOS，Android，PC，Embedded)，具有美觀、快速、高效、開放
的特點，目前在閑魚、貝殼、阿里等公司都有落地場景，作為下一代跨平臺解決方案我們可以持續(xù)關注，它具有一個非常宏大的野心，背靠Google大廠，能夠從系統(tǒng)底層開始抹平各端差異，具有一個強大的技術架構(gòu)來支持，長期來看還是挺值得期待的。
?
阿里前端委員會四大技術方向 以下內(nèi)容摘抄自圓心的分享文稿
*
搭建服務：可以看到整個搭建服務無論是在中后臺還是整個無線端，以及 PC
端都有大量場景，這樣大量場景需要把整個框架標準化，希望把里面的元件、組件以及模塊標準化，還希望把這樣的服務能夠服務于今天所有無論是中后臺也好，C
端頁面也好，希望有這樣的體系——服務化標準化的方式服務，打通整個體系，這就是為什么把搭建服務認為是面向未來最重要的方向。
*
Serverless：可以讓前端更加貼近業(yè)務，可以讓更多能力下沉。前端轉(zhuǎn)到 Node 體系有一個很大的挑戰(zhàn)，但是到了 Serverless
我們可以不用關注部署，不用關注運維，不需要關注所有的 DevOps，也不需要關注底層數(shù)據(jù)庫的狀態(tài)，他會讓我們前后端整個的體系像前后端分層一樣又往前邁一步。
*
智能化：因為在 AI 來臨的時候，我們能否從一個 Design 變成一個
Code？今天每個公司的前端都有大量的設計、大量原代碼，我們通過大量設計稿和原代碼進行機器學習，讓中間的布局可學習，讓中間的元件可學習，我相信未來 D2C
一定能夠解決前端生產(chǎn)力瓶頸，讓前端從今天大量低端開發(fā)、手工工作中解放出來，將精力轉(zhuǎn)移到很多領域深度的參與、深度的突破。
*
IDE
：今天阿里的前端我們做了叫工程中臺，工程中臺做到了前端代碼從提交到發(fā)布的管控，當然包括中間提交之后整個代碼的編譯、構(gòu)建、檢測以及發(fā)布。但是在前臺的部分，每個團隊都有一個工具，而這個工具在各團隊之間割裂的，無法復用。因為工程不僅僅是提交到發(fā)布，前端工程化應該從編碼開始到發(fā)布，應該是一個完整的鏈路、完整的格局
前端技術棧標準化
前端發(fā)展到現(xiàn)在，整個技術棧依舊處于百花齊放的階段，但是對于公司或者團隊而言，需要逐步從草莽時代走向正規(guī)軍時代，這就需要在技術棧標準化上做一些事情。例如對于一個10人左右的前端團隊而言，如果還是三大前端框架并存，那么技術沉淀、代碼復用都無從談起。所以對于一個前端團隊而言，標準化的技術棧是非常重要的，需要統(tǒng)一的腳手架、lint配置、mock工具、編程語言、框架、監(jiān)控等等。
寫在最后
大前端的技術非常繁雜，由于個人和團隊精力有限，總是有不少遺漏還需要各位小伙伴們補充。對于各個技術所處的采用生命周期也限于個人的體驗，總是難免有些爭議，我只能盡可能做到相對合理。
將各個技術放在不同的生命周期中，本意不是去貶低某項技術，其實恰恰相反，能夠出現(xiàn)在Laggards周期往往說明這個技術得到歲月的洗禮，經(jīng)過長時間的驗證。只是一個時代總是有一個時代主流的技術，這個總結(jié)期望大家能夠不斷自省審視當前的技術棧，保持在業(yè)界主流對于未來項目維護、吸引人才都是很有幫助的。
無論什么樣的技術總會有過時的那一天，身為碼農(nóng)還是要持續(xù)不斷學習，不要僅僅修煉術的方面停留在各種技術的使用之上，還要多多修煉道的方面，能夠撥開技術的表面，看清它背后的原理以及解決問題的本質(zhì)。
有興趣同學可以關注微信公眾號奶爸碼農(nóng)，不定期分享關于投資、理財、IT的信息：
?
?
熱門工具 換一換