點選上方“中興開發者社群”，關注我們

每天讀一篇一線開發者原創好文

▍作者簡介

丁一：無線研究院敏捷教練，技術愛好者，喜歡閱讀和分享，致力於讓敏捷管理實踐和技術實踐在團隊中更好的落地。

程式碼走查，英文詞語叫：Code Review，也叫“程式碼審查”，它是我們公司的一項傳統保留專案。記得一位工作超過20年的老員工說過：“我加入中興的時候就有程式碼走查了。”，可見這項實踐的悠久歷史。

1.程式碼走查的形式

程式碼走查的形式有很多種，主要有以下幾種形式：

•  每日走查：只針對每日提交的內容進行評審，走查時間和地點都比較靈活。

• 專項走查：針對某個具體問題或者專題進行走查。評審人需要提前傳送評審內容給大家進行預審，然後安排專門的會議室進行評審，時間較長。

•  結對互查：提交程式碼前指定某位同事進行線上評審，評審通過後才能合入程式碼。

本文要介紹的是每日程式碼走查，就是大家圍在一臺開發機周圍，逐一輪換講解所有提交的內容。

就即使是每日程式碼走查，也被我們團隊玩出了花樣：

• 談心式走查

• 批判式走查

• 半蹲式走查

• 伴侶式走查

2.程式碼走查的好處

持續、有效的開展程式碼走查，將會收穫許多收益，具體表現在：

• 能及時發現程式碼中的Bug，保證版本質量。

• 提升程式碼的可讀性、可維護性，建立團隊共同的編碼風格。

• 有利於知識共享，打破技能壁壘，避免單點故障。

• 通過展示自己的優秀程式碼和設計思路，提升了個人成就感。

• 通過講解自己的程式碼，對個人溝通能力也是一種提升。特別是對於平時比較內向或者不太喜歡發言的同學。

• 給大家提供了一個每天交流、溝通的平臺。工作一天了，也挺累的了，是時候停下手工的編碼工作，一起說說話，交流一下了。

3.程式碼走查中的“壞味道”

雖然程式碼走查有這麼多好處，可在實施的過程中並不會像想象中的那麼美好，會遇到各種各樣的問題，總結起來的“壞味道”有：

• 開發的時間本來就不多，再加上程式碼走查，會打亂開發節奏。

• 評審的同事對程式碼不熟悉，發現不了問題。

• 討論發散或者糾纏在某個具體細節中，導致時間把控不好。

• 評審量大。只能走查部分同事的程式碼，其他同事的內容沒有覆蓋。

• 提問題的總是那幾個人，其他人都是圍觀群眾。

4.如何做有效的程式碼走查

雖然程式碼走查很多團隊都在做，但要想真正做好它並不是件容易的事情。我們團隊經過長期實踐，摸索出一些經驗和大家分享：

4.1程式碼走查的時間

程式碼走查建議在固定時間舉行，當團隊養成習慣後，就會很自然成為團隊日常工作的一部分。以我們團隊為例，走查時間安排在：

• 每天下午16:30--17:30；

• 第二天上午9:00--9:30。

分兩塊時間走查是考慮一次走查的內容會很多，有些內容可能走查不完，就分兩次進行。如果當天下午能把全部過完，第二天上午就再進行走查活動。   

另外，在實踐的過程中，如果有同事反饋程式碼正寫在“興頭”上或者正在定位緊急故障，可以申請延緩或者不參加本次走查活動。

4.2程式碼走查的內容

我們團隊的走查內容已經超越了程式碼本身，還會涉及方案審查、演示等活動。

具體評審內容為；

• 新增程式碼：bug修改，新特性或重構引入的程式碼變更。

• 設計方案：一般為增量式方案評審。

• Mini showcase：針對每日實現的功能進行展示。

4.3程式碼走查的關注點

l 靜態編碼問題

主要關注靜態編碼錯誤、程式設計風格、命名合理性、Clean Code等內容。

雖然這部分檢查項也有有意義，但完全可以在合入程式碼時，通過靜態檢查工具（比如Findbugs，PMD等）消除掉。還是要儘量留給團隊成員走查業務或者設計等問題。

