作為開源專案的積極貢獻者，我發現處理程式碼評審問題是一件很浪費時間的事情，特別是當代碼評審帶有負面、主觀或爭論性的東西時。當專案維護者不喜歡貢獻者提交的程式碼，經常會出現這種情況。在最好的情況下，這種程式碼評審策略會導致無意義的爭論。在最壞的情況下，它會阻礙專案貢獻，形成一個充滿敵意和精英主義的文化。
程式碼評審應該是客觀和簡潔的，並儘可能面向確定性。程式碼評審不是關於政治或情感上的爭論，而是一個技術問題。程式碼評審的目標應該是不斷進取，提升專案及其參與者的水平。提交的程式碼應該根據程式碼的優點而不是對提交者的意見來評判。
程式碼評審策略
以下是一些程式碼評審策略，作為專案維護者，如果你看到不喜歡的程式碼，可以嘗試應用這些評審策略。
1. 把拒絕變成問問題
糟糕的評審：“如果你這樣改，就不可能……”。(這顯然有點誇張，真的不可能嗎?)好的評審：“如果你這樣改，那該怎麼……?”
2. 避免誇大其詞
簡單一點，把你的顧慮和問題說出來，這樣有助於你獲得期望的結果。
糟糕的評審：“這個變更對效能影響很大。”好的評審：“這樣改的話效能會比之前低一些，你有做過測試嗎?”更好的評審：“我會準備一些資料來驗證一下這樣改之後速度不會比之前慢。”或者這樣：“這個變更把之前的 O(n) 變成了 O(n2)，不會影響效能嗎?”
3. 把帶有諷刺意味的評語留給你自己
有些想法最好把它爛在肚子裡，如果你不想讓人覺得你粗魯，最好不要把這些想法說出來。
“我覺得這個變更太糟糕了，它會毀了所有東西的。”“你真的覺得軟體工程這個行業適合你呆下去嗎?”
4. 積極參與
對於同一個問題，或許你會有不同的想法。如果你能夠積極參與，可能會得到比之前更好的解決方案。
糟糕的評審：“這個想法太糟糕了，我有更好的解決方案。”好的評審：“對於這個問題我也有一些類似的想法，或許我們可以比較或者組合一下我們的想法。”或者：“我也有一些類似的想法，我這樣做是因為……而你那麼做是因為什麼?”
5. 不是每個人的經歷都跟你一樣
有些東西對你來說是常識，但有些人可能並不知道，即使他們的能力並不差。你可以說這些東西是常識，但不要顯露出嘲笑或高人一等的姿態。
糟糕的評審：“你不知道這個明顯是錯的嗎?”好的評審：“這樣是不對的，因為當……的時候它會丟擲空指標異常。”
6. 不要把複雜的東西簡單化
有些事情對你來說是顯而易見的，但對其他人並不一定也是這樣。為別人提供可選方案或有用的例子可以讓他們也變得跟你一樣好。
糟糕的評審：“為什麼不直接這樣?”好的評審：“這樣做會更簡單，比如……”
7. 尊重別人
有時候，提交的程式碼可能質量很差，但表示一下對別人的尊重其實很容易。
糟糕的評審：“這些愚蠢的程式碼人跟寫程式碼的人一樣愚蠢。”好的評審：“感謝你提交的程式碼，但我們不能接受它們，因為有一些問題(已經列出來了)。”或者：“程式碼有一些問題，已經列出來了。或許我們可以回退一步，一起討論一下用例?這樣可以幫我們往前進一步。”
8. 管理你的期望和時間
如果一次提交的程式碼太多，你沒有時間評審，可以讓提交者知道。
糟糕的評審：“程式碼太多了，我不會合並它們的。”同樣糟糕的是直接忽略它們。好的評審：“可以把這些分成幾次提交嗎?我沒有這麼多時間，而且一次也評審不了這麼多程式碼。”
9. 使用禮貌用語
使用禮貌用語(比如“請”)表示對程式碼提交者的尊重，特別是當你要他們在細節上做出一些調整(比如格式化)時。
“請你把與空格相關的變更放在單獨的 PR 裡，可以嗎?”“請你把變數對齊，這樣更容易閱讀，可以嗎?”
10. 開啟對話
你可能照著上面所說的去做了，但對提交的程式碼仍然不滿意。這個時候你可以這麼說：“我不喜歡這段程式碼，但我也不知道為什麼，我們可以聊聊嗎?”儘管需要多花一點時間，但這樣是值得的，因為這樣你和對方都能學到東西(一個講一個聽)，而不是變成對立方。
即使是很有經驗的程式設計師也可以這麼說：“我也不知道為什麼不喜歡這段程式碼”。這不是在創造攻擊程式碼評審人員的機會，而是開啟一條共同求知的道路。
總 結
避免使用雙關語或誇大其詞，避免爭論，避免精英主義或貶低他人，避免諸如“顯而易見”和“你為什麼不……”這樣的評語。使用清晰、真實的陳述和支援性的語言，提出問題，推動事情向前發展。記住，同事和程式碼貢獻者都是人，他們的付出和你的付出一樣值得尊重。
作為開源專案的積極貢獻者，我發現處理程式碼評審問題是一件很浪費時間的事情，特別是當代碼評審帶有負面、主觀或爭論性的東西時。當專案維護者不喜歡貢獻者提交的程式碼，經常會出現這種情況。在最好的情況下，這種程式碼評審策略會導致無意義的爭論。在最壞的情況下，它會阻礙專案貢獻，形成一個充滿敵意和精英主義的文化。
程式碼評審應該是客觀和簡潔的，並儘可能面向確定性。程式碼評審不是關於政治或情感上的爭論，而是一個技術問題。程式碼評審的目標應該是不斷進取，提升專案及其參與者的水平。提交的程式碼應該根據程式碼的優點而不是對提交者的意見來評判。
程式碼評審策略
以下是一些程式碼評審策略，作為專案維護者，如果你看到不喜歡的程式碼，可以嘗試應用這些評審策略。
1. 把拒絕變成問問題
糟糕的評審：“如果你這樣改，就不可能……”。(這顯然有點誇張，真的不可能嗎?)好的評審：“如果你這樣改，那該怎麼……?”
2. 避免誇大其詞
簡單一點，把你的顧慮和問題說出來，這樣有助於你獲得期望的結果。
糟糕的評審：“這個變更對效能影響很大。”好的評審：“這樣改的話效能會比之前低一些，你有做過測試嗎?”更好的評審：“我會準備一些資料來驗證一下這樣改之後速度不會比之前慢。”或者這樣：“這個變更把之前的 O(n) 變成了 O(n2)，不會影響效能嗎?”
3. 把帶有諷刺意味的評語留給你自己
有些想法最好把它爛在肚子裡，如果你不想讓人覺得你粗魯，最好不要把這些想法說出來。
“我覺得這個變更太糟糕了，它會毀了所有東西的。”“你真的覺得軟體工程這個行業適合你呆下去嗎?”
4. 積極參與
對於同一個問題，或許你會有不同的想法。如果你能夠積極參與，可能會得到比之前更好的解決方案。
糟糕的評審：“這個想法太糟糕了，我有更好的解決方案。”好的評審：“對於這個問題我也有一些類似的想法，或許我們可以比較或者組合一下我們的想法。”或者：“我也有一些類似的想法，我這樣做是因為……而你那麼做是因為什麼?”
5. 不是每個人的經歷都跟你一樣
有些東西對你來說是常識，但有些人可能並不知道，即使他們的能力並不差。你可以說這些東西是常識，但不要顯露出嘲笑或高人一等的姿態。
糟糕的評審：“你不知道這個明顯是錯的嗎?”好的評審：“這樣是不對的，因為當……的時候它會丟擲空指標異常。”
6. 不要把複雜的東西簡單化
有些事情對你來說是顯而易見的，但對其他人並不一定也是這樣。為別人提供可選方案或有用的例子可以讓他們也變得跟你一樣好。
糟糕的評審：“為什麼不直接這樣?”好的評審：“這樣做會更簡單，比如……”
7. 尊重別人
有時候，提交的程式碼可能質量很差，但表示一下對別人的尊重其實很容易。
糟糕的評審：“這些愚蠢的程式碼人跟寫程式碼的人一樣愚蠢。”好的評審：“感謝你提交的程式碼，但我們不能接受它們，因為有一些問題(已經列出來了)。”或者：“程式碼有一些問題，已經列出來了。或許我們可以回退一步，一起討論一下用例?這樣可以幫我們往前進一步。”
8. 管理你的期望和時間
如果一次提交的程式碼太多，你沒有時間評審，可以讓提交者知道。
糟糕的評審：“程式碼太多了，我不會合並它們的。”同樣糟糕的是直接忽略它們。好的評審：“可以把這些分成幾次提交嗎?我沒有這麼多時間，而且一次也評審不了這麼多程式碼。”
9. 使用禮貌用語
使用禮貌用語(比如“請”)表示對程式碼提交者的尊重，特別是當你要他們在細節上做出一些調整(比如格式化)時。
“請你把與空格相關的變更放在單獨的 PR 裡，可以嗎?”“請你把變數對齊，這樣更容易閱讀，可以嗎?”
10. 開啟對話
你可能照著上面所說的去做了，但對提交的程式碼仍然不滿意。這個時候你可以這麼說：“我不喜歡這段程式碼，但我也不知道為什麼，我們可以聊聊嗎?”儘管需要多花一點時間，但這樣是值得的，因為這樣你和對方都能學到東西(一個講一個聽)，而不是變成對立方。
即使是很有經驗的程式設計師也可以這麼說：“我也不知道為什麼不喜歡這段程式碼”。這不是在創造攻擊程式碼評審人員的機會，而是開啟一條共同求知的道路。
總 結
避免使用雙關語或誇大其詞，避免爭論，避免精英主義或貶低他人，避免諸如“顯而易見”和“你為什麼不……”這樣的評語。使用清晰、真實的陳述和支援性的語言，提出問題，推動事情向前發展。記住，同事和程式碼貢獻者都是人，他們的付出和你的付出一樣值得尊重。