工程化的定義
當網站架構越來越複雜後，就需要一些工作方法或研究方法，讓大家工作時有所依循。
這就像是：假設你想學一些東西，自己自學跟去研究所學，學習的速度、深度、廣度一定不是同一個量級。
為什麼需要工程化？
換個角度思考：
- 網路出現的時間不過是近 20 年的事
- 現代網頁開發結構也都是近 10 年的東西
所以一直有人在提出：如何整理這些複雜、常用、常見的資料分類，並且讓它可以永續使用。
沒有工程化 vs 有工程化：一個真實場景
你有沒有想過，為什麼有些專案接手的時候讓人想翻桌？
想像一下這個場景 — 你加入一個新公司，打開前人留下來的專案：
沒有工程化的專案：
- 沒有 README，不知道怎麼啟動
- CSS 全部寫在一個
style.css裡面，3000 行 - JavaScript 直接寫在 HTML 的
<script>裡 - 不知道哪些檔案還有在用、哪些是廢棄的
- 問同事「這個怎麼部署？」答案是「你 SSH 進去然後手動拉 code」
有工程化的專案：
README.md清楚寫了啟動步驟- 有統一的資料夾結構（components、pages、utils）
- 有 ESLint + Prettier 確保程式碼風格一致
- 有 CI/CD pipeline，push 到 main 就自動部署
- 有 code review 流程，每個 PR 都有人看過
對吧？差別非常明顯。工程化不是什麼高深的理論，它就是讓你的團隊不會每天在那邊互相問「這個東西怎麼跑？」
工程化的核心思想
從亂七八糟到理論化、架構化的過程，就叫做工程化。
工程化最重要的思考點：
- 考慮多人共同協作的情境
- 考慮後續維護的情境
基於這些情境所設計出來的架構或方法，都可以視為工程化後的結果。
常見的工程化實踐
我自己的想法是，工程化可以拆成幾個面向來看：
| 面向 | 做法 | 解決什麼問題 |
|---|---|---|
| 版本控制 | Git + GitHub/GitLab | 多人協作不會互相蓋掉 code |
| 程式碼品質 | ESLint、Prettier、TypeScript | 風格統一，減少低級錯誤 |
| Code Review | PR review 流程 | 知識共享，降低 bug 進入 production 的機率 |
| CI/CD | GitHub Actions、Jenkins | 自動化測試、自動化部署 |
| 文件化 | README、API docs、Storybook | 新人不用每件事都問人 |
| 測試 | Unit test、E2E test | 改 A 功能不會爆 B 功能 |
前端工程化的演進
如果你是前端開發者，回頭看歷史會很有感覺：
jQuery 時代（2006~2015 左右）：
大家把所有邏輯塞在一個 app.js 裡面，CSS 就一個大檔案，部署就 FTP 上傳。那時候也沒什麼工程化可言，因為網頁本身就沒那麼複雜。
現代框架時代（2015~ 至今）： React、Vue、Angular 出來之後，前端變得跟後端一樣複雜了。你要處理 框架 選型、狀態管理、路由、打包工具、TypeScript⋯⋯這時候如果沒有工程化，根本無法維護。
所以你會發現，工程化不是有人突然發明的，而是複雜度逼著大家不得不這樣做。
簡單來說
把所有事情有條理地整理出來，並且描述一個大家都可以 follow 的指引，其實都可以視為工程化。
工程化的終極目標，就是讓團隊可以把時間花在「解決真正的問題」上，而不是花在「搞懂怎麼跑專案」或「修別人造成的低級 bug」上。