目錄

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

程式碼的持續優化

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

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

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

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

Code Review 的關注點

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

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

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

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

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

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

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

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

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

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

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

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

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

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