前言
開發至今從來都沒有特別去了解如何好好的執行代碼審核，大家都默認會寫代碼就代表你也有能力去審核別人代碼，但我想這是一門額外的學問，因而促使我寫下這篇文章去了解如何進行代碼審核。隨著時間過去，有更多的想法我會回來編輯這篇文章慢慢解決我在代碼審核中遇到的問題……
- 要對審核的代碼理解多深？
- 審核代碼是實際的產出嗎？
- 主持一個成功的代碼審核要怎麼做？
受審者
準備好代碼審核所需的一切資訊
代碼用於實踐產品行為，而在審核如何達成目標的手段（How）之前應當充分了解為什麼（Why）要這麼做，提供完整的背景資訊可以幫助審核者更好的理解代碼目的。要求他人審核代碼之前提供必要的上下文資訊，盡量幫助審核者更有效率的進入審核的心態與環境當中：
- 規格書
- 設計稿件
- 測試環境、相關技術文件連結
更進階可以補充的資訊則像是：
- 如何切入這次代碼改動（某檔案、某片段或文件）
- 自己是如何測試並確保代碼正常運作的（透過自動化測試或至少用文字簡單描述期一下期望行為）
有時候調整 UI 相關的代碼我會一邊根據需求改動時一邊開 excalidraw 這類白板工具並截圖自己測試確保沒問題的過程，人們總是對圖像的理解更快負擔更輕。
盡可能縮小審核的規模
一個龐大的審核，不管是審核者還是被審核者都會感到無比的壓力，且專注度會直線下降。
單純注意力是每個人都有限的資源，當審核的規模擴大就意味著審核者需要騰出更多不被打擾的時間專心審核，這點並不是每個人都有辦法辦到，所以我們應該盡可能縮小審核的規模，瞄準更迅捷的迭代，並在每次小改動中也會更容易找出問題。
不過這比較偏向團隊的默契來決定如何管理，舉例像不同的版本管理策略也會影響迭代速度：完整介紹 Git 分支策略 feat. Git Flow, GitHub Flow, GitLab Flow, TBD，我自己是更為偏好快速且頻繁的的迭代，不過也還是要看團隊的習慣與產品性質來決定。
審核者
替反饋提供分級制度
在審核時應當留意我們的「目標」是達成共識並盡快結束審核，或許可以額外替反饋分級會是個好方法，例如標示：Nit(nitpick): 鑽牛角尖的小問題，可以參考就好。
為了在完美代碼與時間成本間達成平衡，我認為每次審核者都應該給出明確的界線告知被審核者「最少哪些是應該被修正才會通過審核」，真正重要的問題解決後再去看彼此有沒有多餘的時間去研究細微的問題。
盡快審核給予反饋
當審核的時間拖得越長，需要審核通過的壓力就會累積在受審者身上，相較於追求代碼品質更多時候意味著放棄重構改進代碼，而只是專注在盡可能審核通過就好。
審核者可以加快反饋速度來彌補這一問題，或是在預期沒辦法在短時間內完成審核時提前告知被審核者，這樣可以讓被審核者有心理準備去處理其他事情或找其他審核者。
風格標準
有的事情並沒有絕對的好壞，這樣的問題時常會讓審核者與被審核者產生爭執但永遠不會有明確的結果，例如語法風格、命名規則風格……等，可以在團隊中取得共識，並在之後就算有反對也要同意完全遵循規範（Disagree and commit）以將時間花費在真正重要的事情上。可以搭配自動化的 Linter 工具來審核這類風格問題，建立硬性規定。
總結
審核代碼是最直接可以發掘並改善問題的環節，主持得當的代碼審核能夠補足團隊成員間的知識盲區進而提升整體代碼水平。
- 確保程式碼的質量，從而確保了產品的品質
- 減少未來的技術債務，使維護成本更低
- 提供開發人員之間的知識共享，從而提高工作效率並提高公車指數
延伸閱讀
- The Art of Code Review - kettanaito
- Speed of Code Reviews - eng-practices
- 成為更重視 Code Review 的工程師 - Byte and Ink