如何寫代碼審覈評論
概述
- 友善一些
- 清楚的闡述你的理由
- 要在清楚地給出方向和指出問題後讓開發者自己決定之間做好平衡
- 鼓勵開發者簡化代碼或者添加說明，而不是解釋代碼爲什麼這麼複雜
禮貌
通常當你在審覈別人的代碼時，友善、尊重、提供清晰、有效的意見對於開發者是非常重要的。做到這個的方法是在評論中只針對代碼，而不是開發者。你不一定需要一直按照推薦實踐來操作，但是當你說一些負面的或者有爭議的意見時一定要按照規範來。例如：
錯誤：“爲什麼你在這種明顯不需要併發的場景使用多線程呢？”
正確：“在這裏使用併發只是增加了系統的複雜度我卻沒有發現任何實際的性能提升。因爲沒有性能提升，在這裏最好使用單線程而不是多線程。”
解釋原因
你發現剛纔“正確”的例子中，能夠幫助開發者理解爲什麼你要寫下那些評論，有時候你要對你的目的做多一些解釋，比如你遵循的最佳實踐，或者你對於提升代碼質量的一些建議
提供指導
通常修復變更提交是開發者的責任而不是審覈者。作爲審覈者你不應該進行解決方案的詳細設計或者幫助開發者編碼。
但這並不意味着審覈者不應提供任何幫助，儘管你要合理的掌握指出問題和直接提供解決方案之間的平衡。單單指出問題並且讓開發者自己做出決定一般能夠幫助其成長，審覈行爲也會更加簡單。通常也會產生好的結果，因爲開發者比審覈者更理解代碼和需求。
然而有時候直接的說明、建議、甚至代碼會更有幫助。畢竟代碼審覈的目的就是使得提交的內容是最優的。第二目標纔是提高開發者的技能，今後的審覈能夠更加快捷。
接受解釋說明
當你要求開發者說明一塊你無法理解的代碼時，通常最終會要求開發者將代碼重寫得更加清晰。偶爾情況下，在代碼中添加註釋也是一個很好的回覆，只要不是解釋一塊過於複雜的代碼。
說明只寫在代碼審覈工具中對於今後閱讀代碼的人並不是很有幫助。這在某些情況下纔可以接受，例如你正在審覈一個比較不熟悉的功能，開發者嘗試給你解釋一些其他大部分審覈者都已經瞭解的內容。
下一篇：如何處理代碼審覈中的負面反饋