Google 如何進行 Code Review - 6
一窺 Google 內部程式審核的指導原則 - Handling Pushback in Code Reviews
文章目錄
有時開發人員會推遲處理程式審查產生的評論。要麼他們不同意你的建議，要麼他們會抱怨你太嚴格了。
當開發人員不同意你的建議時，請先花點時間考慮一下他們是否是正確的。因為通常他們比你更接近程式碼，所以他們可能真的比起你來說對程式的某些層面具有更好的洞察力。 他們的論點有意義嗎? 從程式品質的角度來看它是否合理? 如果是的話，讓他們知道他們是對的，然後讓問題沈下去。
但開發人員也並不總是對的。在這種情況下，審核者應該更進一步解釋為什麼認為自己的建議是正確的。 一個好的解釋通常展示了「對開發人員的回覆的理解」以及有關「為什麼被要求對出做出改動」等資訊。
尤其是當審核人員認為給出的建議會改善程式品質時，便應該繼續宣揚自己的論點。只要他們相信所需的額外的工作量最終會改善整體程式品質。
提高整體程式健康狀況這件事，往往是經由每個微小的改動來發生
有時往往需要幾番解釋一個建議才能讓對方真正理解你的用意。切記，始終保持禮貌， 讓開發人員知道你有聽到他們在說什麼，只是你不同意該論點而已。
審核者有時會認為若自己堅持改進的話，會讓開發人員覺得沮喪不安。 的確開發人員有時會感到很沮喪，但這通常是十分短暫的，甚至後來他們非常感謝你幫助他們提高程式品質。 一般來說，只要你在評論中表現得很有禮貌，開發人員實際上根本不會感到沮喪，這些擔憂都僅存在於審核者心中而已。 沮喪很多時候是對於審核評論的寫作方式有關，而並非來自審核者對於程式品質的堅持。
一個常見的推遲原因是開發人員希望完成任務 (這可以理解)。他們不想通過另一輪審查來批准這個 CL。此時他們通常會説在以後的 CL 進行整理，所以你現在應該要給 LGTM。
當然部分開發人員非常擅長這一點，並且立即送出一個修復問題的後續 CL (follow-up CL)，但根據過往經驗，這種後續「清理行為」非常少見。
除非開發者在 CL 獲得批准之後立刻進行清理動作，否則這事根本不可能發生。
這不是因為開發人員不負責任，而是因為他們可能有很多其他工作要完成，於是清理工作便會在成堆的工作中被遺忘。
因此，通常最好堅持開發人員在程式在合併進程式庫之前清理他們的 CL，因為讓人們「稍後清理」是致使程式庫健康狀況下降最常見的狀況。
如果 CL 引入了新的複雜性的話，除非是緊急情況，否則必須在提交之前將其處理掉。 如果 CL 導致暴露周圍的問題 (surrounding problems) 且現在無法解決它們的話，開發人員應該將缺陷記錄下來並分配給自己，避免後續被遺忘。 又或者他們可以選擇在程式中留下 TODO 的註釋並連結到剛記錄下的缺陷。
如果你先前以相當寬鬆的標準並轉趨嚴格的進行程式審查的話，一些開發人員會開始大聲地抱怨。一般來說，提高審查的速度會讓這些抱怨逐漸消失。 這些抱怨可能需要數個月才會消失，但最終開發人員會看到嚴格的審查所帶來的價值，因為嚴格的審查幫助他們產生的優秀程式碼。 而且一旦發生某些事情時，最大聲的抗議者甚至可能會成為你最堅定的支持者，因為他們會看到變得審核變嚴格後所帶來的價值。
如果你遵循前面所有操作，但仍然遇到無法解決的雙方之間的衝突時，請參閱 The Standard of Code Review 以獲取有助於解決衝突的準則和原則。
相關文章
- Google 如何進行 Code Review - 5
- Google 如何進行 Code Review - 4
- Google 如何進行 Code Review - 3
- Google 如何進行 Code Review - 2
- Google 如何進行 Code Review - 1
文章內容的轉載、重製、發佈，請註明出處: https://tachingchen.com/tw/
Twitter
Google+
Facebook
Reddit
LinkedIn
StumbleUpon
Pinterest
Email