devui是一支兼具設計視角和工程視角的團隊，服務於華為雲devcloud平台和華為內部數個中後台系統，服務於設計師和前端工程師。當你的能力足夠，並且獲得領導的信任之後，很自然地就會去承擔更大、更重要的責任，比如成為大中型業務的owner。官方**：devui.design
ng元件庫：ng-devui（歡迎star）
官方交流：新增devui小助手（devui-official）
devuihelper外掛程式：devuihelper-lsp（歡迎star）
大中型業務指的是該業務足夠大，足夠複雜，僅憑一己之力無法按要求交付版本，需要團隊協作。
我們假設該業務一共12個人，其中角色分布如下（按產品研發流程排序）：
角色職責
成員數產品經理
對接使用者，是需求的**
1專案經理
管理專案進度，有節奏地進行版本交付1設計
負責ui互動和視覺，是使用者體驗的設計者1前端
前端使用者介面和互動效果開發3後台
後台資料儲存和介面開發4測試
負責版本質量1運維
負責現網部署
1如果你被分到該業務，成為前端owner，你可能需要做些什麼，以高效率、高質量地實現版本交付呢？
首先要了解組織和領導對你的期望，假設組織希望你能夠改善該業務的交付質量，贏得使用者口碑。
目標非常明確，就是提公升交付質量，這個目標將牽引你未來一年的方向和行為，也是你超預期完成目標的前提。
有了目標之後，我們還需要去衡量它，這樣才知道有沒有提公升，盡量尋找可以量化的指標。
質量代表的是好不好，問題越少就越好。
從產品側來看，缺陷率和js錯誤率都是非常不錯的衡量指標。
從開發側來看也有很多很好的衡量指標，比如：
缺陷率=缺陷數/**規模缺陷也就是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 ' end '假設通過檢視測試報告，這段時間一共出了3個bug，那麼缺陷率就是：
缺陷率=缺陷數/**規模=3/130=2.3%也就是上個迭代的缺陷率為
2.3%，我們可以多計算幾個迭代，然後算個平均數，這樣我們就知道以前這個業務的缺陷率水平大致如何。
這樣你作為業務owner，後續通過一系枚舉措，最後降低了這個指標，假設降低到1.8%，那麼可以認為質量提公升了：
(2.3-1.8)/2.3=21.7%第二個是js錯誤率，就是監控現網使用者訪問頁面時，是否有js報錯，如果有js報錯，很可能某些功能就可用。
我們沒法在使用者的現場，我們不知道使用者使用我們產品的體驗如何，他是否在使用過程中遇到了困難，這些我們沒法直接知道。
但是js報錯給我們提供了一些了解這些資訊的線索，假設某個時刻，現網出現了js報錯，我們或許就能復現這個報錯，找到報錯的原因，並在使用者投訴之前及時修復這個缺陷。
可以說:
降低現網js錯誤率就是在排除地雷，地雷越少，炸到的使用者就越少，這對產品的使用者口碑意義重大這個指標需要通過前端監控平台採集，比如我們devui內部的furion平台，它的計算公式如下：
js錯誤率=js錯誤數/pv也是先看下以往的現網js錯誤率水平，假設是
6.2%，你通過努力將這個指標降到0.1%，那麼質量提公升就是98%。
除了產品層面的質量衡量指標，我們還可以設定一些開發側的質量指標。
重複率就是乙個很不錯的指標，如果專案裡面重複的**太多
重複**是萬惡之源我們可以用jscpd工具來統計前端**的重複率：
jscpd src它一共有14處重複**，重複率為1.71%（算比較低的），jscpd命令還會列出每一處重複所在的檔案以及所在的行/列。
我們要做的就是照著重複率報告，一處一處改掉即可，當然修改重複**也要考慮可讀性，不能為了消除重複，降低了**的可讀性。
假設改完之後，重複率降到1.16%，那麼質量提公升了32%。
eslint通過一些最佳實踐的規範，來約束我們的**，從而保障**質量。
下圖清晰地展示了eslint的價值：
如果專案中的**沒有遵循eslint規則，那麼就會產生一條eslint錯誤或者提示，將這些eslint問題修復，在一定程度上是可以提公升**質量的。
假設eslint問題清零了，那麼質量提公升就是100%。
大而複雜的事物，我們理解起來一般更費勁，簡潔的事物往往易於理解。
**也是一樣，簡單的**，我們一眼就知道它是做什麼的，這樣修改它就不容易出錯。
如果乙個檔案包含幾千行**，或者乙個方法包含幾百行**，裡面分支眾多，巢狀又深，那麼我們就很難讀懂它，修改它的時候總不免戰戰兢兢、如履薄冰，還容易出bug。
統計所有檔案的**行數，並按**行數從大到小排序，可以使用之前提到的cloc工具：
cloc src --by-file一般乙個檔案的**行數不要超過300行，超過300可能就需要進行適當的模組拆分，以增強**的可讀性和可維護性。
另外也要權衡下檔案的巢狀深度，從根路徑開始往下，一般不超過7層。
我目前沒想到比較好的統計巨石方法的辦法，只能去巨石檔案裡面找，找到超過50行的方法，我就會考慮重構。
我們做乙個簡單的小結，從產品側來看，可以通過
從開發側來看，可以通過
這些質量指標可以根據自己團隊的特點和偏好，設定相應的權重，並最終計算出乙個總的質量提公升比率。
對目標進行量化之後，我們就可以擼起袖子開幹了。
經過一段時間的努力，我們超預期完成了組織的目標，就可以拿著這些質量提公升的量化指標去跟組織要年終獎和加薪啦！文/devui kagol
往期文章推薦
《html2canvas實現瀏覽器截圖的原理（包含原始碼分析的通用方法）》
《在瀑布下用火焰烤餅：三步法助你快速定位**效能問題（超詳細）》
《大廠是如何用devcloud流水線實現自動化部署web應用的？》
變數和資料型別 你可能需要加強的基礎
對於c語言，相信絕大多數人大學就有學過吧，畢業後，我也是 雷打不動地處於大學時通過二級c語言的水平上，並且再也沒有精進過，為了個人的知識拓展或者提高，也就有了這個專欄。相信這是個長期而艱難的旅途 變數的宣告，就是在記憶體開闢乙個區域儲存你要儲存的變數，最早對於變數初始化，就是賦初值，然後就沒什麼理解...
微信小程式乙個你可能需要的功能
效果圖 那這個有什麼用呢。需求是選中的某個區域然後給它新增注釋。還可以有其他用處。那這個是怎麼做到的呢 首先我說下基本的思路 作為乙個背景。然後上面是一層canvas 以及最上面生成的view 因為只是乙個demo 所以寫法上就沒有樣式分離了。下面是布局的 class container src s...
測試高階 你可能需要知道的這些常用服務埠
首先 先介紹下自己，看文章得知道作者是幹嘛的 ido老徐，網際網路從業者，軟體測試老鳥，08年開始從事軟體測試職業 前後經歷3家公司，從測試小菜到公司測試負責人，帶領測試團隊對公司整個產品體系負責 專注測試職業探索 測試管理 專案管理 測試經驗談 分享自己的測試觀點 測試經驗 希望能讓你的職業道路少...