l 功能問題

程式碼的行為是否與預期一致，其邏輯是否是正確無誤？

l 設計問題

針對現有的設計提出不同的思路，多問問為什麼這麼做，有沒有更有效的方法，這樣通過集思廣益可以提供更加優良的設計方法。

l 測試問題

v 測試用例是否完備?

v 測試用例實現是否有效？

l 效能問題

新增功能或者修改功能是否對已有效能測試結果有不良影響？

l 安全問題

v 開源軟體協議風險

v 是否有安全漏洞

4.4角色

程式碼走查中的角色需要從不同的維度考慮。

l 從業務角色考慮：

業務角色儘量完備：至少包括BA、Dev、QA等角色。特別是BA，無論再忙，還是要參加到團隊的走查活動中，從設計層面上保證實現沒有走偏，也能從開發人員那裡獲取最新的問題反饋，從而及時對方案進行修改。

切記：程式碼走查不只是開發人員的事情！需要多種角色同時參與，因為走查活動不僅僅要看功能是否實現了，還要看程式碼和設計是否一致？測試用例是否完備和有效？

l 從走查活動的角色考慮：

  一般包括如下角色：

這裡要提的一個關鍵角色是主持人，

我們團隊之前走查程式碼是沒有主持人的，走查時經常出現討論發散、時間控制不好的情況。

在回顧會上，大家針對這個問題做了討論，最後選舉了一位值得信賴的女主持人。

有了主持人之後，情況果然有了很大改善。一旦發現討論發散、時間過長的情況，主持人會及時喊停，把大家拉回到正確的節奏上。

主持人要求有敏銳的洞察力，良好的大局觀，並且有一定的影響力，最好由團隊選舉產生，可以是SM，也可以不是。

(找找女主持人在哪裡？)

4.5走查過程

4.5.1走查前

• 每個人介紹下要今天走查的內容和預計時間，便於主持人做好規劃。

• 優先走查自己認為風險較大的地方。

4.5.2走查中

l 講解人先介紹業務背景和程式碼關鍵流程，

避免一上來就講程式碼，這種方式跳躍性比較強。只有對這部分程式碼非常熟悉的同事才能發現問題，而那些第一次接觸的同事很難做到這一點，於是很快就會失去走查的興趣。     

l 一次走查的程式碼儘量少。

走查的程式碼行數控制在200--400行。

在審查大的修改時，不僅要看很多行程式碼，還要檢視大量的依賴程式碼才能理解。

將待審查的程式碼隔離為小的修改可以降低審查者的精神負擔並讓審查過程更加順暢。

l 程式碼走查一頁紙規範

很多團隊都制定了程式碼走查一頁紙規範，比如資源使用完要釋放，多執行緒併發問題等。有了走查清單後，便於團隊快速識別問題，提高走查效率。

l 記錄發現的問題

對於程式碼中發現的問題，可以由記錄員記錄到文件中。而我們團隊的做法是讓講解人直接在程式碼中以to-do的方式進行標記。

4.5.3走查後

對於走查中記錄的問題或者程式碼中標示為“todo”的條目進行修改，然後在下次走查時檢查是否修改完成。

4.6溝通

在程式碼走查時，有時會看到為了爭一個問題，雙方搞的面紅耳赤。在我們強調良性對抗的同時，也要儘量避免由於溝通問題導致的不必要衝突。

前面也提到過，程式碼走查問題的本質是一個溝通問題。所以這裡要提一下程式碼走查中的溝通技巧：

l 對於評審人

1.避免出現“你為什麼”，“你為什麼不”這樣的問題。

它會使人對立，“為什麼把它宣告為全域性變數？”可以更好地表達為“我不明白為什麼這裡用一個全域性變數”。

2.不要提出可能聽起來帶指責的要求或言論。

例如:“你沒有遵循標準XYZ”，更好的方式是：“你對標準 XYZ 有什麼看法，它是否適用於這裡？”。

3.不要吝嗇自己的讚揚。

當發現有好的程式碼實現或者設計思路時，請及時給與表揚。

l 對於講解人

保持好心態，別人是針對程式碼提問題，而不是針對人。