如何做到正向循環的 Code Review ?

其實不少大神都有寫過如何進行 Code review 或類似的文章，不過我還是想藉著自身的經驗總結一遍。 通常會需要你 Code review 就代表你對 Codebase 或者程式設計的功力已經有相當程度的熟悉了（是的，能力越大，責任越大）！

但是 Code review 並不是霹哩啪拉給個幾條意見，然後就打完收工的事，歸根究底它多少還是牽扯人際關係的互動，這就是程式設計師的江湖。

闖江湖不免要來幾條規矩：

• 開宗明義，用批評摧毀團隊很快很簡單，但是團隊要建立互信與默契卻是需要長期的經營
• Code review 要具備同理心、Code review 要具備同理心、Code review 要具備同理心！別人也是花時間寫的程式碼，初衷也是想要達成規定的功能與目標，沒有人想被批抨得一文不值，你們都是為了產品好，只是想法與做法不同而已，請用實質的建議取代批評
• 內心要認知一件事——「 PR 的作者對規格/程式碼相關情境的了解，應該在 Reviewer 之上」，也就是說作者對於程式碼中存在的缺點以及妥協應該都相當了解，如果有覺得奇怪的地方，可以先詢問作者是否有任何考量，再進行後續討論
• Code review 不是把別人的 PR(Pull Request) 變成你喜歡的樣子，也不是炫耀火力，千萬別不順眼就拔刀拔槍要相殺， Code review 的目的在於：
  1. 讓經驗可以透過互動方式在成員間流轉
  2. 避免致命錯誤被送到 Production 造成團隊困擾（人人都想開開心心上班，準準時時下班）
  3. 維持 Codebase 一定程度的整潔，避免大家像在玩疊疊樂，誰倒楣誰當壓垮疊疊樂的最後 1 根積木
• Code review 如果有爭執，請用數據說明，譬如效能不好的地方請用 profiling 說服作者，或者有 best practices 也請提供文件或出處，給彼此 1 個教學相長的機會
• Comment 的文字會容易被誤解情緒，你可能文字表達沒有任何情緒，但是讀者容易誤解其中情緒，最好的方法是雙方可以再 face to face 快速講解 1 遍（有默契之後，幾乎就可以不需要這步驟），或者善用 emoji 輔助表達文字情緒，避免被誤解
• Code review 留的 comment 可以加上標籤表達是建議還是要求，例如 [Optional] , [Suggestion] , [FYI] , 因為有些無傷大雅的更動可以讓作者在趕時間的情況下先忽略（而且作者本來就沒有義務接受所有不合理的要求⋯⋯）
• 別吝嗇給稱讚，看到好的地方請大方留下稱讚，稱讚可以給人帶來自信，激發更多創意，好稱讚，不稱讚嗎？

基本上，只要做到這些應該就能夠來一場溫馨快樂又有內容的 Code Review 囉！

一起成為人人都喜歡的 Reviewer 吧～！😎