Google 如何進行 Code Review - 3
一窺 Google 內部程式審核的指導原則 - Navigating a CL in review
文章目錄
現在你已經知道審核時要看些什麼，但怎樣才是審核分散在多個文件中的改動最有效的方法?
- 改動是否合理? 他是否有好的描述 (description)
- 優先看 CL 最重要的改動。它整體是否有完善的設計?
- 用合理的順序看 CL 剩餘的改動
Look at the CL CL description and what the CL does in general.
查看 CL 描述以及它做什麼
該改動是否有意義、合理？如果在第一時間認為不應該發生這種變化，請立即說明為什麼不該這樣做的原因。 當拒絕類似這樣的更改時，向開發人員提供建議告訴他們應該怎麼做什麼也是一個好主意 [1]。
例如，你可以說「看起來你已經完成一些不錯的事情，謝謝! 但我們實際上正朝著刪除你正在修改的 FooWidget 系統的方向前進，所以現階段我們不想對它進行任何新的修改。 你覺得不如重構我們的新 BarWidget class 的主意如何?」
值得注意的是，審核者在委婉拒絕該 CL 的同時提供替代方案，而且仍然保持「禮貌」。這種禮貌是很重要，因為我們希望表明即使不同意也會相互保持尊重。
如果你有幾個 CL 裡頭包含你不想這樣做的改動時 (a few CLs that represent changes you don’t want to make)， 你應該考慮重新開發團隊的開發過程，或發佈開發流程給外部貢獻者 (contributor) 知道，以便在任何 CL 被撰寫前有更多的溝通。 最好是在他們開始投入大量工作前説「不」，避免那些已經投入心血的工作現在必須被拋棄或徹底重寫。
- [1] 提供替代方案讓對方知道該怎麼做，而非讓其自行獨自摸索。
點出可能問題，告知替代方案或指點方向
Find the file or files that are the “main” part of this CL.
找到 CL 最核心的部分的那些文件
通常 CL 內會有文件包含大量的邏輯改動，而它正是 CL 的主要部分。因此我們要首先查看這些主要部分。 這有助於為 CL 的其他較小部分提供適當上下文，而且這樣通常可以提高審查速度。 如果 CL 太大導致於無法確定哪裡是主要部分時，請向開發者詢問首先應當查看的內容，或者要求他們將 CL 拆分為多個 CL。
如果在主要部分發現存在一些主要的設計問題時，即使沒有時間立即查看 CL 的其餘部分，也應立即留下評論告知此問題。
因為事實上，因為該設計問題足夠嚴重的話，繼續審查其餘部分很可能只是浪費寶貴時間，因為其他正在審查的程式可能都將無關緊或消失。
立刻發送關於主要設計的評論非常重要有兩個主要原因:
通常開發者在送出 CL 後，在等待審核過程中便已經開始著手基於該 CL 的新工作。此時如果正在審核的 CL 存在重大設計問題的話，開發者將不得不重新撰寫所有基於它的後續所有 CL。 因此你會想在他們投入額外時間在有問題的設計上之前阻止他們。
主要設計變更通常需要較長時間才能完成，但每個開發人員幾乎都有自己截止日期。為了趕上截止日期並保證程式庫品質，開發者需要盡快開始或重做 CL 任何的主要設計變更。
一旦確認整個 CL 沒有重大的設計問題時，試著找出一個有邏輯順序 (logical sequence) 來審核剩餘檔案，並確保不會錯過其中任何一個。 通常在查看主要部分後，最簡單的方式是按照程式碼審查工具提供的順序來瀏覽每個文件。 有時在閱讀主要程式前先閱讀測試也是非常有幫助的，如此一來你就可以了解應該做、看些什麼。
相關文章
- Google 如何進行 Code Review - 6
- Google 如何進行 Code Review - 5
- Google 如何進行 Code Review - 4
- Google 如何進行 Code Review - 2
- Google 如何進行 Code Review - 1
文章內容的轉載、重製、發佈，請註明出處: https://tachingchen.com/tw/
Twitter
Google+
Facebook
Reddit
LinkedIn
StumbleUpon
Pinterest
Email