瀏覽評論中的CL
摘要
現在您知道要查找的內容了，管理分佈在多個文件中的審閱的最有效方法是什麼？
- 更改有意義嗎？它有一個很好的 描述嗎？
- 首先看一下變化中最重要的部分。整體設計得好嗎？
- 以適當的順序查看其餘的CL。
第一步：全面瞭解變化
查看CL的說明以及CL的一般功能。這種變化甚至有意義嗎？如果最初不應該進行此更改，請立即做出答覆，說明爲什麼不應該進行更改。當您拒絕這樣的更改時，最好還是向開發人員建議他們應該做些什麼。
例如，您可能會說：“看起來您爲此做了一些出色的工作，謝謝！但是，實際上，我們正朝着刪除您在此處修改的FooWidget系統的方向發展，因此我們現在不希望對其進行任何新的修改。相反，您可以重構我們的新BarWidget類嗎？”
請注意，審閱者不僅拒絕當前的CL並提出其他建議，而且還禮貌地做到了。這種禮貌很重要，因爲即使我們不同意，我們也希望表明我們彼此尊重，作爲開發人員。
如果獲得的多個CL代表您不想進行的更改，則應考慮重新設計團隊的開發流程或外部貢獻者的已發佈流程，以便在編寫CL之前進行更多的溝通。最好先告訴人們“不”，然後再做大量的工作，現在必須將它們扔掉或徹底改寫。
第二步：檢查CL的主要部分
查找屬於此CL的“主要”部分的文件。通常，一個文件的邏輯更改數量最多，這是CL的主要部分。首先看這些主要部分。這有助於爲CL的所有較小部分提供上下文，並通常加快執行代碼審閱的速度。如果CL太大，您無法確定哪些部分是主要零件，請詢問開發人員您應該首先看什麼，或要求他們 將CL分成多個CL。
如果您發現CL的這一部分存在一些主要的設計問題，則即使您現在沒有時間審查CL的其餘部分，也應立即發送這些評論。實際上，複查其餘的CL可能會浪費時間，因爲如果設計問題足夠嚴重，那麼正在複查的許多其他代碼都將消失，並且無論如何都不會變得很重要。
立即發出這些主要設計評論非常重要有兩個主要原因：
- 開發人員通常會郵寄一個CL，然後在等待審閱時立即根據該CL開始新工作。如果您正在審查的CL中存在重大設計問題，那麼他們也將不得不重新設計其以後的CL。您希望在他們在有問題的設計之上進行過多額外工作之前就抓住他們。
- 重大的設計變更比小的變更需要更長的時間。開發人員幾乎都有截止日期；爲了在截止日期之前完成任務，並在代碼庫中保留高質量的代碼，開發人員需要儘快開始CL的所有重大重做。
第三步：按適當的順序瀏覽其餘的CL
確認CL整體上沒有大的設計問題後，請嘗試找出邏輯順序來瀏覽文件，同時還要確保不要錯過對任何文件的審查。通常，在瀏覽了主要文件之後，按照代碼審查工具向您展示它們的順序瀏覽每個文件是最簡單的。有時在閱讀主要代碼之前先閱讀測試也是有幫助的，因爲這樣您就可以知道更改應該做什麼。
參考
https://google.github.io/eng-practices/review/reviewer/navigate.html