Proto 規劃（一）：為什麼每個專案都在重新發明輪子？

cover

為什麼每個專案都在重新發明輪子？

一句話總結：Proto 是讓你第一天就能寫業務邏輯的生產環境級起始點，不是又一個 Hello World。

結論先講：如果你的團隊每開一個新專案就要花兩週處理 Docker、CI/CD、環境變數、錯誤處理這些「跟業務無關但每個專案都需要」的東西，你需要的不是更快的工程師，是一個好的 Proto。

每一個新專案都從某個地方開始。有些團隊從 create-react-app 開始，有些從 GitHub 上找一個 boilerplate，有些直接 mkdir 從零開始。

然後呢？第二週才發現 Docker 設定不完整、CI/CD 根本沒有、錯誤處理各寫各的格式、日誌散落在 console.log 裡。本來該花在業務邏輯上的時間，三分之一被消耗在「重複解決基礎建設問題」上。

你有沒有算過，每個新專案在這些事情上花了多少時間？環境設定、容器化、CI/CD、錯誤處理、日誌格式、測試結構、安全基線——這些東西跟業務無關但每個專案都需要。它們應該被解決一次、複用多次。

Proto 不是你想的那種 Template

先搞清楚四個概念的差異：

Template：程式碼樣板，cookiecutter 那種，變數替換產生新專案，產出後通常不回溯更新
Scaffold：框架提供的初始化命令，create-react-app、django-admin startproject，只有框架的最小骨架
Boilerplate：GitHub 上一堆 xxx-boilerplate，特定技術組合的範例，但沒有你的團隊慣例
Proto：你的團隊定義的「生產環境等級專案原型」，包含完整的基礎建設、團隊慣例、安全基線

Scaffold 只給你框架的骨架。Boilerplate 只給你技術組合的範例。Proto 給你的是：clone 下來就能開始寫業務邏輯。

COPY, not Reference：最重要的一條原則

每個新專案應該是 Proto 的完整獨立副本，而不是引用或繼承。

為什麼？

專案獨立性：不同專案有不同的演進速度，不應被 Proto 更新綁架
可客製化：複製後自由修改，不影響其他專案
完整性 > DRY：在專案層級，完整性比「不重複」更重要

實務做法就是：

cp -r proto/b2e/django-proto ./new-project-name
cd new-project-name
rm -rf .git && git init
git add . && git commit -m "init: from django-proto v2.3.0"

記錄從哪個版本的 Proto 複製，之後需要追溯就有依據。

Proto 分類：四類就夠了

不要搞太多分類，四類涵蓋絕大多數的專案：

b2e/：後端服務（Django、Spring Boot、Express、FastAPI）
f2e/：前端應用（Vue 3、React、Svelte）
app/：全端 / 行動應用（Nuxt、React Native、Flutter）
infra/：基礎建設（Nginx + Docker Compose、EFK Stack）

為什麼只有四類？分類的目的是「快速找到」，不是「精確描述」。分太多反而讓人猶豫「這個該放哪裡」。

架構邊界：Proto 管什麼、不管什麼

這點非常容易搞混。在前後端分離的架構下，明確的邊界劃分很重要：

Proto 負責的（應用層）：專案結構、多環境設定、安全基線、錯誤處理、日誌、測試基線、文件、程式碼品質。

Infra 負責的（基礎設施層）：Docker 建構、CI/CD Pipeline、CORS（在 Nginx 層）、部署策略、備份。

Proto 只需要提供 Infra 所需的介面——比如 health check endpoint——實際的容器化和 CI/CD 由 Infra 處理。

搞混這個邊界的後果是：前後端工程師被迫承擔 Infra 的 context，或者 Infra 的設定散落在每個專案裡各自為政。

這篇的重點回顧

Proto 是生產環境等級的專案原型，跟 Scaffold、Boilerplate、Template 不同。核心原則是 COPY not Reference，分四類管理，邊界清楚（Proto 管應用層、Infra 管基礎設施層）。

下一篇我們進入 Proto 的核心——10 個完整性面向的檢查清單。

系列文章：

Terry Yao's Blog

分類

目錄