如何進行 code review？

代碼 review 中的學問萬千，高效地進行代碼 review 不僅可以節約時間，並且能夠幫助寫代碼、review 代碼的人共同進步。

他山之石可以攻玉，100offer 說推出的「技巧」專欄，本周帶來一篇湯不熱工程師 cyle 的博文翻譯，看看他們是如何進行代碼 review 的。

在 Tumblr，review 代碼對於所有的工程師來說，都是一項十分重要的工作，甚至比寫代碼本身更重要。我們的代碼倉庫被數百人共享，所以，我們不僅要寫最好的代碼，還要盡量使寫出來的代碼易於理解。而這一切的關鍵因素就是花時間 review 別人的代碼，保證一切都是有條不紊的進行。

在 Tumblr，代碼的所有的改動都是通過在一個內部的 github 服務上提交申請（Pull request,以下簡稱PR）的方式完成的。我們的代碼倉庫裡面同時存放著 PHP 寫的後端，資料庫模式， swift/Obj-C 寫的 iOS 應用，JAVA/Kotlin 寫的 Android 應用，Go/C/C++ 寫的基礎架構，以及其他 Scala，Node.js，Python 或其他語言寫的項目。我們所有的代碼倉庫都是由代碼作者提交 PR，然後再由同事進行審閱，最後再合入到主分支並發布到生產環境對用戶提供服務。

從我加入 Tumblr 以來，我個人 review 代碼的方式發生了巨大的變化。以前，我主要是自己寫代碼然後在一小撮人里 review；現在在 Tumblr，龐大的代碼倉庫有者數百名貢獻者，變化之大可想而知。幸運的是，我遇到了很多好的前輩。開始的時候我一個月 review 一個 PR，現在我平均每周需要 review 25個 PR。以下是我在 review 代碼期間遵循的一些基本原則，這些原則使得我能夠及時 review 代碼，並能給他人帶來幫助。

你需要知道你在給誰 review 代碼

在收到 PR 的時候，我關注的第一件事情是：「誰寫的這段代碼？TA 是初級工程師還是資深工程師？TA 是剛接觸到這部分代碼還是開發多年的老鳥？我以前是否 review 過 TA 的代碼？我對這段代碼所屬的模塊是否熟悉？」

當我 review 我熟悉的人的代碼的時候，我十分清楚 TA 寫這段代碼的時候是怎麼想的，並且我知道 TA 在寫代碼可能遇到什麼問題。初級工程師的常常需要更多手把手的指導，比如為他們提供更多的樣例代碼和參考；資深工程師則需要提醒他們注意他們寫的高性能，抽象或者討巧的代碼是很難閱讀的，所以需要寫更多的注釋和文檔。

另外，在對 review 的代碼寫評論的時候，也需要注意讓除了提 PR 的作者本人之外的人能夠看懂。因為：

有些人是通過別人review代碼的評論學習的；

對初級工程師而言，這是幫助他們理解Turmble代碼複雜性的方法。在六個月之內，你很可能會再次閱讀這段代碼，並理解它是如何運作的，如果有一段有意義的 code review 評論在那裡，你也就更容易知道當初這段代碼為什麼這麼寫，以及他是如何工作的。

review 代碼的時候也需要想著其他人

我 review 代碼的關鍵在於，無論誰提交代碼改動的時候，都需要知道這段改動本身的的含義以及做出這寫改動的動機和上下文。對我來說，理想情況是任何一個人看到這個 PR，都有足夠的上下文去理解相應的改動，TA 能夠知道這段改動為什麼要這麼寫以及它究竟是如何工作的。特別是陳年的老代碼和共享的代碼倉庫，也許三年之後，有人還會需要從這個 PR 去理解它做了什麼。如果做不到上面說的需求的話，或者這次 PR 裡面甚至都沒有任何的上下文信息，那就一定是有問題的。細節總歸是越多越好。

我從來不擔心代碼風格或者語法的問題，因為我們有自動化的流程來保證新代碼或者改動是符合我們的代碼要求的。正如我在我是如何寫代碼的說的，我需要的有清楚的文檔（隨代碼的注釋和專門的文檔）的，易於理解（哪怕不是那麼討巧）的的代碼。我寧願閱讀有十倍代碼量但是易於理解的代碼，而不是僅一行的複雜難懂的多重嵌套，特別是這段代碼的作者已經在這裡堵了好幾次，並且被那些陳年的，沒有文檔的「聰明"代碼折騰得要死的時候。

我覺得我能夠理解這次代碼的改動之後，我還會從一個不怎麼了解這部分代碼的人的角度重新審視它（因為下次我也可能 review 不了解的代碼），並思考如何如何使得這份代碼更加清晰。我會試著從一個剛入職六個月的新手的角度來看這段代碼，並理解它是如何工作的。

懂得 PR 的影響面

很多時候單個的 PR 並不能把所有的事情工作的完成。在 Tumblr，我們總是試圖讓每個 PR 都儘可能的小，那樣的話我們就能夠快速且安全的進行代碼 review，而不必要攢到 5000 行改動才進行 review。因此，一些大的工作需要被分解成小的片段，有些 PR 負責構建基礎的組件，有些 PR 則是完成了基礎實現之後做的。

換句話說，一些代碼常常有一些待完成的事項或者以後需要修正的點，那麼在代碼裡面標註好，寫下待辦事項的名字和具體的工作，就是十分常見的行為了。這樣，我們就不用等到完成了所有的代碼之後再提交這次 PR 了。

關注整個代碼 review 的過程

幫助我及時 review 代碼，並且跟進整個 review 過程的主要工具是：郵件。我會檢查我收到的每一份 github 郵件，我並不保證倉庫裡面的所有改動都會通知到我，但是我會檢查我收到的任何一封跟 PR 相關的郵件。我就是依靠這種方式跟進整個 reivew 過程的，因為這個來回理想情況下不會超過一整天。

在 Tumblr，大多數的 reviewer 是自動的在 PR 作者裡面輪流選出來的。攤派任務的時候會給我發送一封郵件，並把跟這個PR相關的所有信息都和我關聯起來。自此以後，我就需要一直關注我的郵件，並保證我不僅要抽時間儘快 review 代碼，還需要跟進這次 PR 中作者對我提的評論進行的對應的修改。

記住你是一個「人」

無論是在 review 代碼還是寫代碼的過程中，必須要始終記得一件事情：你是一個「人」，並且你 review 的代碼的作者也是一個「人」。

通過 review 代碼讓他們覺得受到質疑對你們都有好處。在你寫建議，有問題或者發現 TA 沒注意到一個邊界條件的時候，保持友善的態度。即使是寫了多年「完美無缺」代碼的老鳥，有些時候也應該把他們當作會犯錯誤的普通人來看待。即使那些與你共事很久的人並不在意你拿他們開玩笑，總會有新人不理解的。

記住，被很多人分享的，並且在不斷更新的代碼必然往往是奇怪的、複雜的，特別是那些已經存在了十多年的代碼。記住，很多時候工作是十分倉促的，你要做的就是在有限的時間完成儘可能優質的代碼。我們並不能為了完美的代碼耽擱項目進度，但是我們需要保證我們寫的每一份代碼儘可能的好，無論我們在寫代碼還是在 review 代碼。

翻譯：100offer

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！