Code Review 怎麼做？新手工程師如何提升「程式碼品質」

程式碼的持續優化

對一個入門的工程師來說，掌握程式語法與模仿範例實作是基本的能力。那有了這樣的基本能之後，要如何寫出更好的程式呢？怎樣才能夠成為一個「優秀」的新手工程師呢？事實上，寫出會動的程式不難，但想寫出好的程式其實是需要刻意練習的。大部分的人會建議要「多練習、多實作」，但我認為在大量練習之外，適時的「優化程式」也是提升「程式碼品質」重要的關鍵。而在「優化程式」可以分成兩個角度：

1. 程式執行效能更好
2. 程式碼結構更精簡

程式執行效能就是從速度跟空間來思考，執行時間越短、變數佔用空間越小。而程式碼結構則會從可讀性和精簡來衡量，例如：變數的命名有沒有意義、程式碼有沒有冗余、繁瑣的部分等等。只不過新手很容易停留在寫出程式的喜悅以及受到固有的解題思考，而忽略優化的過程。

透過「Code Review」是推薦新手的方法，經由反饋與討論來找出程式中可優化的空間。

Code Review 的關注點

以我自己的經驗來說，Review 一份專案的時候會關注：

1. 程式能不能正常操作，有没有什么明显的错误？（低標）
2. 程式碼當中有沒有奇怪的地方？（優化）

第一個關注點是程式碼的低標，結果正確與可正常運行一定是最重要的。如果程式無法運行動或存在很明顯的問題，那再多的優化都沒有意義。除了確保執行之外，同時也會檢查一下是否有低級的邏輯失誤或是安全性的疑慮，像是資料庫沒有正確關閉或密碼明碼沒有加密之類的問題。

第二個關注點是「程式碼品質提升」的部分，我會把它定義成程式運作上沒有問題，但看起來很不舒服或執行效率很差的部分。大致上可以從以下幾點下手：

1. 命名有沒有意義/不一致
2. 資料庫的正規化情況
3. 是否存在特別複雜的程式片段（例如多次的資料庫查詢、多層的迴圈使用）
4. 重複的程式碼有沒有定義成 function
5. 冗長的程式碼能不能拆分成 function

不過一次的 Code Review 建議著重在 3 - 5 個優化地方，比較容易聚焦在優化的品質。根據時程的壓力，決定 Code Review 迭代的次數。

從架構的規劃到細節的優化

在拿到一份程式碼時，通常會先掃過一眼程式的檔案結構，是否有不該上傳的檔案或缺漏。

以這個例子來說，第一眼會覺得檔案配置蠻結構化的。但再多看一點會發現存在幾個冗餘的檔案，例如：-filesqqqq、diff，甚至 /icon 資料夾也不該放在最上層。

進入程式的第一步先從 package.json 檔案開始，確認一下專案的基本資訊是否完整、使用到的套件與版本，以及程式的進入點是什麼。然後打開進入點的檔案（通常會命名成 app 或 main），通常有幾個點需要注意：「套件的載入順序」會建議從第三方套件 → 自定義的模組 → 程式內的變數這樣順序定義；「善用 MVC 的架構」將非主程式的部分依照功能拆分模組，避免檔案資訊量太雜亂。接著就會從 Router → Controller → Service → View 的流程一個一個功能，以下分享一些存在優化空間的程式碼：

1. 善用工具，已有的工具，不用自己手刻
2. 變數名稱不建議用大寫開頭（通常是用在 Class 的命名）
3. 保持優化的空間與彈性

「優化其實是一種取捨」，不需要也不應該追求一步到位。開發往往都是在品質跟產出做取捨，初期可以把開發目標放在「先求可以動，再求持續優化」的節奏上。新手需要在意的點有幾下兩點：

1. 很容易把重點全部放在程式碼的產出上而忽略的程式碼的品質。
2. 停留在做出成果的喜悅，而停滯了優化的步調。

因此，會建議在開發當下就「多想」兩秒鐘，感覺可優化但來不及的部分先在旁邊加個註解提醒自己。另外也養成一段時間回頭看之前的程式碼的習慣，試著刻意找出可以優化改進的部分。專案的提交可能會有期限，但程式碼的優化沒有盡頭。面對相同的專案與程式碼，唯有透過不停的迭代優化才能打造更好的程式，同時也見證了你和程式一起變得更好的過程。所以建立逐步優化的空間，養成持續提升程式碼品質的習慣，才是一個新手工程師需要修煉的心法。