7 個 code review 的技巧

Code review，中文譯為「代碼審查」，是指對代碼進行系統性的審查，通常是和其他開發者來共同進行。這里作者就講了在 Asana 中他們是怎么來做代碼審查的。

1.先確定 code review 的目標優先級

在 code review 之前先和你的團隊成員明確 code review 中事項的優先級。

作者認為 code review 應該做的事：

• 熟悉同事在編程時的思考方式，這樣其余同事以后如果有需要就可以更輕松、快速的更改代碼。
• 向同事介紹修改了哪些文件，增加了什么樣的功能，這樣在問題出現時，可以保證至少有兩個人可以幫助診斷、解決問題。

不建議在 code review 中做的事：

• 找 bug。自動化測試、運行程序要比幾個人坐著看代碼有效率多了。
• 檢查代碼規范。現在的 IDE 和編輯器都有自動規范代碼的工具，為什么還要在這方面浪費人力呢？

2.把程序跑起來

讀其實是一種很不自然的和代碼交互的方式。僅僅靠讀代碼來找 bug 效率實在不能算高，要知道計算機能比你的大腦更好地運行代碼。

把程序運行起來，親自試一試，或許你會有一些和他們測試時不同的操作，發現一些他們遺漏的問題。

并且現在的 IDE 中斷點調試，都能夠很詳細的顯示運行時的程序數據，這能幫助你更容易的理解這段代碼是如何運行的。

3.明確方法的調用層次

作者發現很多人談起 code review 的第一印象就是一堆人坐在一個電腦面前一行一行的看代碼。但這么做其實效率是很低的，除非你的經驗非常豐富，否則真的不建議就靠一雙眼睛和你的大腦來做 code review。用工具明確方法的調用層次，能幫助你更有效的梳理代碼邏輯。

4.盡可能及時的進行 code review

當你收到別人的 code review 邀請時，盡量第一時間就開始。因為這時作者的記憶是最清晰的，并且通常會對你的及時反饋心懷感激，這種正面情緒對于 code review 是非常有幫助的。

如果你覺得自己在面對 code review 時有困難的話，作者在這里推薦了兩個方法：

• 事先設置一個時限，比如半小時。也就是在你的第一次 review 中，先花半個小時理解變動的代碼，寫下自己的問題。如果在這個時間范圍內，你不能確定代碼變動是否沒有問題，把你的想法和問題先發給作者，之后再確定一個時間進一步的 review。
• 在你的機器上保留兩個獨立的倉庫。一個用于你自己的修改，另一個用于 review。這樣你和作者之間的修改就能夠保持彼此獨立。

5.在你讀代碼之前，先想想自己會怎么做

先讀一下功能說明，思考下如果是自己來可能會怎么做，之后再查看作者實際做出的修改。如果有和你想得不一樣的地方，就可以和作者進行交流，討論清楚為什么。這樣做能使得你們兩個都得到成長，還能提高 code review 的效率。

6.在實際的開發環境中 review

現在的 code review 早就不是光用眼睛看啦，各種強大的 IDE 完全可以成為我們的一大助力。善用 IDE 的力量。

7.不要吝嗇你的贊揚，除非你能證明那里確實有一個 bug

每個人的內心深處都是期待被別人稱贊的，因此在 code review 開始的時候不要老是揪著變量命名、代碼重復之類的問題。先集中注意力在真正重要的地方，給作者一個舒服、放松的心態（通常剛開始 code review 的時候作者是會很緊張的）。這樣他們也就會樂于接受你對于代碼風格等方面的建議了。: )

來自：https://zhuanlan.zhihu.com/p/24562689