作為開源項目的積極貢獻者，我發現處理代碼評審問題是一件很浪費時間的事情，特別是當代碼評審帶有負面、主觀或爭論性的東西時。當項目維護者不喜歡貢獻者提交的代碼，經常會出現這種情況。在最好的情況下，這種代碼評審策略會導致無意義的爭論。在最壞的情況下，它會阻礙項目貢獻，形成一個充滿敵意和精英主義的文化。

代碼評審應該是客觀和簡潔的，并盡可能面向確定性。代碼評審不是關于政治或情感上的爭論，而是一個技術問題。代碼評審的目標應該是不斷進取，提升項目及其參與者的水平。提交的代碼應該根據代碼的優點而不是對提交者的意見來評判。

代碼評審策略

以下是一些代碼評審策略，作為項目維護者，如果你看到不喜歡的代碼，可以嘗試應用這些評審策略。

1.把拒絕變成問問題

糟糕的評審：“如果你這樣改，就不可能……”。(這顯然有點夸張，真的不可能嗎?)好的評審：“如果你這樣改，那該怎么……?”

2.避免夸大其詞

簡單一點，把你的顧慮和問題說出來，這樣有助于你獲得期望的結果。

糟糕的評審：“這個變更對性能影響很大。”好的評審：“這樣改的話性能會比之前低一些，你有做過測試嗎?”更好的評審：“我會準備一些數據來驗證一下這樣改之后速度不會比之前慢。”或者這樣：“這個變更把之前的O(n)變成了O(n2)，不會影響性能嗎?”

3.把帶有諷刺意味的評語留給你自己

有些想法最好把它爛在肚子里，如果你不想讓人覺得你粗魯，最好不要把這些想法說出來。

“我覺得這個變更太糟糕了，它會毀了所有東西的。”“你真的覺得軟件工程這個行業適合你呆下去嗎?”

4.積極參與

對于同一個問題，或許你會有不同的想法。如果你能夠積極參與，可能會得到比之前更好的解決方案。

糟糕的評審：“這個想法太糟糕了，我有更好的解決方案。”好的評審：“對于這個問題我也有一些類似的想法，或許我們可以比較或者組合一下我們的想法。”或者：“我也有一些類似的想法，我這樣做是因為……而你那么做是因為什么?”

5.不是每個人的經歷都跟你一樣

有些東西對你來說是常識，但有些人可能并不知道，即使他們的能力并不差。你可以說這些東西是常識，但不要顯露出嘲笑或高人一等的姿態。

糟糕的評審：“你不知道這個明顯是錯的嗎?”好的評審：“這樣是不對的，因為當……的時候它會拋出空指針異常。”

6.不要把復雜的東西簡單化

有些事情對你來說是顯而易見的，但對其他人并不一定也是這樣。為別人提供可選方案或有用的例子可以讓他們也變得跟你一樣好。

糟糕的評審：“為什么不直接這樣?”好的評審：“這樣做會更簡單，比如……”

7.尊重別人

有時候，提交的代碼可能質量很差，但表示一下對別人的尊重其實很容易。

糟糕的評審：“這些愚蠢的代碼人跟寫代碼的人一樣愚蠢。”好的評審：“感謝你提交的代碼，但我們不能接受它們，因為有一些問題(已經列出來了)。”或者：“代碼有一些問題，已經列出來了。或許我們可以回退一步，一起討論一下用例?這樣可以幫我們往前進一步。”

8.管理你的期望和時間

如果一次提交的代碼太多，你沒有時間評審，可以讓提交者知道。

糟糕的評審：“代碼太多了，我不會合并它們的。”同樣糟糕的是直接忽略它們。好的評審：“可以把這些分成幾次提交嗎?我沒有這么多時間，而且一次也評審不了這么多代碼。”

9.使用禮貌用語

使用禮貌用語(比如“請”)表示對代碼提交者的尊重，特別是當你要他們在細節上做出一些調整(比如格式化)時。

“請你把與空格相關的變更放在單獨的PR里，可以嗎?”“請你把變量對齊，這樣更容易閱讀，可以嗎?”

10.開啟對話

你可能照著上面所說的去做了，但對提交的代碼仍然不滿意。這個時候你可以這么說：“我不喜歡這段代碼，但我也不知道為什么，我們可以聊聊嗎?”盡管需要多花一點時間，但這樣是值得的，因為這樣你和對方都能學到東西(一個講一個聽)，而不是變成對立方。

即使是很有經驗的程序員也可以這么說：“我也不知道為什么不喜歡這段代碼”。這不是在創造攻擊代碼評審人員的機會，而是打開一條共同求知的道路。

總結

避免使用雙關語或夸大其詞，避免爭論，避免精英主義或貶低他人，避免諸如“顯而易見”和“你為什么不……”這樣的評語。使用清晰、真實的陳述和支持性的語言，提出問題，推動事情向前發展。記住，同事和代碼貢獻者都是人，他們的付出和你的付出一樣值得尊重。

轉載丨DavidLloyd