以下為譯文：
數百萬年前，人類祖先人猿學會直立行走——解放雙手——最終進化到人；而程式碼審查在開發過程中有著異曲同工之妙——區別出野蠻開發和先進開發。
然而，在實際工作中，以下聲音總不絕於耳：
- “程式碼審查在專案中簡直就是浪費時間！”
- “我根本沒有時間去做複查。”
- “由於我那個謹慎的拍檔還沒做好複查，進度只能延後了。”
- “你確定，我的同事要求我修改程式碼嗎？請向他們解釋一下，任何輕微地改動都會讓我的程式碼失去原有的優雅。”
作為專業的軟體開發人員，持續提高程式碼質量是工作生涯不斷追求的目標之一。無論我們有多麼優秀，都離不開團隊；而程式碼複查是個人與團隊的潤滑劑：
- 當局者迷，旁觀者清。程式碼複查如同為我們安裝了後視鏡；
- 使我們的程式碼多了至少一個知音人；
- 能幫助新員工在這個過程中學習和領悟到前輩的程式碼精髓；
- 有助開展知識共享，眾“智”成城。
要做就要做到最好
如果想要達成上述種種美好結果，是離不開時間和工作的科學安排的。僅僅做好程式碼縮排、變數命名規範等基本工作，還不能算得上完美。而如果曾經嘗試過結對程式設計，或許你會發現其所花的時間往往都比程式碼複查要多。
我的建議是用開長總時長的四分之一時間來進行程式碼複查。舉例來說，如果開發總用時為兩天，那麼應該花上大約四個小時來進行復查。
當然，如果能把事情做對，可不必拘泥於時間的多少。進一步說，我們必須能看明白將要複查的程式碼。這不僅代表要掌握基本的語言語法，更關鍵的是要掌握整個程式碼的架構，所用元件或庫等細節。如果不能做到對每一行程式碼所做的事情都瞭然於胸，這樣的複查工作是沒有多少價值的。所以要做好這點是不能一味講求速度的，必須花一番功夫來從頭到尾對程式碼進行梳理分析。
此外還有兩件事是務必要做到的：
- 複查工作中包含所有必須的測試工作；
- 做好設計文件的編寫工作。
避免拖延症
今天的工作今天完成是最完美的工作狀態，否則一旦拖延症出現，再多再好的複查都只會成為開發過程中的絆腳石。好的複查需要緊密而持久的努力，不是搞搞突擊就能做好的。
因此，開發者應當盡力做到日清日結。把複查作為每天工作的開端是個不錯的主意；理清舊的思路將有助於開展新的編碼任務。也或許有的人喜歡在午休或下班前進行，無論在什麼時候進行，以下幾點是應該避免的：
- 讓積壓工作越積越多；
- 由於複查沒有做好而導致進度延後；
- 由於程式碼更新頻率快就放棄做複查；
- 往往在最後一刻才去做複查。
編寫出可複查的程式碼
不應該把所有複查工作都推給複查員。如果我的同事花了一週時間新增了看起來比較亂的程式碼，這對複查工作無疑是重大打擊，也很難讓人摸清其思路和結構。
所以我們在程式設計時，要有意識地把程式碼劃分為可操作單元。我們使用的方法是scrum，它為我們的開發工作做了很明晰的指導，同時使得整個開發過程有跡可循，便於進行追溯和回顧。
其次，在與複查員進行討論前要搞好關係。這樣將有助於雙方對彼此有所瞭解，從而減少討論時矛盾發生的機率。
再者，專案結構應當在設計文件中描述得清楚具體。這對於專案新成員的成長是大有裨益的，同時能幫助複查員提高工作效率。
最後也是最重要的一點是在自我複查過程中做好註釋。換言之要先自行對程式碼過一遍，把需要做出說明的地方標示出來並解釋清楚。有研究表明，開發者在對自己的進行復查和註釋時，經常會找出不少瑕疵。
大型程式碼重構
有時候如果需要進行程式碼重構，這勢必會影響到很多元件，特別是較大型的應用。在這種情況下，最好的解決方案是逐步推進重構工作。先對要做的變更進行劃分，然後根據修改意圖進行分段式重構。當這部分變更完成並做好複查後，再執行第二部分的重構，重複該步驟直至完成全部工作。這或許增加了重構用時，但會帶來更高質量的程式碼同時可以減輕複查員的工作量。
如果實際情況真的不允許進行逐步重構，可以試試結對程式設計。
解決矛盾
在一個技術團隊中，各人有各自的觀點，如何達成共識是成敗的關鍵。作為開發者，應該保持開明的心態並虛心接受不同的意見。避免固步自封，避免對自我複查工作的不屑一顧。如果有人提議把我們一些重複的程式碼做成一個可複用函式，這並不代表我們之前的工作是毫無價值的。
而作為複查員，要懂得人情世故。在給出修改意見前，先考慮清楚這真的會更好抑或僅僅是風格上的不同看法。提議說法可以是：“如果嘗試另一種方法，或許會更好”或“有同事建議這樣做”，而要避免的是：“就連我家寵物都能寫出比這好的演算法！”
如果真的一時僵持不下，爭議雙方不妨請教第三個開發人員，從他的角度來再次審度各自的觀點，直到形成共識，三人行，必有我師焉。（責編：張紅月）
相關閱讀
評論(1)