立完flag，你可能需要對flag進行量化
DevUI是一支兼具設計視角和工程視角的團隊，服務於華為雲DevCloud平台和華為內部數個中後台系統，服務於設計師和前端工程師。
官方網站：devui.design
Ng組件庫：ng-devui（歡迎Star）
官方交流：添加DevUI小助手（devui-official）
DevUIHelper插件：DevUIHelper-LSP（歡迎Star）
引言
當你的能力足夠，並且獲得領導的信任之後，很自然地就會去承擔更大、更重要的責任，比如成為大中型業務的Owner。
大中型業務指的是該業務足夠大，足夠複雜，僅憑一己之力無法按要求交付版本，需要團隊協作。
我們假設該業務一共12個人，其中角色分佈如下（按產品研發流程排序）：
| 角色 | 職責 | 成員數 |
|---|---|---|
| 產品經理 | 對接用戶，是需求的來源 | 1 |
| 項目經理 | 管理項目進度，有節奏地進行版本交付 | 1 |
| 設計 | 負責UI交互和視覺，是用戶體驗的設計者 | 1 |
| 前端 | 前端用戶界面和交互效果開發 | 3 |
| 後台 | 後台數據存儲和接口開發 | 4 |
| 測試 | 負責版本質量 | 1 |
| 運維 | 負責現網部署 | 1 |
如果你被分到該業務，成為前端Owner，你可能需要做些什麼，以高效率、高質量地實現版本交付呢？
1 明確目標和職責
首先要了解組織和領導對你的期望，假設組織希望你能夠改善該業務的交付質量，贏得用戶口碑。
目標非常明確，就是提升交付質量，這個目標將牽引你未來一年的方向和行為，也是你超預期完成目標的前提。
有了目標之後，我們還需要去衡量它，這樣才知道有沒有提升，盡量尋找可以量化的指標。
這一塊可以參考我們以前的文章：《如何度量前端項目研發效率與質量》
2 交付質量的組成
質量代表的是好不好，問題越少就越好。
從產品側來看，缺陷率和JS錯誤率都是非常不錯的衡量指標。
從開發側來看也有很多很好的衡量指標，比如：
重複率圈複雜度ESLint問題數巨石文件/方法數
3 計算缺陷率
缺陷率=缺陷數/代碼規模
缺陷也就是BUG，當我們開發完產品特性後，需要部署到測試環境，並提測，測試人員測試完，會提一堆BUG單，這些BUG的數量就是缺陷數。
代碼規模可以用代碼行數來表示，一般源碼都放在工程根目錄下的src目錄中，可以使用cloc工具統計代碼行數：
cloc src
如果要排除裏面的某些目錄，比如__tests__，可以加上--exclude-dir參數
cloc src --exclude-dir=__tests__
比如html2canvas庫的代碼行數：
有了缺陷數和代碼規模，就可以計算缺陷率啦。
可以先統計下歷史迭代的缺陷率，缺陷數可以通過查看測試報告獲得，該版本增加的代碼行數可以通過Git提交記錄獲得。
比如上一個迭代1.2.6，從2020.12.14-2020.12.25。
我們可以使用以下命令統計到新增的代碼行數：
git log --after="2020-12-14 00:00:00" --before="2020-12-25 23:59:59" --pretty=tformat: --numstat | grep -v 'static' | awk '{ add += $1 ; subs += $2 ; loc += $1 - $2 } END { printf "增加行數:%s 刪除行數:%s 變化總行數:%s\n",add,subs,loc }'
還是以html2canvas舉栗子🌰
假設通過查看測試報告，這段時間一共出了3個BUG，那麼缺陷率就是：
缺陷率=缺陷數/代碼規模=3/130=2.3%
也就是上個迭代的缺陷率為2.3%，我們可以多計算幾個迭代，然後算個平均數，這樣我們就知道以前這個業務的缺陷率水平大致如何。
這樣你作為業務Owner，後續通過一系列舉措，最後降低了這個指標，假設降低到1.8%，那麼可以認為質量提升了：
(2.3-1.8)/2.3=21.7%
4 監控JS錯誤率
第二個是JS錯誤率，就是監控現網用戶訪問頁面時，是否有JS報錯，如果有JS報錯，很可能某些功能就可用。
我們沒法在用戶的現場，我們不知道用戶使用我們產品的體驗如何，他是否在使用過程中遇到了困難，這些我們沒法直接知道。
但是JS報錯給我們提供了一些了解這些信息的線索，假設某個時刻，現網出現了JS報錯，我們或許就能復現這個報錯，找到報錯的原因，並在用戶投訴之前及時修復這個缺陷。
可以說:
降低現網JS錯誤率就是在排除地雷，地雷越少，炸到的用戶就越少，這對產品的用戶口碑意義重大
這個指標需要通過前端監控平台採集，比如我們DevUI內部的Furion平台，它的計算公式如下：
JS錯誤率=JS錯誤數/PV
也是先看下以往的現網JS錯誤率水平，假設是6.2%，你通過努力將這個指標降到0.1%，那麼質量提升就是98%。
5 統計重複率
除了產品層面的質量衡量指標，我們還可以設定一些開發側的質量指標。
重複率就是一個很不錯的指標，如果項目裏面重複的代碼太多
- 一來我們的維護成本提高，一處變更，要改很多地方；
- 二來容易漏該某些地方，從來導致BUG。
重複代碼是萬惡之源
我們可以用jscpd工具來統計前端代碼的重複率：
jscpd src
以html2canvas為🌰
它一共有14處重複代碼，重複率為1.71%（算比較低的），jscpd命令還會列出每一處重複所在的文件以及所在的行/列。
我們要做的就是照着重複率報告，一處一處改掉即可，當然修改重複代碼也要考慮可讀性，不能為了消除重複，降低了代碼的可讀性。
假設改完之後，重複率降到1.16%，那麼質量提升了32%。
6 計算圈複雜度
圈複雜度可以參考下我們之前的文章：淺談前端中的圈複雜度 ，這裡就不贅述。
7 ESLint問題數清零
ESLint通過一些最佳實踐的規範，來約束我們的代碼，從而保障代碼質量。
下圖清晰地展示了ESLint的價值：
- 如果你不使用ESLint，你的代碼只能靠人工來檢查，格式亂七八糟，運行起來bug叢生，你的合作者或用戶會怒氣沖沖；
- 如果你使用了ESLint，你的代碼有可靠的機器進行檢查，格式規則，運行起來問題會少很多，大家都會很滿意。
如果項目中的代碼沒有遵循ESLint規則，那麼就會產生一條ESLint錯誤或者提示，將這些ESLint問題修復，在一定程度上是可以提升代碼質量的。
假設ESLint問題清零了，那麼質量提升就是100%。
8 統計巨石文件/方法數
大而複雜的事物，我們理解起來一般更費勁，簡潔的事物往往易於理解。
代碼也是一樣，簡單的代碼，我們一眼就知道它是做什麼的，這樣修改它就不容易出錯。
如果一個文件包含幾千行代碼，或者一個方法包含幾百行代碼，裏面分支眾多，嵌套又深，那麼我們就很難讀懂它，修改它的時候總不免戰戰兢兢、如履薄冰，還容易出bug。
統計所有文件的代碼行數，並按代碼行數從大到小排序，可以使用之前提到的cloc工具：
cloc src --by-file
還是以html2canvas為🌰（只截取了代碼行數大於100行的文件）
一般一個文件的代碼行數不要超過300行，超過300可能就需要進行適當的模塊拆分，以增強代碼的可讀性和可維護性。
另外也要權衡下文件的嵌套深度，從根路徑開始往下，一般不超過7層。
我目前沒想到比較好的統計巨石方法的辦法，只能去巨石文件裏面找，找到超過50行的方法，我就會考慮重構。
大家有更好的辦法歡迎推薦。
小結
我們做一個簡單的小結，從產品側來看，可以通過
- 缺陷率
- JS錯誤率
來衡量質量。
從開發側來看，可以通過
- 重複率
- 圈複雜度
- ESLint問題數
- 巨石文件/方法
來衡量質量。
這些質量指標可以根據自己團隊的特點和偏好，設定相應的權重，並最終計算出一個總的質量提升比率。
對目標進行量化之後，我們就可以擼起袖子開幹了。
經過一段時間的努力，我們超預期完成了組織的目標，就可以拿着這些質量提升的量化指標去跟組織要年終獎和加薪啦！
加入我們
我們是DevUI團隊，歡迎來這裡和我們一起打造優雅高效的人機設計/研發體系。招聘郵箱：[email protected]。
文/DevUI Kagol
往期文章推薦
《在瀑布下用火焰烤餅：三步法助你快速定位網站性能問題（超詳細）》
《html2canvas實現瀏覽器截圖的原理（包含源碼分析的通用方法） 》
《大廠是如何用DevCloud流水線實現自動化部署Web應用的？》
