淺談軟體工程中的程式碼評審
程式碼評審這個詞相信很多做開發的同學一定不會陌生,線上故障回顧總結有程式碼評審和單元測試總能夠被高頻率的提及並作為主要的整改意見,可見程式碼評審對於軟體工程質量保證的重要性。相對於單元測試,程式碼評審的普及率是相對較少,相信主要原因是程式碼評審的執行難度高,靈活性大,評審的方法和規則難於標準化等原因,要做好程式碼評審往往也困難許多,這裡除了涉及到具體的技術知識和業務知識,還需要評審雙方的溝通能力,表達能力,個人態度以及團隊氛圍等多種個人軟體技能或者團隊開放度。
什麼是程式碼評審
根據維基百科的定義,程式碼評審是軟體質量保證一種活動,由一個或者多個人對一個程式的部分或者全部原始碼進閱讀理解。一般來說分為作者和評審者兩種角色,作者方提供程式碼邏輯的介紹和程式碼,評審者則對提供的程式碼基於設計,功能性和非功能性等方面認知進行閱讀並提出問題。常見的評審組織形式是有同行評審(Peer Review)和小組檢查 (Team Inspection)兩種方式。
程式碼評審目的
維基百科中提到通過程式碼的評審發現潛在的問題是程式碼評審主要的目的。這是不可否認的當時提出程式碼審查的初衷,但從我個人的實踐中發現,分享和表達是程式碼評審過程最主要的收穫。通過程式碼評審可能無法發現更多的明顯的問題,但是一定可以通過評審過程學習和交流發現程式碼中存在的優點和缺點,讓新同學瞭解業務,讓老同學知道可能有更優的設計和用法。同時讓同事們在評審中交流表達自己的觀點,讓同學們有更多的開口機會。
根據Google 工程團隊執行程式碼評審活動後發現,除了捕捉bug外,還對5大無形收益。
- 程式碼評審促進團隊和個人開放度
- 程式碼評審提升團隊交付標準
- 程式碼評審激勵團隊協作
- 程式碼評審保持安全至上
- 程式碼評審構建社會認可
什麼時候做程式碼評審
程式碼評審最重要的一點是非常靈活,無固定形式,隨時隨地都可以發起。根據Github和Apache一些開源專案的程式碼評審實踐,往往是將PR合併到主幹時進行評審並作為是否合併到Master分支的一個准入條件。對於團隊辦公集中且人員比較固定的組織,可以基於commit進行評審,那麼對於每次需要評審的工作不會太高,時效性也容易把握。
如何執行程式碼評審
作者 (Author)
- 確定待評審的程式碼範圍
根據SamrtBear在思科的一個系統小組的研究,一個開發人員一次評審的程式碼在200-400之間,審查超過400行程式碼後效率和發現均呈下降趨勢。如下圖:
同時,一個小時審查的程式碼行數應該少於500行,超過500行後效率呈下降趨勢。
- 簡單的描述程式碼業務邏輯以及主要的業務流程
- 開放的心態接受評審的問題或者建議
評審者(Reviewer)
- 準備一個檢查列表
- 瞭解業務邏輯和主要流程
- 準備好一些問題,對於不確定或者不明白,儘量以問題形式跟作者溝通,而非質疑。
- 準備一些解決方案。在提出問題時候,同時思考更好的方法或者解決方案是什麼?你的方法好在什麼地方?
程式碼評審的關注點
- 功能性 - 功能完整,是否嚴格按照產品說明書實現產品的所需的功能點
- 可讀性 - 程式碼易讀易懂,其它人能夠輕鬆從程式碼中讀邏輯和設計思想,命名是一個學問。
- 可測性 - 程式碼能夠輕鬆被單元測試覆蓋,一般來說無法被單元測試覆蓋的程式碼不是一個好程式碼
- 可維護性 - 程式碼執行期間日誌輸出完整,運維人員或者其它人員可以從日誌中瞭解應用的執行邏輯和狀態。
- 效能 - 天下武功唯快不破,確保程式碼在可度量的資料量級下面保持一個穩定的效能表現。程式碼是否存在效能問題,預計峰值流量能到多少。
- 多執行緒,併發和鎖 - 在併發或者多執行緒情況下,程式碼執行結果是否有問題。過去幾個月中我們有一個應用是以Shell的方式啟動任務,每一個作業一個程式。由於這種方式帶來的資源利用率較低,打算改成多個作業執行在一個程式中(容器)以節省系統資源, 上線後發在存在多處執行緒不安全的問題,例項變數被汙染導致線上問題。
- 安全性 目前雖然有很多的掃描工具可以幫助發現程式碼安全的問題,但更專業的開發人員在寫程式碼就已經注意這個問題,避免基本的SQL隱碼攻擊,XSS跨域等問題。有興趣的同學可以參考OWASP CODE REVIEW GUIDE
程式碼評審中注意事項
- 程式碼評審不僅是技術,也社會學。雙方溝通表達能力決定程式碼評審的效率和有效性。評審者需要注意問題的方式或者語氣,就事論事,不上升到精神和思想層面。而作者則需秉承一切問題都可探討或有更好的方案的想法吸收理解他人的想法,即使評審提出不合適的問題,那麼你讓隊友知道一個正確的方法仍然是團隊和組織的收穫。
- 程式碼評審不應太過於關注程式碼風格,程式碼風格的檢查完全可以通過IDE或者掃描工具SONARCube整合CheckStyle, PMD,FINDBUG實現。
程式碼評審的參考書
-
大廠的Java編碼標準,如唯品會Java編碼規範,阿里Java編碼規範
-
設計模式: Design Patterns, Elements of Reusable Object-Oriented Software
-
程式碼整潔之道: clean code-程式碼整潔之道
-
高效能Java開發: Effective Java, Third Edition
參考文件
- Code Review
- Lessons From Google: How Code Reviews Build Company Culture
- Best Practices for Code Review
關於作者
王雲 - 唯品會財務研發微胖中年男,常年關注架構設計,高效能應用設計,軟體工程,團隊管理等領域。
相關文章
- 淺談軟體工程師的程式碼素養軟體工程工程師
- 淺談前端/軟體工程師的程式碼素養前端軟體工程工程師
- 程式碼中的軟體工程軟體工程
- 軟體測試的需求評審
- 淺談軟體開發中的防禦式程式設計程式設計
- 說透程式碼評審
- 程式碼審查或評審的最佳實踐 - FogBugz
- MySQL全面瓦解26:程式碼評審中的MySQL(團隊使用)MySql
- 2021敏捷軟體工程需求評審答辯問題總結與建議敏捷軟體工程
- [譯] 程式碼評審的 8 點建議
- 程式碼規範淺談
- 程式碼評審的18個軍規,收藏好!
- 程式碼評審的不可能三角
- Google程式碼評審介紹 - Michaela GreilerGo
- 淺談Python中的scrapy的安裝和建立工程。Python
- 海外IT工程師淺談工程師
- 淺談軟體效能提升相關的概念
- 淺談微視推薦系統中的特徵工程特徵工程
- 前端程式碼評審通常注意些什麼前端
- 谷歌程式碼評審指南已經開源谷歌
- 前端團隊程式碼評審 CheckList 清單前端
- [譯] Go 程式碼評審常見問題Go
- 我們走訪了900名微軟員工,為你揭祕全球最大軟體公司的程式碼評審機制微軟
- 談談我對 AIGC 趨勢下軟體工程重塑的理解AIGC軟體工程
- 淺談中介軟體漏洞與防護
- 進行了1000多次程式碼評審的經驗分享 - DEVdev
- 淺談專案程式碼規範
- 淺談JavaScript程式碼效能優化JavaScript優化
- 谷歌開源內部程式碼評審規範谷歌
- 為什麼程式碼評審(code reviews)很重要View
- 程式碼審計中XSS挖掘一些體會
- 【團隊建設】如何做好團隊開發中的 CodeReview(程式碼評審)?View
- 淺談DOTA2中的碰撞體積
- 淺談Kotlin中的Sequences原始碼解析(十)Kotlin原始碼
- 淺談JavaScript中的thisJavaScript
- 中國的頂級軟體程式設計工程師和歐美的頂級軟體程式設計工程師差距有多大?程式設計工程師
- 實踐篇(三):如何有效評審軟體架構圖?架構
- [譯] 如何讓高效的程式碼評審成為一種文化