如果你喜歡這內容的話幫我在 Twitter 和 Threads 上面分享給其他正在前端這條路上努力的朋友們，也別忘了訂閱我們電子報收到第一手消息喔 🚀
在軟體開發的快速節奏中，確保 code 的質量、安全性和可維護性比以往任何時候都更加重要。除了寫測試以外，code review 是個朝這個目標實現的一種過程，code reviews 不僅有助於捕捉錯誤和提高 code 質量，還能促進團隊內的知識共享和合作。
其他更熟悉技術的工程師可以幫助識別你未曾想到的潛在錯誤，多幾雙眼睛檢查你可能遺漏的 case，寫 unit case 也只能檢查我們自己想得到的 case 但開 PR 和其他人集思廣益看看還遺漏了什麼。如果你正在嘗試的解決方案曾經嘗試過但未能取得成效，這也是一個很好的討論機會，雖然在開 PR 之前應該有很多機會可以討論但 PR 算是整個 funnel 最後給大家討論的機會。
Reviewers 這時候也會檢查 code style 有沒有一致或是否遵守 code guidelines，其中很多東西可以用 linters 幫忙做自動檢查但有寫 function 和架構還是需要人工檢查。
代碼審查中的 PR 可以用於作者和 reviewer 之間的知識共享。作者可以以 PR 的形式分享他們的想法，作為其他成員審查的 RFC 或作為其他團隊的參考。如果你不想寫文件，某些時候你可以用 PR 來代替。對於reviewer 來說，你也可能提供見解或提出其他解決方案，因為你可能對技術、庫或整個 code 庫更了解。
進行 code reviews 還為你提供了一個機會來指導初級工程師，幫助他們寫出更好的 code，並快速上手。你可以提供改進建議或討論他們為什麼這樣做。
每個人都有不同的經歷和思維過程。他們會根據他們擁有的信息和知識做出決定。作為 reviewer，如果你認為有更好的方法來，重點關注和討論 code、架構或設計，而不要針對開發者。解釋你的思考過程，邀請作者表達他們的想法，禮貌和善意地進行，以促進正向的文化。
提供反饋時，儘量明確並給出可操作的建議，而不是說「這不好」或「我們不應該這樣做」。為了指導他人，你應該給出可以改進的方向。
一些 feedback example：
• 「我建議我們將這個變量命名得更具描述性，例如將 x 改為 transaction。」
• 「這個函數包含多個邏輯和條件。我們是否應該將其分解以提高可測試性和可讀性？」
• 「看起來這個組件沒有處理加載和錯誤狀態。添加它們可能會改善用戶體驗。」
這有點文鄒鄒的但大概意思是這樣，可以寫的更白話一點。
這主要針對 PR 作者，但作為reviewer，如果 PR 改動的範圍太大你可以建議將 PR 縮小以便更容易 review，較小的 PR 可以讓 review 的人快速理解上下文並將範圍保持在可管理的範圍內，這應該有助於更快地 merge PR 而不是一直在那邊沒有人看。
在某些情況下，使用任何技術或庫都是可以的，但人們可能有自己偏好的意見。儘量讓你的 review 和反饋客觀，減少 review 過程中的個人偏見。我們希望改進 code，而不是僅僅只是因為某個特定的人的想法改進。在整個過程中，reviewer 應鼓勵雙方的合作和討論，這有助於促進創造一個更友善的環境和團隊文化。