不会比这更详细的前端工程化的入门教程了
本文將分成以下 7 個小節(jié)：
部分小節(jié)提供了非常詳細的實戰(zhàn)教程，讓大家動手實踐。
另外我還寫了一個前端工程化 demo 放在?github?上。這個 demo 包含了 js、css、git 驗證，其中 js、css 驗證需要安裝 VSCode，具體教程在下文中會有提及。
技術(shù)選型
對于前端來說，技術(shù)選型挺簡單的。就是做選擇題，三大框架中選一個。個人認為可以依據(jù)以下兩個特點來選：
第二點對于小公司來說，特別重要。本來小公司就不好招人，要是還選一個市場占有率不高的框架（例如 Angular），簡歷你都看不到幾個...
UI 組件庫更簡單，github 上哪個 star 多就用哪個。star 多，說明用的人就多，很多坑別人都替你踩過了，省事。
統(tǒng)一規(guī)范
代碼規(guī)范
先來看看統(tǒng)一代碼規(guī)范的好處：
- 規(guī)范的代碼可以促進團隊合作
- 規(guī)范的代碼可以降低維護成本
- 規(guī)范的代碼有助于 code review（代碼審查）
- 養(yǎng)成代碼規(guī)范的習(xí)慣，有助于程序員自身的成長
當團隊的成員都嚴格按照代碼規(guī)范來寫代碼時，可以保證每個人的代碼看起來都像是一個人寫的，看別人的代碼就像是在看自己的代碼。更重要的是我們能夠認識到規(guī)范的重要性，并堅持規(guī)范的開發(fā)習(xí)慣。
如何制訂代碼規(guī)范
建議找一份好的代碼規(guī)范，在此基礎(chǔ)上結(jié)合團隊的需求作個性化修改。
下面列舉一些 star 較多的 js 代碼規(guī)范：
- airbnb (101k star 英文版)，airbnb-中文版
- standard (24.5k star) 中文版
- 百度前端編碼規(guī)范 3.9k
css 代碼規(guī)范也有不少，例如：
- styleguide 2.3k
- spec 3.9k
如何檢查代碼規(guī)范
使用 eslint 可以檢查代碼符不符合團隊制訂的規(guī)范，下面來看一下如何配置 eslint 來檢查代碼。
不過這樣檢查代碼效率太低，每次都得手動檢查。并且報錯了還得手動修改代碼。
為了改善以上缺點，我們可以使用 VSCode。使用它并加上適當?shù)呐渲每梢栽诿看伪４娲a的時候，自動驗證代碼并進行格式化，省去了動手的麻煩。
css 檢查代碼規(guī)范則使用?stylelint?插件。
由于篇幅有限，具體如何配置請看我的另一篇文章ESlint + stylelint + VSCode自動格式化代碼(2020)。
git 規(guī)范
git 規(guī)范包括兩點：分支管理規(guī)范、git commit 規(guī)范。
分支管理規(guī)范
一般項目分主分支（master）和其他分支。
當有團隊成員要開發(fā)新功能或改 BUG 時，就從 master 分支開一個新的分支。例如項目要從客戶端渲染改成服務(wù)端渲染，就開一個分支叫 ssr，開發(fā)完了再合并回 master 分支。
如果改一個 BUG，也可以從 master 分支開一個新分支，并用 BUG 號命名（不過我們小團隊嫌麻煩，沒這樣做，除非有特別大的 BUG）。
git commit 規(guī)范
<type>(<scope>): <subject> <BLANK LINE> <body> <BLANK LINE> <footer>大致分為三個部分(使用空行分割):
type: commit 的類型
- feat: 新功能、新特性
- fix: 修改 bug
- perf: 更改代碼，以提高性能
- refactor: 代碼重構(gòu)（重構(gòu)，在不影響代碼內(nèi)部行為、功能下的代碼修改）
- docs: 文檔修改
- style: 代碼格式修改, 注意不是 css 修改（例如分號修改）
- test: 測試用例新增、修改
- build: 影響項目構(gòu)建或依賴項修改
- revert: 恢復(fù)上一次提交
- ci: 持續(xù)集成相關(guān)文件修改
- chore: 其他修改（不在上述類型中的修改）
- release: 發(fā)布新版本
- workflow: 工作流相關(guān)文件修改
示例
fix（修復(fù)BUG）
如果修復(fù)的這個BUG只影響當前修改的文件，可不加范圍。如果影響的范圍比較大，要加上范圍描述。
例如這次 BUG 修復(fù)影響到全局，可以加個 global。如果影響的是某個目錄或某個功能，可以加上該目錄的路徑，或者對應(yīng)的功能名稱。
// 示例1 fix(global):修復(fù)checkbox不能復(fù)選的問題 // 示例2 下面圓括號里的 common 為通用管理的名稱 fix(common): 修復(fù)字體過小的BUG，將通用管理下所有頁面的默認字體大小修改為 14px // 示例3 fix: value.length -> values.lengthfeat（添加新功能或新頁面）
feat: 添加網(wǎng)站主頁靜態(tài)頁面這是一個示例，假設(shè)對點檢任務(wù)靜態(tài)頁面進行了一些描述。這里是備注，可以是放BUG鏈接或者一些重要性的東西。chore（其他修改）
chore 的中文翻譯為日常事務(wù)、例行工作，顧名思義，即不在其他 commit 類型中的修改，都可以用 chore 表示。
chore: 將表格中的查看詳情改為詳情其他類型的 commit 和上面三個示例差不多，就不說了。
驗證 git commit 規(guī)范
驗證 git commit 規(guī)范，主要通過 git 的?pre-commit?鉤子函數(shù)來進行。當然，你還需要下載一個輔助工具來幫助你進行驗證。
下載輔助工具
npm?i?-D husky在?package.json?加上下面的代碼
"husky": {"hooks": {"pre-commit": "npm run lint","commit-msg": "node script/verify-commit.js","pre-push": "npm test"} }然后在你項目根目錄下新建一個文件夾?script，并在下面新建一個文件?verify-commit.js，輸入以下代碼：
const msgPath = process.env.HUSKY_GIT_PARAMS const msg = require('fs') .readFileSync(msgPath, 'utf-8') .trim()const commitRE = /^(feat|fix|docs|style|refactor|perf|test|workflow|build|ci|chore|release|workflow)(\(.+\))?: .{1,50}/if (!commitRE.test(msg)) {console.log()console.error(`不合法的 commit 消息格式。請查看 git commit 提交規(guī)范：https://github.com/woai3c/Front-end-articles/blob/master/git%20commit%20style.md`)process.exit(1) }現(xiàn)在來解釋下各個鉤子的含義：
項目規(guī)范
主要是項目文件的組織方式和命名方式。
用我們的 Vue 項目舉個例子。
├─public ├─src ├─test一個項目包含 public（公共資源，不會被 webpack 處理）、src（源碼）、test（測試代碼），其中 src 目錄，又可以細分。
├─api （接口） ├─assets （靜態(tài)資源） ├─components （公共組件） ├─styles （公共樣式） ├─router （路由） ├─store （vuex 全局數(shù)據(jù)） ├─utils （工具函數(shù)） └─views （頁面）文件名稱如果過長則用 - 隔開。
UI 規(guī)范
UI 規(guī)范需要前端、UI、產(chǎn)品溝通，互相商量，最后制定下來，建議使用統(tǒng)一的 UI 組件庫。
制定 UI 規(guī)范的好處：
- 統(tǒng)一頁面 UI 標準，節(jié)省 UI 設(shè)計時間
- 提高前端開發(fā)效率
測試
測試是前端工程化建設(shè)必不可少的一部分，它的作用就是找出 bug，越早發(fā)現(xiàn) bug，所需要付出的成本就越低。并且，它更重要的作用是在將來，而不是當下。
設(shè)想一下半年后，你的項目要加一個新功能。在加完新功能后，你不確定有沒有影響到原有的功能，需要測試一下。由于時間過去太久，你對項目的代碼已經(jīng)不了解了。在這種情況下，如果沒有寫測試，你就得手動一遍一遍的去試。而如果寫了測試，你只需要跑一遍測試代碼就 OK 了，省時省力。
寫測試還可以讓你修改代碼時沒有心理負擔(dān)，不用一直想著改這里有沒有問題？會不會引起 BUG？而寫了測試就沒有這種擔(dān)心了。
在前端用得最多的就是單元測試（主要是端到端測試我用得很少，不熟），這里著重講解一下。
單元測試
單元測試就是對一個函數(shù)、一個組件、一個類做的測試，它針對的粒度比較小。
它應(yīng)該怎么寫呢？
對一個函數(shù)做測試
例如一個取絕對值的函數(shù)?abs()，輸入?1,2，結(jié)果應(yīng)該與輸入相同；輸入?-1,-2，結(jié)果應(yīng)該與輸入相反。如果輸入非數(shù)字，例如?"abc"，應(yīng)該拋出一個類型錯誤。
對一個類做測試
假設(shè)有這樣一個類：
class Math {abs() {}sqrt() {}pow() {}... }單元測試，必須把這個類的所有方法都測一遍。
對一個組件做測試
組件測試比較難，因為很多組件都涉及了 DOM 操作。
例如一個上傳圖片組件，它有一個將圖片轉(zhuǎn)成 base64 碼的方法，那要怎么測試呢？一般測試都是跑在 node 環(huán)境下的，而 node 環(huán)境沒有 DOM 對象。
我們先來回顧一下上傳圖片的過程：
這個過程和下面的代碼是一樣的：
document.querySelector('input').onchange = function fileChangeHandler(e) {const file = e.target.files[0]const reader = new FileReader()reader.onload = (res) => {const fileResult = res.target.resultconsole.log(fileResult) // 輸出 base64 碼}reader.readAsDataURL(file) }上面的代碼只是模擬，真實情況下應(yīng)該是這樣使用
document.querySelector('input').onchange = function fileChangeHandler(e) {const file = e.target.files[0]tobase64(file) }function tobase64(file) {return new Promise((resolve, reject) => {const reader = new FileReader()reader.onload = (res) => {const fileResult = res.target.resultresolve(fileResult) // 輸出 base64 碼}reader.readAsDataURL(file)}) }可以看到，上面代碼出現(xiàn)了 window 的事件對象?event、FileReader。也就是說，只要我們能夠提供這兩個對象，就可以在任何環(huán)境下運行它。所以我們可以在測試環(huán)境下加上這兩個對象：
// 重寫 File window.File = function () {}// 重寫 FileReader window.FileReader = function () {this.readAsDataURL = function () {this.onload&& this.onload({target: {result: fileData,},})} }然后測試可以這樣寫：
// 提前寫好文件內(nèi)容 const fileData = 'data:image/test'// 提供一個假的 file 對象給 tobase64() 函數(shù) function test() {const file = new File()const event = { target: { files: [file] } }file.type = 'image/png'file.name = 'test.png'file.size = 1024it('file content', (done) => {tobase64(file).then(base64 => {expect(base64).toEqual(fileData) // 'data:image/test'done()})}) }// 執(zhí)行測試 test()通過這種 hack 的方式，我們就實現(xiàn)了對涉及 DOM 操作的組件的測試。我的?vue-upload-imgs?庫就是通過這種方式寫的單元測試，有興趣可以了解一下。
TDD 測試驅(qū)動開發(fā)
TDD 就是根據(jù)需求提前把測試代碼寫好，然后根據(jù)測試代碼實現(xiàn)功能。
TDD 的初衷是好的，但如果你的需求經(jīng)常變（你懂的），那就不是一件好事了。很有可能你天天都在改測試代碼，業(yè)務(wù)代碼反而沒怎么動。
所以到現(xiàn)在為止，三年多的程序員生涯，我還沒嘗試過 TDD 開發(fā)。
雖然環(huán)境如此艱難，但有條件的情況下還是應(yīng)該試一下 TDD 的。例如在你自己負責(zé)一個項目又不忙的時候，可以采用此方法編寫測試用例。
測試框架推薦
我常用的測試框架是?jest，好處是有中文文檔，API 清晰明了，一看就知道是干什么用的。
部署
在沒有學(xué)會自動部署前，我是這樣部署項目的：
一次兩次還行，如果天天都這樣，就會把很多時間浪費在重復(fù)的操作上。所以我們要學(xué)會自動部署，徹底解放雙手。
自動部署（又叫持續(xù)部署 Continuous Deployment，英文縮寫 CD）一般有兩種觸發(fā)方式：
輪詢
輪詢，就是構(gòu)建軟件每隔一段時間自動執(zhí)行打包、部署操作。
這種方式不太好，很有可能軟件剛部署完我就改代碼了。為了看到新的頁面效果，不得不等到下一次構(gòu)建開始。
另外還有一個副作用，假如我一天都沒更改代碼，構(gòu)建軟件還是會不停的執(zhí)行打包、部署操作，白白的浪費資源。
所以現(xiàn)在的構(gòu)建軟件基本采用監(jiān)聽?webhook?事件的方式來進行部署。
監(jiān)聽?webhook?事件
webhook 鉤子函數(shù)，就是在你的構(gòu)建軟件上進行設(shè)置，監(jiān)聽某一個事件（一般是監(jiān)聽?push?事件），當事件觸發(fā)時，自動執(zhí)行定義好的腳本。
例如?Github Actions，就有這個功能。
對于新人來說，僅看我這一段講解是不可能學(xué)會自動部署的。為此我特地寫了一篇自動化部署教程，不需要你提前學(xué)習(xí)自動化部署的知識，只要照著指引做，就能實現(xiàn)前端項目自動化部署。
前端項目自動化部署——超詳細教程（Jenkins、Github Actions），教程已經(jīng)奉上，各位大佬看完后要是覺得有用，不要忘了點贊，感激不盡。
監(jiān)控
監(jiān)控，又分性能監(jiān)控和錯誤監(jiān)控，它的作用是預(yù)警和追蹤定位問題。
性能監(jiān)控
性能監(jiān)控一般利用?window.performance?來進行數(shù)據(jù)采集。
Performance 接口可以獲取到當前頁面中與性能相關(guān)的信息，它是 High Resolution Time API 的一部分，同時也融合了 Performance Timeline API、Navigation Timing API、 User Timing API 和 Resource Timing API。這個 API 的屬性?timing，包含了頁面加載各個階段的起始及結(jié)束時間。
為了方便大家理解?timing?各個屬性的意義，我在知乎找到一位網(wǎng)友對于?timing?寫的簡介（忘了姓名，后來找不到了，見諒），在此轉(zhuǎn)載一下。
timing: {// 同一個瀏覽器上一個頁面卸載(unload)結(jié)束時的時間戳。如果沒有上一個頁面，這個值會和fetchStart相同。navigationStart: 1543806782096,// 上一個頁面unload事件拋出時的時間戳。如果沒有上一個頁面，這個值會返回0。unloadEventStart: 1543806782523,// 和 unloadEventStart 相對應(yīng)，unload事件處理完成時的時間戳。如果沒有上一個頁面,這個值會返回0。unloadEventEnd: 1543806782523,// 第一個HTTP重定向開始時的時間戳。如果沒有重定向，或者重定向中的一個不同源，這個值會返回0。redirectStart: 0,// 最后一個HTTP重定向完成時（也就是說是HTTP響應(yīng)的最后一個比特直接被收到的時間）的時間戳。// 如果沒有重定向，或者重定向中的一個不同源，這個值會返回0. redirectEnd: 0,// 瀏覽器準備好使用HTTP請求來獲取(fetch)文檔的時間戳。這個時間點會在檢查任何應(yīng)用緩存之前。fetchStart: 1543806782096,// DNS 域名查詢開始的UNIX時間戳。//如果使用了持續(xù)連接(persistent connection)，或者這個信息存儲到了緩存或者本地資源上，這個值將和fetchStart一致。domainLookupStart: 1543806782096,// DNS 域名查詢完成的時間.//如果使用了本地緩存（即無 DNS 查詢）或持久連接，則與 fetchStart 值相等domainLookupEnd: 1543806782096,// HTTP（TCP） 域名查詢結(jié)束的時間戳。//如果使用了持續(xù)連接(persistent connection)，或者這個信息存儲到了緩存或者本地資源上，這個值將和 fetchStart一致。connectStart: 1543806782099,// HTTP（TCP） 返回瀏覽器與服務(wù)器之間的連接建立時的時間戳。// 如果建立的是持久連接，則返回值等同于fetchStart屬性的值。連接建立指的是所有握手和認證過程全部結(jié)束。connectEnd: 1543806782227,// HTTPS 返回瀏覽器與服務(wù)器開始安全鏈接的握手時的時間戳。如果當前網(wǎng)頁不要求安全連接，則返回0。secureConnectionStart: 1543806782162,// 返回瀏覽器向服務(wù)器發(fā)出HTTP請求時（或開始讀取本地緩存時）的時間戳。requestStart: 1543806782241,// 返回瀏覽器從服務(wù)器收到（或從本地緩存讀取）第一個字節(jié)時的時間戳。//如果傳輸層在開始請求之后失敗并且連接被重開，該屬性將會被數(shù)制成新的請求的相對應(yīng)的發(fā)起時間。responseStart: 1543806782516,// 返回瀏覽器從服務(wù)器收到（或從本地緩存讀取，或從本地資源讀取）最后一個字節(jié)時//（如果在此之前HTTP連接已經(jīng)關(guān)閉，則返回關(guān)閉時）的時間戳。responseEnd: 1543806782537,// 當前網(wǎng)頁DOM結(jié)構(gòu)開始解析時（即Document.readyState屬性變?yōu)椤發(fā)oading”、相應(yīng)的 readystatechange事件觸發(fā)時）的時間戳。domLoading: 1543806782573,// 當前網(wǎng)頁DOM結(jié)構(gòu)結(jié)束解析、開始加載內(nèi)嵌資源時（即Document.readyState屬性變?yōu)椤癷nteractive”、相應(yīng)的readystatechange事件觸發(fā)時）的時間戳。domInteractive: 1543806783203,// 當解析器發(fā)送DOMContentLoaded 事件，即所有需要被執(zhí)行的腳本已經(jīng)被解析時的時間戳。domContentLoadedEventStart: 1543806783203,// 當所有需要立即執(zhí)行的腳本已經(jīng)被執(zhí)行（不論執(zhí)行順序）時的時間戳。domContentLoadedEventEnd: 1543806783216,// 當前文檔解析完成，即Document.readyState 變?yōu)?'complete'且相對應(yīng)的readystatechange 被觸發(fā)時的時間戳domComplete: 1543806783796,// load事件被發(fā)送時的時間戳。如果這個事件還未被發(fā)送，它的值將會是0。loadEventStart: 1543806783796,// 當load事件結(jié)束，即加載事件完成時的時間戳。如果這個事件還未被發(fā)送，或者尚未完成，它的值將會是0.loadEventEnd: 1543806783802 }通過以上數(shù)據(jù)，我們可以得到幾個有用的時間
// 重定向耗時 redirect: timing.redirectEnd - timing.redirectStart, // DOM 渲染耗時 dom: timing.domComplete - timing.domLoading, // 頁面加載耗時 load: timing.loadEventEnd - timing.navigationStart, // 頁面卸載耗時 unload: timing.unloadEventEnd - timing.unloadEventStart, // 請求耗時 request: timing.responseEnd - timing.requestStart, // 獲取性能信息時當前時間 time: new Date().getTime(),還有一個比較重要的時間就是白屏?xí)r間，它指從輸入網(wǎng)址，到頁面開始顯示內(nèi)容的時間。
將以下腳本放在?</head>?前面就能獲取白屏?xí)r間。
<script>whiteScreen = new Date() - performance.timing.navigationStart </script>通過這幾個時間，就可以得知頁面首屏加載性能如何了。
另外，通過?window.performance.getEntriesByType('resource')?這個方法，我們還可以獲取相關(guān)資源（js、css、img...）的加載時間，它會返回頁面當前所加載的所有資源。
它一般包括以下幾個類型
- sciprt
- link
- img
- css
- fetch
- other
- xmlhttprequest
我們只需用到以下幾個信息
// 資源的名稱 name: item.name, // 資源加載耗時 duration: item.duration.toFixed(2), // 資源大小 size: item.transferSize, // 資源所用協(xié)議 protocol: item.nextHopProtocol,現(xiàn)在，寫幾行代碼來收集這些數(shù)據(jù)。
// 收集性能信息 const getPerformance = () => {if (!window.performance) returnconst timing = window.performance.timingconst performance = {// 重定向耗時redirect: timing.redirectEnd - timing.redirectStart,// 白屏?xí)r間whiteScreen: whiteScreen,// DOM 渲染耗時dom: timing.domComplete - timing.domLoading,// 頁面加載耗時load: timing.loadEventEnd - timing.navigationStart,// 頁面卸載耗時unload: timing.unloadEventEnd - timing.unloadEventStart,// 請求耗時request: timing.responseEnd - timing.requestStart,// 獲取性能信息時當前時間time: new Date().getTime(),}return performance }// 獲取資源信息 const getResources = () => {if (!window.performance) returnconst data = window.performance.getEntriesByType('resource')const resource = {xmlhttprequest: [],css: [],other: [],script: [],img: [],link: [],fetch: [],// 獲取資源信息時當前時間time: new Date().getTime(),}data.forEach(item => {const arry = resource[item.initiatorType]arry && arry.push({// 資源的名稱name: item.name,// 資源加載耗時duration: item.duration.toFixed(2),// 資源大小size: item.transferSize,// 資源所用協(xié)議protocol: item.nextHopProtocol,})})return resource }小結(jié)
通過對性能及資源信息的解讀，我們可以判斷出頁面加載慢有以下幾個原因：
除了用戶網(wǎng)速過慢，我們沒辦法之外，其他兩個原因都是有辦法解決的，性能優(yōu)化將在下一節(jié)《性能優(yōu)化》中會講到。
錯誤監(jiān)控
現(xiàn)在能捕捉的錯誤有三種。
我們可以建一個錯誤數(shù)組變量?errors?在錯誤發(fā)生時，將錯誤的相關(guān)信息添加到數(shù)組，然后在某個階段統(tǒng)一上報，具體如何操作請看代碼
// 捕獲資源加載失敗錯誤 js css img... addEventListener('error', e => {const target = e.targetif (target != window) {monitor.errors.push({type: target.localName,url: target.src || target.href,msg: (target.src || target.href) + ' is load error',// 錯誤發(fā)生的時間time: new Date().getTime(),})} }, true)// 監(jiān)聽 js 錯誤 window.onerror = function(msg, url, row, col, error) {monitor.errors.push({type: 'javascript',row: row,col: col,msg: error && error.stack? error.stack : msg,url: url,// 錯誤發(fā)生的時間time: new Date().getTime(),}) }// 監(jiān)聽 promise 錯誤 缺點是獲取不到行數(shù)數(shù)據(jù) addEventListener('unhandledrejection', e => {monitor.errors.push({type: 'promise',msg: (e.reason && e.reason.msg) || e.reason || '',// 錯誤發(fā)生的時間time: new Date().getTime(),}) })小結(jié)
通過錯誤收集，可以了解到網(wǎng)站錯誤發(fā)生的類型及數(shù)量，從而可以做相應(yīng)的調(diào)整，以減少錯誤發(fā)生。
完整代碼和 DEMO 請看我另一篇文章前端性能和錯誤監(jiān)控的末尾，大家可以復(fù)制代碼（HTML文件）在本地測試一下。
數(shù)據(jù)上報
性能數(shù)據(jù)上報
性能數(shù)據(jù)可以在頁面加載完之后上報，盡量不要對頁面性能造成影響。
window.onload = () => {// 在瀏覽器空閑時間獲取性能及資源信息// https://developer.mozilla.org/zh-CN/docs/Web/API/Window/requestIdleCallbackif (window.requestIdleCallback) {window.requestIdleCallback(() => {monitor.performance = getPerformance()monitor.resources = getResources()})} else {setTimeout(() => {monitor.performance = getPerformance()monitor.resources = getResources()}, 0)} }當然，你也可以設(shè)一個定時器，循環(huán)上報。不過每次上報最好做一下對比去重再上報，避免同樣的數(shù)據(jù)重復(fù)上報。
錯誤數(shù)據(jù)上報
我在DEMO里提供的代碼，是用一個?errors?數(shù)組收集所有的錯誤，再在某一階段統(tǒng)一上報（延時上報）。
其實，也可以改成在錯誤發(fā)生時上報（即時上報）。這樣可以避免在收集完錯誤延時上報還沒觸發(fā)，用戶卻已經(jīng)關(guān)掉網(wǎng)頁導(dǎo)致錯誤數(shù)據(jù)丟失的問題。
SPA
window.performance?API 是有缺點的，在 SPA 切換路由時，window.performance.timing?的數(shù)據(jù)不會更新。
所以我們需要另想辦法來統(tǒng)計切換路由到加載完成的時間。
拿 Vue 舉例，一個可行的辦法就是切換路由時，在路由的全局前置守衛(wèi)?beforeEach?里獲取開始時間，在組件的?mounted?鉤子里執(zhí)行?vm.$nextTick?函數(shù)來獲取組件的渲染完畢時間。
除了性能和錯誤監(jiān)控，其實我們還可以做得更多。
用戶信息收集
navigator
使用?window.navigator?可以收集到用戶的設(shè)備信息，操作系統(tǒng)，瀏覽器信息...
UV（Unique visitor）
是指通過互聯(lián)網(wǎng)訪問、瀏覽這個網(wǎng)頁的自然人。訪問您網(wǎng)站的一臺電腦客戶端為一個訪客。00:00-24:00內(nèi)相同的客戶端只被計算一次。一天內(nèi)同個訪客多次訪問僅計算一個UV。
在用戶訪問網(wǎng)站時，可以生成一個隨機字符串+時間日期，保存在本地。在網(wǎng)頁發(fā)生請求時（如果超過當天24小時，則重新生成），把這些參數(shù)傳到后端，后端利用這些信息生成 UV 統(tǒng)計報告。
PV（Page View）
即頁面瀏覽量或點擊量，用戶每1次對網(wǎng)站中的每個網(wǎng)頁訪問均被記錄1個PV。用戶對同一頁面的多次訪問，訪問量累計，用以衡量網(wǎng)站用戶訪問的網(wǎng)頁數(shù)量。
頁面停留時間
傳統(tǒng)網(wǎng)站
用戶在進入 A 頁面時，通過后臺請求把用戶進入頁面的時間捎上。過了 10 分鐘，用戶進入 B 頁面，這時后臺可以通過接口捎帶的參數(shù)可以判斷出用戶在 A 頁面停留了 10 分鐘。
SPA
可以利用 router 來獲取用戶停留時間，拿 Vue 舉例，通過?router.beforeEach?destroyed?這兩個鉤子函數(shù)來獲取用戶停留該路由組件的時間。
瀏覽深度
通過?document.documentElement.scrollTop?屬性以及屏幕高度，可以判斷用戶是否瀏覽完網(wǎng)站內(nèi)容。
頁面跳轉(zhuǎn)來源
通過?document.referrer?屬性，可以知道用戶是從哪個網(wǎng)站跳轉(zhuǎn)而來。
小結(jié)
通過分析用戶數(shù)據(jù)，我們可以了解到用戶的瀏覽習(xí)慣、愛好等等信息，想想真是恐怖，毫無隱私可言。
前端監(jiān)控部署教程
前面說的都是監(jiān)控原理，但要實現(xiàn)還是得自己動手寫代碼。為了避免麻煩，我們可以用現(xiàn)有的工具 sentry 去做這件事。
sentry 是一個用 python 寫的性能和錯誤監(jiān)控工具，你可以使用 sentry 提供的服務(wù)（免費功能少），也可以自己部署服務(wù)。現(xiàn)在來看一下如何使用 sentry 提供的服務(wù)實現(xiàn)監(jiān)控。
注冊賬號
打開?https://sentry.io/signup/?網(wǎng)站，進行注冊。
選擇項目，我選的 Vue。
安裝 sentry 依賴
選完項目，下面會有具體的 sentry 依賴安裝指南。
根據(jù)提示，在你的 Vue 項目執(zhí)行這段代碼?npm install --save @sentry/browser @sentry/integrations @sentry/tracing，安裝 sentry 所需的依賴。
再將下面的代碼拷到你的?main.js，放在?new Vue()?之前。
import * as Sentry from "@sentry/browser"; import { Vue as VueIntegration } from "@sentry/integrations"; import { Integrations } from "@sentry/tracing";Sentry.init({dsn: "xxxxx", // 這里是你的 dsn 地址，注冊完就有integrations: [new VueIntegration({Vue,tracing: true,}),new Integrations.BrowserTracing(),],// We recommend adjusting this value in production, or using tracesSampler// for finer controltracesSampleRate: 1.0, });然后點擊第一步中的?skip this onboarding，進入控制臺頁面。
如果忘了自己的 DSN，請點擊左邊的菜單欄選擇?Settings?->?Projects?-> 點擊自己的項目 ->?Client Keys(DSN)。
創(chuàng)建第一個錯誤
在你的 Vue 項目執(zhí)行一個打印語句?console.log(b)。
這時點開 sentry 主頁的 issues 一項，可以發(fā)現(xiàn)有一個報錯信息?b is not defined：
這個報錯信息包含了錯誤的具體信息，還有你的 IP、瀏覽器信息等等。
但奇怪的是，我們的瀏覽器控制臺并沒有輸出報錯信息。
這是因為被 sentry 屏蔽了，所以我們需要加上一個選項?logErrors: true。
然后再查看頁面，發(fā)現(xiàn)控制臺也有報錯信息了：
上傳 sourcemap
一般打包后的代碼都是經(jīng)過壓縮的，如果沒有 sourcemap，即使有報錯信息，你也很難根據(jù)提示找到對應(yīng)的源碼在哪。
下面來看一下如何上傳 sourcemap。
首先創(chuàng)建 auth token。
這個生成的 token 一會要用到。
安裝?sentry-cli?和?@sentry/webpack-plugin：
npm install sentry-cli-binary -g npm install --save-dev @sentry/webpack-plugin安裝完上面兩個插件后，在項目根目錄創(chuàng)建一個?.sentryclirc?文件（不要忘了在?.gitignore?把這個文件添加上，以免暴露 token），內(nèi)容如下：
[auth] token=xxx[defaults] url=https://sentry.io/ org=woai3c project=woai3c把 xxx 替換成剛才生成的 token。
org?是你的組織名稱。
project?是你的項目名稱，根據(jù)下面的提示可以找到。
在項目下新建?vue.config.js?文件，把下面的內(nèi)容填進去：
const SentryWebpackPlugin = require('@sentry/webpack-plugin')const config = {configureWebpack: {plugins: [new SentryWebpackPlugin({include: './dist', // 打包后的目錄ignore: ['node_modules', 'vue.config.js', 'babel.config.js'],}),],}, }// 只在生產(chǎn)環(huán)境下上傳 sourcemap module.exports = process.env.NODE_ENV == 'production'? config : {}填完以后，執(zhí)行?npm run build，就可以看到?sourcemap?的上傳結(jié)果了。
我們再來看一下沒上傳 sourcemap 和上傳之后的報錯信息對比。
未上傳 sourcemap
已上傳 sourcemap
可以看到，上傳 sourcemap 后的報錯信息更加準確。
切換中文環(huán)境和時區(qū)
選完刷新即可。
性能監(jiān)控
打開 performance 選項，就能看到你每個項目的運行情況。具體的參數(shù)解釋請看文檔?Performance Monitoring。
性能優(yōu)化
性能優(yōu)化主要分為兩類：
例如壓縮文件、使用 CDN 就屬于加載時優(yōu)化；減少 DOM 操作，使用事件委托屬于運行時優(yōu)化。
在解決問題之前，必須先找出問題，否則無從下手。所以在做性能優(yōu)化之前，最好先調(diào)查一下網(wǎng)站的加載性能和運行性能。
手動檢查
檢查加載性能
一個網(wǎng)站加載性能如何主要看白屏?xí)r間和首屏?xí)r間。
- 白屏?xí)r間：指從輸入網(wǎng)址，到頁面開始顯示內(nèi)容的時間。
- 首屏?xí)r間：指從輸入網(wǎng)址，到頁面完全渲染的時間。
將以下腳本放在?</head>?前面就能獲取白屏?xí)r間。
<script>new Date() - performance.timing.navigationStart </script>在?window.onload?事件里執(zhí)行?new Date() - performance.timing.navigationStart?即可獲取首屏?xí)r間。
檢查運行性能
配合 chrome 的開發(fā)者工具，我們可以查看網(wǎng)站在運行時的性能。
打開網(wǎng)站，按 F12 選擇 performance，點擊左上角的灰色圓點，變成紅色就代表開始記錄了。這時可以模仿用戶使用網(wǎng)站，在使用完畢后，點擊 stop，然后你就能看到網(wǎng)站運行期間的性能報告。如果有紅色的塊，代表有掉幀的情況；如果是綠色，則代表 FPS 很好。
另外，在 performance 標簽下，按 ESC 會彈出來一個小框。點擊小框左邊的三個點，把 rendering 勾出來。
這兩個選項，第一個是高亮重繪區(qū)域，另一個是顯示幀渲染信息。把這兩個選項勾上，然后瀏覽網(wǎng)頁，可以實時的看到你網(wǎng)頁渲染變化。
利用工具檢查
監(jiān)控工具
可以部署一個前端監(jiān)控系統(tǒng)來監(jiān)控網(wǎng)站性能，上一節(jié)中講到的 sentry 就屬于這一類。
chrome 工具 Lighthouse
如果你安裝了 Chrome 52+ 版本，請按 F12 打開開發(fā)者工具。
它不僅會對你網(wǎng)站的性能打分，還會對 SEO 打分。
使用 Lighthouse 審查網(wǎng)絡(luò)應(yīng)用
如何做性能優(yōu)化
網(wǎng)上關(guān)于性能優(yōu)化的文章和書籍多不勝數(shù)，但有很多優(yōu)化規(guī)則已經(jīng)過時了。所以我寫了一篇性能優(yōu)化文章前端性能優(yōu)化 24 條建議(2020)，分析總結(jié)出了 24 條性能優(yōu)化建議，強烈推薦。
重構(gòu)
《重構(gòu)2》一書中對重構(gòu)進行了定義：
所謂重構(gòu)（refactoring）是這樣一個過程：在不改變代碼外在行為的前提下，對代碼做出修改，以改進程序的內(nèi)部結(jié)構(gòu)。重構(gòu)是一種經(jīng)千錘百煉形成的有條不紊的程序整理方法，可以最大限度地減小整理過程中引入錯誤的概率。本質(zhì)上說，重構(gòu)就是在代碼寫好之后改進它的設(shè)計。重構(gòu)和性能優(yōu)化有相同點，也有不同點。
相同的地方是它們都在不改變程序功能的情況下修改代碼；不同的地方是重構(gòu)為了讓代碼變得更加易讀、理解，性能優(yōu)化則是為了讓程序運行得更快。
重構(gòu)可以一邊寫代碼一邊重構(gòu)，也可以在程序?qū)懲旰?#xff0c;拿出一段時間專門去做重構(gòu)。沒有說哪個方式更好，視個人情況而定。
如果你專門拿一段時間來做重構(gòu)，建議你在重構(gòu)一段代碼后，立即進行測試。這樣可以避免修改代碼太多，在出錯時找不到錯誤點。
重構(gòu)的原則
重構(gòu)手法
在《重構(gòu)2》這本書中，介紹了多達上百個重構(gòu)手法。但我覺得有兩個是比較常用的：
提取重復(fù)代碼，封裝成函數(shù)
假設(shè)有一個查詢數(shù)據(jù)的接口?/getUserData?age=17&city=beijing。現(xiàn)在需要做的是把用戶數(shù)據(jù)：{ age: 17, city: 'beijing' }?轉(zhuǎn)成 URL 參數(shù)的形式：
let result = '' const keys = Object.keys(data) // { age: 17, city: 'beijing' } keys.forEach(key => {result += '&' + key + '=' + data[key] })result.substr(1) // age=17&city=beijing如果只有這一個接口需要轉(zhuǎn)換，不封裝成函數(shù)是沒問題的。但如果有多個接口都有這種需求，那就得把它封裝成函數(shù)了：
function JSON2Params(data) {let result = ''const keys = Object.keys(data)keys.forEach(key => {result += '&' + key + '=' + data[key]})return result.substr(1) }拆分太長或功能太多的函數(shù)
假設(shè)現(xiàn)在有一個注冊功能，用偽代碼表示：
function register(data) {// 1. 驗證用戶數(shù)據(jù)是否合法/*** 驗證賬號* 驗證密碼* 驗證短信驗證碼* 驗證身份證* 驗證郵箱*/// 2. 如果用戶上傳了頭像，則將用戶頭像轉(zhuǎn)成 base64 碼保存/*** 新建 FileReader 對象* 將圖片轉(zhuǎn)換成 base64 碼*/// 3. 調(diào)用注冊接口// ... }這個函數(shù)包含了三個功能，驗證、轉(zhuǎn)換、注冊。其中驗證和轉(zhuǎn)換功能是可以提取出來單獨封裝成函數(shù)的：
function register(data) {// 1. 驗證用戶數(shù)據(jù)是否合法// verify()// 2. 如果用戶上傳了頭像，則將用戶頭像轉(zhuǎn)成 base64 碼保存// tobase64()// 3. 調(diào)用注冊接口// ... }如果你對重構(gòu)有興趣，強烈推薦你閱讀《重構(gòu)2》這本書。
參考資料：
- 《重構(gòu)2》
總結(jié)
寫這篇文章主要是為了對我這一年多工作經(jīng)驗作總結(jié)，因為我基本上都在研究前端工程化以及如何提升團隊的開發(fā)效率。希望這篇文章能幫助一些對前端工程化沒有經(jīng)驗的新手，通過這篇文章入門前端工程化。
如果這篇文章對你有幫助，請點一下贊，感激不盡。
總結(jié)
以上是生活随笔為你收集整理的不会比这更详细的前端工程化的入门教程了的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： idea 中 maven Process
- 下一篇： 路由器 telnet配置