程式碼的持續優化
對一個入門的工程師來說，掌握程式語法與模仿範例實作是基本的能力。那有了這樣的基本能之後，要如何寫出更好的程式呢？怎樣才能夠成為一個「優秀」的新手工程師呢？
事實上，寫出會動的程式不難，但想寫出好的程式其實是需要刻意練習的。大部分的人會建議要「多練習、多實作」，但我認為在大量練習之外，適時的「優化程式」也是提升「程式碼品質」重要的關鍵。而在「優化程式」可以分成兩個角度：
- 程式執行效能更好
- 程式碼結構更精簡
程式執行效能就是從速度跟空間來思考，執行時間越短、變數佔用空間越小。而程式碼結構則會從可讀性和精簡來衡量，例如：變數的命名有沒有意義、程式碼有沒有冗余、繁瑣的部分等等。只不過新手很容易停留在寫出程式的喜悅以及受到固有的解題思考，而忽略優化的過程。
透過「Code Review」是推薦新手的方法，經由反饋與討論來找出程式中可優化的空間。
在 ALPHA Camp 的課程規劃中有一個為期兩週的專案練習，內容會以「復刻 Twitter 社群網站」為目標，當中會以團隊協作與自動化測試形式開發。而我在擔任 ALPHA Camp 學期三助教期間，剛好有機會對於這個專案給予 Code Review 的建議，過程中也歸納出幾個給新手的重點筆記。
點我免費領取非本科轉職工程師指南！
Code Review 的關注點
以我自己的經驗來說，Review 一份專案的時候會關注：
- 程式能不能正常操作，有沒有什麼明顯的錯誤？ ← 低標
- 程式碼當中有沒有奇怪的地方？ ← 優化
第一個關注點是程式碼的低標，結果正確與可正常運行一定是最重要的。如果程式無法運行動或存在很明顯的問題，那再多的優化都沒有意義。除了確保執行之外，同時也會檢查一下是否有低級的邏輯失誤或是安全性的疑慮，像是資料庫沒有正確關閉或密碼明碼沒有加密之類的問題。
第二個關注點是「程式碼品質提升」的部分，我會把它定義成程式運作上沒有問題，但看起來很不舒服或執行效率很差的部分。大致上可以從以下幾點下手：
- 命名有沒有意義/不一致
- 資料庫的正規化情況
- 是否存在特別複雜的程式片段（例如多次的資料庫查詢、多層的迴圈使用）
- 重複的程式碼有沒有定義成 function
- 冗長的程式碼能不能拆分成 function
不過一次的 Code Review 建議著重在 3 – 5 個優化地方，比較容易聚焦在優化的品質。根據時程的壓力，決定 Code Review 迭代的次數。
主管和老闆怎麼看你的 code？業界需要怎樣的工程師？聽聽 foodpanda 怎麼說
從架構的規劃到細節的優化
在拿到一份程式碼時，通常會先掃過一眼程式的檔案結構，是否有不該上傳的檔案或缺漏。
以這個例子來說，第一眼會覺得檔案配置蠻結構化的。但再多看一點會發現存在幾個冗餘的檔案，例如：-filesqqqq、diff，甚至 /icon 資料夾也不該放在最上層。
進入程式的第一步先從 package.json 檔案開始，確認一下專案的基本資訊是否完整、使用到的套件與版本，以及程式的進入點是什麼。然後打開進入點的檔案（通常會命名成 `app` 或 `main`），通常有幾個點需要注意：「套件的載入順序」會建議從第三方套件 → 自定義的模組 → 程式內的變數這樣順序定義；「善用 MVC 的架構」將非主程式的部分依照功能拆分模組，避免檔案資訊量太雜亂。接著就會從 Router → Controller → Service → View 的流程一個一個功能，以下分享一些存在優化空間的程式碼：
分頁的功能可以善用工具，不用自己手刻
資料庫的可以利用關聯查詢
變數名稱不建議用大寫開頭（通常是用在 Class 的命名）
保持優化的空間與彈性
「優化其實是一種取捨」，不需要也不應該追求一步到位。開發往往都是在品質跟產出做取捨，初期可以把開發目標放在「先求可以動，再求持續優化」的節奏上。新手需要在意的點有幾下兩點：
- 很容易把重點全部放在程式碼的產出上而忽略的程式碼的品質。
- 停留在做出成果的喜悅，而停滯了優化的步調。
因此，會建議在開發當下就「多想」兩秒鐘，感覺可優化但來不及的部分先在旁邊加個註解提醒自己。另外也養成一段時間回頭看之前的程式碼的習慣，試著刻意找出可以優化改進的部分。專案的提交可能會有期限，但程式碼的優化沒有盡頭。面對相同的專案與程式碼，唯有透過不停的迭代優化才能打造更好的程式，同時也見證了你和程式一起變得更好的過程。所以建立逐步優化的空間，養成持續提升程式碼品質的習慣，才是一個新手工程師需要修煉的心法。
