立完flag,你可能需要對flag進行量化
阿新 • • 發佈:2021-01-17
> DevUI是一支兼具設計視角和工程視角的團隊,服務於華為雲[DevCloud](https://www.huaweicloud.com/devcloud/)平臺和華為內部數箇中後臺系統,服務於設計師和前端工程師。
> 官方網站:[devui.design](https://devui.design/)
> Ng元件庫:[ng-devui](https://github.com/DevCloudFE/ng-devui)(歡迎Star)
> 官方交流:新增DevUI小助手(devui-official)
> DevUIHelper外掛:DevUIHelper-LSP(歡迎Star) # 引言 當你的能力足夠,並且獲得領導的信任之後,很自然地就會去承擔更大、更重要的責任,比如成為大中型業務的Owner。 大中型業務指的是該業務足夠大,足夠複雜,僅憑一己之力無法按要求交付版本,需要團隊協作。 我們假設該業務一共12個人,其中角色分佈如下(按產品研發流程排序): |角色|職責|成員數| |---|---|---| |產品經理|對接使用者,是需求的來源|1| |專案經理|管理專案進度,有節奏地進行版本交付|1| |設計|負責UI互動和視覺,是使用者體驗的設計者|1| |前端|前端使用者介面和互動效果開發|3| |後臺|後臺資料儲存和介面開發|4| |測試|負責版本質量|1| |運維|負責現網部署|1| 如果你被分到該業務,成為前端Owner,你可能需要做些什麼,以高效率、高質量地實現版本交付呢? # 1 明確目標和職責 首先要了解組織和領導對你的期望,假設組織希望你能夠改善該業務的交付質量,贏得使用者口碑。 目標非常明確,就是提升`交付質量`,這個目標將牽引你未來一年的方向和行為,也是你超預期完成目標的前提。 有了目標之後,我們還需要去衡量它,這樣才知道有沒有提升,儘量尋找可以量化的指標。 這一塊可以參考我們以前的文章:[《如何度量前端專案研發效率與質量》](https://juejin.cn/post/6844904095908626445) # 2 交付質量的組成 質量代表的是好不好,問題越少就越好。 從產品側來看,`缺陷率`和`JS錯誤率`都是非常不錯的衡量指標。 從開發側來看也有很多很好的衡量指標,比如: - `重複率` - `圈複雜度` - `ESLint問題數` - `巨石檔案/方法數` # 3 計算缺陷率 > 缺陷率=缺陷數/程式碼規模 缺陷也就是BUG,當我們開發完產品特性後,需要部署到測試環境,並提測,測試人員測試完,會提一堆BUG單,這些BUG的數量就是缺陷數。 程式碼規模可以用程式碼行數來表示,一般原始碼都放在工程根目錄下的src目錄中,可以使用[cloc](https://github.com/AlDanial/cloc)工具統計程式碼行數: ``` cloc src ``` 如果要排除裡面的某些目錄,比如`__tests__`,可以加上`--exclude-dir`引數 ``` cloc src --exclude-dir=__tests__ ``` 比如`html2canvas`庫的程式碼行數: ![](https://p6-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/97c93aa2e9724d58830b171b795f2525~tplv-k3u1fbpfcp-watermark.image) 有了缺陷數和程式碼規模,就可以計算缺陷率啦。 可以先統計下歷史迭代的缺陷率,缺陷數可以通過檢視`測試報告`獲得,該版本增加的程式碼行數可以通過`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舉栗子
> 官方網站:[devui.design](https://devui.design/)
> Ng元件庫:[ng-devui](https://github.com/DevCloudFE/ng-devui)(歡迎Star)
> 官方交流:新增DevUI小助手(devui-official)
> DevUIHelper外掛:DevUIHelper-LSP(歡迎Star) # 引言 當你的能力足夠,並且獲得領導的信任之後,很自然地就會去承擔更大、更重要的責任,比如成為大中型業務的Owner。 大中型業務指的是該業務足夠大,足夠複雜,僅憑一己之力無法按要求交付版本,需要團隊協作。 我們假設該業務一共12個人,其中角色分佈如下(按產品研發流程排序): |角色|職責|成員數| |---|---|---| |產品經理|對接使用者,是需求的來源|1| |專案經理|管理專案進度,有節奏地進行版本交付|1| |設計|負責UI互動和視覺,是使用者體驗的設計者|1| |前端|前端使用者介面和互動效果開發|3| |後臺|後臺資料儲存和介面開發|4| |測試|負責版本質量|1| |運維|負責現網部署|1| 如果你被分到該業務,成為前端Owner,你可能需要做些什麼,以高效率、高質量地實現版本交付呢? # 1 明確目標和職責 首先要了解組織和領導對你的期望,假設組織希望你能夠改善該業務的交付質量,贏得使用者口碑。 目標非常明確,就是提升`交付質量`,這個目標將牽引你未來一年的方向和行為,也是你超預期完成目標的前提。 有了目標之後,我們還需要去衡量它,這樣才知道有沒有提升,儘量尋找可以量化的指標。 這一塊可以參考我們以前的文章:[《如何度量前端專案研發效率與質量》](https://juejin.cn/post/6844904095908626445) # 2 交付質量的組成 質量代表的是好不好,問題越少就越好。 從產品側來看,`缺陷率`和`JS錯誤率`都是非常不錯的衡量指標。 從開發側來看也有很多很好的衡量指標,比如: - `重複率` - `圈複雜度` - `ESLint問題數` - `巨石檔案/方法數` # 3 計算缺陷率 > 缺陷率=缺陷數/程式碼規模 缺陷也就是BUG,當我們開發完產品特性後,需要部署到測試環境,並提測,測試人員測試完,會提一堆BUG單,這些BUG的數量就是缺陷數。 程式碼規模可以用程式碼行數來表示,一般原始碼都放在工程根目錄下的src目錄中,可以使用[cloc](https://github.com/AlDanial/cloc)工具統計程式碼行數: ``` cloc src ``` 如果要排除裡面的某些目錄,比如`__tests__`,可以加上`--exclude-dir`引數 ``` cloc src --exclude-dir=__tests__ ``` 比如`html2canvas`庫的程式碼行數: ![](https://p6-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/97c93aa2e9724d58830b171b795f2525~tplv-k3u1fbpfcp-watermark.image) 有了缺陷數和程式碼規模,就可以計算缺陷率啦。 可以先統計下歷史迭代的缺陷率,缺陷數可以通過檢視`測試報告`獲得,該版本增加的程式碼行數可以通過`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舉栗子