代碼靜態(tài)分析系統(tǒng)設計及實踐

1、技術(shù)創(chuàng)新，變革未來代碼靜態(tài)分析系統(tǒng)設計及實踐目錄代碼質(zhì)量管理是個大問題靜態(tài)分析+代碼評審的實踐學習和強調(diào)，紅線和懲罰，100%的測試覆蓋率，和事后復盤并不夠有經(jīng)驗的程序員也會犯錯對代碼提要求很難監(jiān)督落實測試更多是驗證功能，很難檢測編碼缺陷代碼的快速變化使質(zhì)量更難管生產(chǎn)質(zhì)量是責任靠運維和事后復盤善后夠嗎？靜態(tài)分析工具：半智能的代碼分析機器人靜態(tài)分析輔助代碼評審自動化工具+流程才是未來Bug!Thx!Bug!投入大KPI不痛不癢使用主體和責任主體不一致一步登天想要終極AI代碼質(zhì)量改進工具、流程落地難Bug!No Thx!DevOps: 代碼質(zhì)量責任應該左移設計代碼開發(fā)代碼評審入庫測試發(fā)布非研發(fā)人員

2、主導，溝通成本高，推動修復周期長很難形成標準推動研發(fā)實施形成技術(shù)債，償債成本高代碼簽入前，研發(fā)人員有義務修復問題測試人員早期加入，更懂項目研發(fā)的情況，溝通成本低，加快上線能逐步形成好的編碼規(guī)范和最佳實踐檢查代碼風格問題挺準，但是 我warning都不看，還看這個？大多數(shù)開發(fā)人員眼中的靜態(tài)分析工具檢查邏輯問題好，但耗時長 還挺多誤報，想用而不敢用編譯器里的Errors and warnings自帶靜態(tài)分析的語言如Typescript, RustIDE里的智能提示代碼混淆和美化代碼交叉索引Eclipse等IDE中的一鍵重構(gòu)App市場的審核成功靜態(tài)分析應用代碼評審中的靜態(tài)分析針對該提交 代碼片段自

3、動觸發(fā)分析發(fā)現(xiàn)問題，拒絕代碼合并發(fā)起代碼提交，如Pull Request沒有問題，允許合入開發(fā)者代碼倉庫靜態(tài)代碼評審的樣子為何代碼評審階段？2K Bugs12K Warnings 225K Code Smell“找到幾萬個問題，沒法修”“這是以前的業(yè)務邏輯，不用修”“這別人寫的代碼，不關我事”大量報告引起不適剛寫的代碼立即自動掃描，程序員強迫使用 只體現(xiàn)新增代碼問題，責任邊界清晰評審流程多人督促漸進式開啟更多檢查器增量分析減少不適軟件工程師一天被邀請進行多次 代碼評審，這些都不是他們自身 的KPI一旦工期緊996，人工評審容易 變成走形式任務掛著還容易造成工程師焦慮降低工程師勞動強度大規(guī)模C/

4、C+靜態(tài)代碼評審系統(tǒng)搭建數(shù)千個活躍開發(fā)的代碼倉庫每天上千次代碼評審請求平均每次代碼評審小于50分鐘需要編譯C/C+代碼使用了定理證明器求解可行路徑（精確，耗時）能跨函數(shù)分析能處理指針使用有深度的代碼分析器做到快速和準確用盡量少機器完成一天幾千次分析每次分析10分鐘要能結(jié)束控制誤報并建立反饋和改進機制挑戰(zhàn)：超大規(guī)模代碼倉庫項目平均40分鐘單機編譯時間 項目平均編譯代碼量超百萬行編譯的價值C/C+代碼邏輯受編 譯參數(shù)深度控制源代碼索引和統(tǒng)計提升開源靜態(tài)分析工 具分析質(zhì)量提高分析質(zhì)量測試項目 glog （谷歌的日志項目）, 17個源文件。cppcheck不帶編譯分析：111個分析報告cppcheck

5、帶編譯分析：280個分析報告111 280不編譯編譯300250200150報告數(shù) 100500編譯流程融合靜態(tài)分析分布式編譯與分析大量使用緩存提升靜態(tài)分析的理論速度如何做到10分鐘反饋分析結(jié)果系統(tǒng)地改進分析時間編譯流程分析流程依賴關系分析分布式 編譯分布式 分析分布式鏈接跨模塊分析 報告整合緩存緩存緩存緩存硬核玩家：從理論上改進靜態(tài)分析能力PLDI2018: 去掉路徑 遍歷分析中的冗余ICSE2019：路徑遍歷內(nèi) 存泄漏分析的多項式算法需求2：誤報率要低方法1： 數(shù)據(jù)驅(qū)動的改進循環(huán)降低誤報率標注反饋優(yōu)化代碼掃描新增分析器淘汰分析器感知誤報率數(shù)據(jù)驅(qū)動的開發(fā)管理方法2： 高低搭配高危，誤報率偏高

6、的高價值檢查器 搭配其他誤報率低的檢查器避免重要問題被忽略的同時降低 “感知誤報率”降低感知誤報率方法3：易于理解的報告關鍵步驟高亮和行為解釋配套完善的文檔代碼交叉索引降低感知誤報率回憶下代碼評審 時最不能忍的事 是啥？對，就是 不能像在IDE里 面一樣查看符號 定義使用。代碼交叉索引方法4：Bug生命周期跟蹤精確查找類似Bug，利用標記數(shù)據(jù)排除潛在誤報通過修復率等參數(shù)對分析 器進行綜合評價降低感知誤報率降低感知誤報率方法5：防止誤標和作弊標記量，間隔時間，標記內(nèi)容用基線數(shù)據(jù)訓練模型用聚類和離群檢測找到違反者紅黑榜鼓勵參與者用數(shù)據(jù)風控的方式管理總結(jié)：代碼評審中的靜態(tài)分析無需額外操作，不改變程序員習慣的流