本篇文章參考大量參考百度工程能力白皮書：https://drive.google.com/file/d/1mbb8pA9wE4fd3ftW5tUJJWazCe7yXwp_/view?usp=sharing 這是今年五月初去 Qcon 聽到的其中一場議程 講者是王一男，百度研發工具平台資深產品經理 整場大意為： 一個技術公司，研發工程能力的高低直接影響公司的持久創新力和公司在市場上的作為。只有不懈追求卓越的工程能力，才能夠帶來長期的核心競爭力，才能為每個用戶、每個企業客戶以及整個社會創造價值 議程分為四章節 1. 人（能力、文化） 2. 技 （研發工具、工程複用） 3. 法 （工程方法、優秀實踐） 4. 數據 （研發數據、工程數據） 以下我就依靠僅存的記憶跟大家大概分享他講了啥😅 1. 人（能力、文化） 人的部分我想借用上次分享的

之前跟 Ig, Amazon 的工程師吃飯，他們也說自己第一個月都不工作 公司會排課程讓他們學習公司的工程文化 要求的內容大致都跟 slide 上的那三點相同，Readability, Debuggability 等等 我們公司現在有慢慢在用 linter 來規範大家的代碼風格 但是 code review 真的很難落實 然後代碼可讀性這點我目前我沒很清楚怎樣叫易讀，等哪天看完「Clean Code」再來跟大家分享好了XD 2. 技 （研發工具、工程複用） 這個章節 pr 成分比較多 因為每間公司的應用場景略有不同 所以 jenkins, Travis-CI 會有點不符需求 導致他們要自幹一個平台，可以設計自己想要的 pipeline 完全取代 github, Travis-CI 這些，不過這些應該都離大家很遙遠就是了ＸＤ 3. 法 （工程方法、優秀實踐）、數據 （研發數據、工程數據） 法幾乎就是寫在這份白皮書中了 數據 （研發數據、工程數據）就是每季拿來檢驗你做得如何，類似 OKR, KPI 這樣所以我就一起講

先列出一些我覺得比較容易做到的 a. code review 的部分 30 天內的千行評論數不能小於 4，千行評論數上面沒寫定義，我不敢亂猜然後只查到類似的定義「千行代码Bug率 = Bug数量/ (代码行数/1000)」 我猜千行評論數就是「code review 數量 / (代碼行數 / 1000)」 reference: https://www.cnblogs.com/peida/p/8315677.html b. P0 級別的自動化回歸測試覆蓋率要達 30% (P0 級別就是最嚴重的 bug，例如閃退、數據丟失、用光你記憶體這種) 詳情請看：https://www.jianshu.com/p/1482c2a650e1 c. Unit Test 的覆蓋率達 45% d. Commit 的規範，95% 的 commit 不超過 400 行 e. 迭代週期小於兩週，平均完成率不低於 80%（沒寫如果不是用 agile 系列的話怎麼衡量XD） f. 在你家的 Bug 回報系統中，停留半年以內的 Bug 完成率達 80% g. 禁止重複文件的提交（沒有說是不是一定要寫文件，難不成在百度裡面寫文件是每個工程師的標配嗎😅） 小結論：

百度實踐完的心得是 1. 有認真做的團隊，他們的開發週期平均從 120 hr 降到 80 hr，這個東西一定要畫到 dashboard 上，這樣團隊才會有動力去執行 2. 團隊人數越多，實施工程實踐所縮短的開發週期效果越大 3. 採用越多，實施工程實踐所縮短的開發週期效果越大 4. 採用越深，實施工程實踐所縮短的開發週期效果越大 今天的故事就到這邊拉 剛好下週一有新的同事 on board 來試著推行看看效果如何，之後再跟大家分享 ========== 我是分隔線 下面自我 Q&A ========== Q1: 為什麼都要七月了你還在分享你五月出差的心得 A1: 因為我很混ㄎㄎㄎ Q2: 終於發文了，人家等豪久ＲＲＲ（醒醒吧，沒人想看你發文） A2: 喔喔喔，因為我們去越南員工旅遊啊，然後我帶著公司的測試機 iPhone X 去越南寫 code，回台灣就找不到了嗚 Q3: 有越南照片嗎？ A3: 我都用測試機拍，因為鏡頭比較好，結果弄丟了所以這邊只有幾張用自己手機拍的糞照，這是當地的傳統市場，前天溫度四十幾😓

順帶一提越南按摩很便宜（純按摩） 這是我主管ㄎㄎㄎ

—————————— 如果你喜歡這篇文章，請按一下喜歡以及右上角訂閱按鈕。 看更多文章：https://www.dcard.tw/@ggggghgggg