同行代碼審查實戰分析

jopen 9年前發布 | 16K 次閱讀 代碼審查

同行代碼審查實戰分析

英文原文:Practical Lessons in Peer Code Review

代碼審查(Code Review)是軟件開發中常用的手段,和 QA 測試相比,它更容易發現較難發現的問題,還可以幫助團隊成員提高編程技能,統一編程風格等。本文作者從實際出發,詳細分析了開發者在代碼審查過程中會遇到的問題及解決方法。

以下為譯文:

數百萬年前,人類祖先人猿學會直立行走——解放雙手——最終進化到人;而代碼審查在開發過程中有著異曲同工之妙——區別出野蠻開發和先進開發。

然而,在實際工作中,以下聲音總不絕于耳:

  1. “代碼審查在項目中簡直就是浪費時間!”
  2. “我根本沒有時間去做復查。”
  3. “由于我那個謹慎的拍檔還沒做好復查,進度只能延后了。”
  4. “你確定,我的同事要求我修改代碼嗎?請向他們解釋一下,任何輕微地改動都會讓我的代碼失去原有的優雅。”

那么問題來了,我們為什么需要做代碼復查?

作為專業的軟件開發人員,持續提高代碼質量是工作生涯不斷追求的目標之一。無論我們有多么優秀,都離不開團隊;而代碼復查是個人與團隊的潤滑劑:

  • 當局者迷,旁觀者清。代碼復查如同為我們安裝了后視鏡;
  • 使我們的代碼多了至少一個知音人;
  • 能幫助新員工在這個過程中學習和領悟到前輩的代碼精髓;
  • 有助開展知識共享,眾“智”成城。

要做就要做到最好

如果想要達成上述種種美好結果,是離不開時間和工作的科學安排的。僅僅做好代碼縮進、變量命名規范等基本工作,還不能算得上完美。而如果曾經嘗試過結對編程,或許你會發現其所花的時間往往都比代碼復查要多。

我的建議是用開長總時長的四分之一時間來進行代碼復查。舉例來說,如果開發總用時為兩天,那么應該花上大約四個小時來進行復查。

當然,如果能把事情做對,可不必拘泥于時間的多少。進一步說,我們必須能看明白將要復查的代碼。這不僅代表要掌握基本的語言語法,更關鍵的是要掌握整個代碼的架構,所用組件或庫等細節。如果不能做到對每一行代碼所做的事情都了然于胸,這樣的復查工作是沒有多少價值的。所以要做好這點是不能一味講求速度的,必須花一番功夫來從頭到尾對代碼進行梳理分析。

此外還有兩件事是務必要做到的:

  1. 復查工作中包含所有必須的測試工作;
  2. 做好設計文檔的編寫工作。

避免拖延癥

今天的工作今天完成是最完美的工作狀態,否則一旦拖延癥出現,再多再好的復查都只會成為開發過程中的絆腳石。好的復查需要緊密而持久的努力,不是搞搞突擊就能做好的。

因此,開發者應當盡力做到日清日結。把復查作為每天工作的開端是個不錯的主意;理清舊的思路將有助于開展新的編碼任務。也或許有的人喜歡在午休或下班前進行,無論在什么時候進行,以下幾點是應該避免的:

  • 讓積壓工作越積越多;
  • 由于復查沒有做好而導致進度延后;
  • 由于代碼更新頻率快就放棄做復查;
  • 往往在最后一刻才去做復查。

編寫出可復查的代碼

不應該把所有復查工作都推給復查員。如果我的同事花了一周時間添加了看起來比較亂的代碼,這對復查工作無疑是重大打擊,也很難讓人摸清其思路和結構。

所以我們在編程時,要有意識地把代碼劃分為可操作單元。我們使用的方法是 scrum,它為我們的開發工作做了很明晰的指導,同時使得整個開發過程有跡可循,便于進行追溯和回顧。

其次,在與復查員進行討論前要搞好關系。這樣將有助于雙方對彼此有所了解,從而減少討論時矛盾發生的機率。

再者,項目結構應當在設計文檔中描述得清楚具體。這對于項目新成員的成長是大有裨益的,同時能幫助復查員提高工作效率。

最后也是最重要的一點是在自我復查過程中做好注釋。換言之要先自行對代碼過一遍,把需要做出說明的地方標示出來并解釋清楚。有研究表明,開發者在對自己的進行復查和注釋時,經常會找出不少瑕疵。

大型代碼重構

有時候如果需要進行代碼重構,這勢必會影響到很多組件,特別是較大型的應用。在這種情況下,最好的解決方案是逐步推進重構工作。先對要做的變更進行劃分,然后根據修改意圖進行分段式重構。當這部分變更完成并做好復查后,再執行第二部分的重構,重復該步驟直至完成全部工作。這或許增加了重構用時,但會帶來更高質量的代碼同時可以減輕復查員的工作量。

如果實際情況真的不允許進行逐步重構,可以試試結對編程。

解決矛盾

在一個技術團隊中,各人有各自的觀點,如何達成共識是成敗的關鍵。作為開發者,應該保持開明的心態并虛心接受不同的意見。避免固步自封,避免對自我復查工作的不屑一顧。如果有人提議把我們一些重復的代碼做成一個可復用函數,這并不代表我們之前的工作是毫無價值的。

而作為復查員,要懂得人情世故。在給出修改意見前,先考慮清楚這真的會更好抑或僅僅是風格上的不同看法。提議說法可以是:“如果嘗試另一種方法,或許會更好”或“有同事建議這樣做”,而要避免的是:“就連我家寵物都能寫出比這好的算法!”

如果真的一時僵持不下,爭議雙方不妨請教第三個開發人員,從他的角度來再次審度各自的觀點,直到形成共識,三人行,必有我師焉。

來自:http://news.cnblogs.com/n/514015/

 本文由用戶 jopen 自行上傳分享,僅供網友學習交流。所有權歸原作者,若您的權利被侵害,請聯系管理員。
 轉載本站原創文章,請注明出處,并保留原始鏈接、圖片水印。
 本站是一個以用戶分享為主的開源技術平臺,歡迎各類分享!