原文：https://css-tricks.com/code-review-etiquette/
譯者：火山仙人掌
校對者：Miya
提示：文中的藍色字體大家可以點擊文末“閱讀原文”在 freeCodeCamp 中文論壇訪問鏈接
code review 在軟件開發中（尤其是團隊協作開發）非常重要，團隊內部有必要對於 code review 禮節達成統一意見。code review 本質是一種分析點評，而分析點評相對於寫代碼本身更加主觀。草率、研究不充分或不到位的分析會給團隊成員之間的溝通造成困難，降低團隊整體工作效率，時間長了還會降低代碼質量。這篇文章將簡要定義 code review，闡述 code review 過程中常見的錯誤，並提供改進 code review 的實用技巧。
什麼是 code review?
code review 是將代碼公開給其他工程師審查的過程。code review 可以在結對編程期間口頭進行，也可以在 CodePen 和 GitHub 等網站上進行。大部分情況下，工程師通過在 GitHub 這類工具中提交 pull requests 進行 code review。
對代碼進行分析點評極爲有益，可以召集工程師們當面交流或者（遠程）協作對代碼進行討論，以確保他們的節奏一致。此外，code review 可以幫助我們發現代碼或註釋中的小錯誤，比如拼寫錯誤，還可以幫助萌新或初級程序員學習代碼庫。如果做得好，定期的 code review 對所有參與者來說都有好處。
code review 需要代碼變更儘可能小和清晰，以便審閱者可以輕鬆瞭解代碼中有哪些更改以及做了什麼。如果 code review 的內容足夠少，則可以更頻繁地進行，可能每天幾次，而且更易於管理。
code review 應是每個開發者工作流程的一部分。在 code review 過程中，高級工程師可以進行教學、指導，甚至自己不時學習一些新東西，而初級工程師可以得到成長，並且他們提出的問題可以幫助確保代碼的可讀性。事實上，初級工程師通常是團隊中確保代碼可讀性的最佳成員。
對獨立開發者來說，當遇到人們在線下活動、GitHub、Slack 開源頻道、Reddit、Twitter 等場合展示代碼並向外界尋求反饋時，他們就有機會參與 code review 過程。
如果我們對 code review 的流程和使用的語言達成一致，那麼我們就更容易維持一個富有創造力和高工作效率的積極環境。不管是對獨立開發者還是團隊，code review 禮節對所有人都有好處。
苛刻的 code review 會降低士氣
每當我遇到 bug，或者問題不斷出現並且無法解決時，常會有挫敗感和沮喪感。對待正在進行的項目，我只看到那些消極的因素，只想着自己曾經碰到過的 bug、用詞不當和犯過的錯。這就讓我進入了一個惡性循環，因爲過於沮喪而無法繼續工作，由於不工作而更加沮喪。——Tim Wood，Momentjs 作者
網上有很多工程師發表評論、帖子和推文說 code review 傷害了他們，這並不一定是說那些評論者故意要這麼刻薄，對負面批評反饋產生自我防禦是人類本能的反應。評論者應該意識到審覈意見的語調、語氣或情緒會影響被評論者對評價原文的理解。— 參考奧卡姆剃刀原理
“這些評論的人以爲我們這些維護人員好像不是人，不會犯錯誤。” — Henry Zhu @SF (@left_pad) September 18, 2017
雖然 code review 有很多好處，但糟糕或草率的 code review 可能會產生相反的結果。避免只批評而不提供背景，換句話說，就是花些時間解釋爲什麼出了問題，哪出了問題，以及如何解決問題。體現出對被評審者的尊重可以加強團隊凝聚力，提高工程意識，並有助於統一對技術定義的理解。
快速改善 code review 的幾個建議
代碼編寫的本質就是要符合邏輯，找出不正確或可以改進的代碼就像找到拼寫錯誤一樣簡單。對待或討論某些邏輯事例（如代碼）時，容易忽視他人感受，這是人們的通病。這會造成在感情上傷害到他人，使他們無法專注學習和合作。
由於人們的這種通病，提升 code review 素養是有困難的。下面列出我曾做過、說過、看過或收到的注意事項，這些都是 code review 禮節中很容易把握的小技巧。
對事不對人
由於交流溝通中的各種人際關係，工程師們會忽視有見解的專業點評和單純的指責兩者之間存在區別。
下面剖析了一個函數的 code review 意見，建議有機會盡早 return 這個函數。
你或我： 使用”你“或”我“不會讓人覺得有意冒犯。但是，久而久之，涉及到的“你”會開始感覺不自在，尤其是在語音評述時。
你應該儘早 return 函數
我們： 用”我們“比較包容，是一個比較安全、可以更直接地表達想法的方式，而且不會讓人感到被冒犯。然而，如果是個未參與編寫代碼的外人用”我們“，這種包容聽上去就有點作假，有點麻木。
我們應該儘早 return 函數
不使用人稱指代： 沒有人稱指代，談話或點評只密切針對談論的問題、想法或 issue。
儘早 return 函數
可以看到，不用人稱代詞談論同一件事用的文字更少，更清晰。將代碼討論和個人間討論區分開，表達相同的想法需要的文字更少，也更有助於人與人之間的互動。
將富有激情的點評平和地表達出來
激情是改進的重要動力。富有激情的點評是非常重要的，可以表達對被點評者的體諒與鼓勵。只有相關的人員收到技術評論，反饋纔是最有用的。在討論架構或新產品時的交流通常就是這樣的。
只有相關的人員收到技術評論，反饋纔是最有用的。注意： 在點評的時候讓被點評者參與進來。
想象一下用誇張的肢體語言、激動的聲調、大聲地說這句話。
本次模擬中使用了 8 種網絡字體，這可能會影響頁面加載速度，或者其他潛在因素可能影響其他指標！
然後，想象一個類似的點評效果，語氣更溫和，更簡潔，以平靜、緩慢、正常的聲音表達，最後再提一個問題。
本次模擬中使用了 8 種網絡字體。由於潛在的競爭條件，這將影響頁面加載速度和其它指標。如何改善這種情況？
請注意上面的點評幾乎表達同一個意思。但第二個點評更直接，它把問題陳述爲事實，然後詢問反饋。
當滿懷熱情時，記得保持語氣平和。這種平和是通過身體語言而不是社交語言展示出來的。基於交流者的語氣，語言表達的意思可以是相同的，也可以是截然不同的。如果身體語調（肢體語言）、聲調、音高和音量保持溫和，聽話的人更有可能保持交流——即使評論本身批評性較強。
如果語氣具有攻擊性（誇張的身體運動、更激動的聲調、更高的音量），即使用的詞語原本是溫和的，聽話的人也會有非常不同的感受。這樣交流可能會導致雙方尷尬、聽話的對方不迴應，甚至失去尊重。
激情交流中說話氣勢洶洶很常見，因爲人們本能偏向於維護自己充滿激情的想法。所以，如果發現你的聽衆在討論你感興趣的事情時不感興趣，不用太擔心。關鍵是要記住，如果你能創造出可感知的溫和交流環境，即使他們最初的想法與你不一致，也會更容易保持和你積極交流。
只評議代碼，不對作者說三道四
通過上面的討論，不論在書面對話或實際肢體語言中，論語境本身轉移到某個人或某件事都不是良好溝通的最佳方式。
以下的回覆提供了評論。在 code review 本身的語境中，註釋的第二句偏離了 code review 的內容本身，這會令人非常困惑。
// 提前在函數中 return
// 你需要學習函數式編程
下面的評論提供了一個註釋，以及僞代碼建議。
/*
像這樣提前 return：
*/
const calculateStuff = (stuff) => {
if (noStuff) return
// calculate stuff
return calculatedStuff
}
在上面的兩個例子中，第一個例子讓讀者偏離了問題本身，很抽象。第二個示例直接引用問題，然後提供一個與內容相關的僞代碼片段。
code review 時，最好只對特定的上下文進行點評。寬泛的點評會喪失語境。如果必須進行更廣泛的點評，應該在 code review 之外進行。這樣就可以保持清楚地只評論代碼，並將範圍限定在被評述的代碼編程上。
對錯是可變的
開發者總是想重構。爲了解決當下的問題很自然地將問題實時分解成任務。然而，關注產品歷史的“人”和“爲什麼”，同樣對於理解產品概念很重要，因爲可以從中得知歷史背景。當你在點評別人的產品或者你的產品被點評時，要記住“歷史總會重演”。從歷史背景中總能獲得大量的信息。
JavaScript 是在一週內寫成的，當時被認爲是一種黑客腳本語言，後來卻成爲世界上使用最廣泛的編程語言。早在 1999 年就已經支持可縮放矢量圖形（SVGs）了，幾乎要被遺忘了，而現在，它因提供的新可能性而廣受歡迎。甚至萬維網（互聯網）當初只是爲了文檔共享而設計的，誰也沒有預想到會有今天的結果。當考慮軟件和工程時，所有這些技術都很重要——成功往往來自意想不到的結果，請懷抱開放的態度！
有助於提升 code review 禮節的資源和工具
Alexjs: 用來捕捉不到位、不體貼文字的工具。作者：Titus Wormer
Grammarly: 幫助改進寫作的瀏覽器插件
Write Good: 一個 cli 和文本編輯器插件，有助於改善在文本編輯器和 shells 中的寫作。作者：Brian Ford
Awesome Writing Tools: 改進寫作的工具清單。
結論
以上羅列了有助於積極參與討論、評議或閱讀代碼初階和高階的 code review 禮節。
在這篇文章中我建議不要犯的錯誤我都犯過。我不虛僞，是人都會犯錯。我的目標是幫助其他人避免再犯我曾經犯過的錯，也許鼓勵在 code review 時遵循一些行爲標準，這樣工程師就可以更公開地討論代碼，而不用擔心傷害到其他人。
❤️ 看完三件事
如果你覺得這篇內容對你挺有啓發，我想邀請你幫我三個小忙：
點個「在看」，讓更多的人也能看到這篇內容（喜歡不點在看，都是耍流氓 -_-）
關注我的博客 https://github.com/SHERlocked93/blog，讓我們成爲長期關係
關注公衆號「前端下午茶」，持續爲你推送精選好文，也可以加我爲好友，隨時聊騷。
在看點這裏
