你工作很高效，如何證明？你做了很多優化，是否有效？
為了回答這些問題，最有力的就是用資料來支援，所以需要將自己的工作量化。
量化的工作總共分為兩層：業務需求和程式碼質量。
需求統計包括完成率和使用者滿意度評分。
1）完成率
公司每雙月會開一次需求討論會，羅列本雙月的需求。
我會以這份列表為基礎，自己再開一份線上列表，記錄所有需求的狀態，並且會將不在此列表中的零碎需求也記錄。
這份列表有 5 列，包括需求名稱、線上BUG數、功能點數量、狀態和備註。
其中狀態又包括設計、提測、上線、延期等，可以一眼就能反映出需求所處的階段。
線上BUG數就是字面意思，而功能點數量是 QA 提供的，他們在寫測試用例時就會有這個資料。
我的需求完成率是按提測狀態來統計，而不是上線狀態。
因為有時候是需要多端聯調的，經常會碰到共同作業方因為種種原因無法配合聯調或延期。
提測是指 QA 可以驗收需求，所以要說明此處的聯調問題並不是指我們寫好介面，然後等伺服器端給介面。
而是比如我們完成管理後臺的前後端功能，提供資料來源，伺服器端沒有時間處理這批資料，類似於這種場景。
2）使用者滿意度評分
這是一張問卷調查，收集大家對我們組工作的反饋，對當前存在的問題可以做出針對性的優化。
需要填寫所處部門，需求型別（後臺或活動），是否達到預期，維度包括成果、溝通、響應等。
最後還有兩個可選項，就是填寫意見或建議，以及最想表揚的同學及其理由。
若是正面反饋，那自然很好；若是負面反饋，那就要總結.
核心指標主要與程式碼質量有關，包括異常狀態碼介面、慢響應、前端錯誤、白屏和首屏時間等，以折線圖的形式描述趨勢變化。
因為我們組維護著大量的 Node 服務，所以指標中就會包含多個伺服器端資料。其中慢響應作為我們組的北極星指標。
所謂北極星指標，也叫第一關鍵指標，是指在產品的當前階段與業務/戰略相關的核心指標，一旦確立就像北極星一樣指引團隊向同一個方向前進。
1）狀態碼介面
狀態碼是指報 500、502、503 和 504 的介面，其中 500 是程式碼錯誤，我們可以通過紀錄檔做排查。
在 500 的錯誤碼中，監控介面佔據了 94% 左右，主要是因為上傳的資料量太大導致報錯，伺服器端限制 1M，最終在上傳時就做大小限制。
還有一個佔據了 6.2% 的錯誤介面主要是邏輯不夠嚴密，邊界條件沒有處理好，修復後就降到了 0。
502 是轉發到錯誤的後端服務，503 是沒有轉發，都是 Nginx 的問題，如果大量報，那就要找運維了。
504 是由後端服務出問題導致的超時引起的，例如資料庫因為一條耗時的查詢語句而被掛起。
2）慢響應
慢響應是那些響應時間超過 2 秒的介面，一種是內部邏輯慢，另一種是受呼叫的介面影響而變慢。
第一種就可以我們自己解決，第二種就需要找共同作業組配合解決了。
有一個佔了慢響應 67.4% 的監控列表介面，屬於前者，在內部會查詢一張 430W 的大表 6 次。
優化手段也很直接，就是減少查詢次數，降到 1 次，慢響應次數一下子減少了 95%。
還有個舉報介面，也屬於前者，這張表也比較大，增加查詢條件，觸發索引，就立竿見影的把速度提上來了。
該慢響應次數一下子減少了 90%。這兩個介面優化後，慢響應總佔比從 0.23% 降低到 0.1%。
3）前端錯誤
前端錯誤就是通過監控系統蒐集到的錯誤紀錄檔，分為指令碼錯誤和通訊異常。
指令碼錯誤就是 JavaScript 的異常，例如用 undefined 當物件讀取屬性。
一個專案中的指令碼錯誤在修復後，從高峰的4073降低至246，減少了93.96%，進一步的保障專案質量。
通訊異常其實也是 500、502 和 504 介面，之前的介面異常數量會包括靜態資源以及內部的服務呼叫。
而此處的通訊異常只包含從使用者端發起的那部分介面，可以簡單理解為其子集，不過有時候發現 502 和 504 的統計兩邊會有略微差異。
4）白屏和首屏時間
白屏就是等待白屏的時間（FP），首屏更確切的說是首次有意義的內容載入時間（FMP）。
之前做過一套性能監控系統，白屏比較好計算，而首屏比較複雜，我們這邊採用最簡單的埋點的方式。
也就是手動的在某個階段記錄首屏時間，比較麻煩的是需要將線上頁面逐個新增，不過也沒多少個，所以還能接受這個笨辦法。
以首屏為例，1 秒內佔 72%左右，2 秒內佔 19% 左右，若以 1.2 秒為邊界的話，那優化的空間還是蠻大的。
初步排查後，發現主要慢在 DOM 解析，這讓我蠻詫異的，經過 Chrome DevTools 的效能分析後，定位到了指令碼尺寸上。
載入的指令碼有點多，並且有一個 chunk-vendors.js 指令碼還比較大，下載時間有點長。
因此在載入和執行時就會延長 DOM 的解析，影響白屏時間。