[工程師日程] Code Review程式碼審查要點
本篇文章屬個人見解，若有錯誤部分或不同見解，請不吝指教
概要
工程師日常生活中除了寫Code、設計架構等等之外，還有很重要的其中一環就是Review團隊成員的程式碼，也就是Code Review。
那Code Review的時候，我們主要需要Review哪些要點呢？以下將以Pull Request本身觀點及程式碼觀點來做說明。
Pull Request本身觀點
Pull Request本身所含資訊是否足夠
Pull Request本身裡面所含的資訊，是否足夠能讓Reviewer能夠理解這個Pull Request所要新增的功能或是所要解決的問題。
個人建議使用Template來規範，這樣成員發Pull Request的時候，自動就有Template，提出者就照個Template填好資料即可。正常內容會包含：主旨、修改前後畫面截圖、相關連結等等。
Github Template範本可參考：https://github.com/FlyRayTsou/template-pull-request/blob/v1.0.0/.github/PULL_REQUEST_TEMPLATE.md
延伸閱讀：Creating a pull request template for your repository
Pull Request所包含修正的內容是否過多
若是一個Pull Request包含的修正內容過多，其實則不方便被Review，原則上一個Pull Request所包含的修正內容以一個主題為主。若包含過多主題則可能會被Reviewer退回，會被要求分割成多個Pull Request再重發一次。
Commit資訊
每一個Commit的基本上就是要能表達一個完整的意義。有些人會一個一個commit看，來進行Code Review。
另外，儘管有些公司可能沒有規範commit標題及敘述的記述方式。在有規範commit的記述的前提下，可補充相關參考資訊及採用該commit作法的原因或想法。若需記錄的內容過多則可記錄在對應的專案管理系統的Ticket。
程式碼觀點
是否符合需求(meet requirement)：
最基本需要確認的是寫的code是否有符合所要需求。Reviewer會從Pull Request的資訊來了解需求，並去Review代碼。
譬如說今天我們在做一個流程審核系統，我們的需求是有管理者權限的使用者才可以操作審核通過按鈕，那我們則就要確認程式碼的邏輯是否正確。
是否好維護(Maintainability)
譬如說寫的function是否太大等等，未來是否可以再利用或是擴充，但是要記得不要overdesign，所以要在可預見的未來內的想法。同時也要注意是否有足夠的測試程式碼。
是否容易讀(Readability)
譬如說變數、函數的命名是否恰當。
是否有做好例外處理(Error Handling、Edge Case)
像是包含後面幾個例子『是否有針對例外做處理以及是否有想足各種edge case』、『是否有處理multi-thread case』、『關注用到的class是否是thread-safe』。
是否為可接受的複雜度(Time Complexity、Space Complexity)
譬如說，程式處理邏輯是否會造成高的時間複雜度像是O(N²)。此種情況時可思考，是否可以有辦法可以降低時間複雜度。例如說先整理資料後，再進行邏輯處理的部分，讓時間複雜度可以降低至O(N)。
自動化檢查的部分
正常會設定CI來自動檢查coding style、測試程式碼是否通過及其他品質檢測（例如：SonarQube）。若有一項沒通過，則代表程式碼可能有問題。需要再次修改後，再次提出。
總結
寫這篇文章主要是紀錄自己目前做Code Review時，會關注哪些點，在日常工作時，也可以參考這篇文章來做Code Review。
並且，未來回頭看自己時，也可以比較是否因為成長及經驗的不同，而有了不同的看法。
最後，Google也有公開他們的Code Review指導原則，有興趣的人也可以去閱讀。
文章內的常用單字中英文對照
實際工作職場上，每一家公司的內部溝通語言不同，大致上來說就是中文跟英文兩種，以下列出相對應字詞，方便大家對照。
- Code：程式碼、代碼
- Code Review、Pull Request Review、Merge Request Review：代碼審查、程式碼審查
- Review：審查
- Reviewer：審查者
- Ticket：工單
- Team member、Member：團隊成員
- Template：範本
