從技術選型到架構設計：主導新專案的經驗分享

最近一個新專案剛結束，趁著空檔記錄一下這次的經驗。這次我不只是參與開發，而是從技術選型、架構設計到流程規劃，幾乎都由我主導大方向。對我來說，是一次蠻重要的里程碑。

以下是幾個在這次專案中做的技術決策與實作內容：

團隊技術背景與選型考量

團隊主要使用 Java 8 舊版本，Spring 框架也偏老。這次新專案決定改用 Spring Boot 3 搭配 JDK 17，雖然能提升開發效率，但也知道對部分成員來說會有一定的學習門檻。

前端方面，大多數人對 JavaScript 的認知還停留在 JSP 時期，ES6 語法不熟，更不用說 React 或 Vue 這類更新頻繁的框架。最後我選擇整合相對原始的 UI 元件，搭配 Vanilla JS，盡量降低學習難度，同時保留基本的互動性與模組化能力。

在設計 API request 的共用元件、整合常用依賴的過程中，也開始理解像 Nuxt 這類 meta framework 為什麼會強調模組化、資料流清晰與預設約定，這些設計背後其實是為了降低複雜度與提升開發一致性。

元件選型：功能、文件、成本之間的取捨

專案啟動當時，AI 工具還不普及，前端元件選型必須快速決定。上頭提供了幾套方案，要我們協助評估：其中一套功能完整但價格高，網站範例不太好參考；另一套則偏陽春，但現有範例資源多、文件相對清楚。

最後選擇了文件比較完整、整合起來比較順的方案。畢竟在缺乏現成經驗的情況下，文件品質真的很重要。

分支策略與合併流程

初期採用簡化版 Git Flow，主要是 feature → master，develop 環境還沒建好，staging 還在規劃中。

合併流程也還沒自動化，我先協調各模組的開發方式，規定每組只有一位負責人有合併權限，其他人不能直接合入 master，要交由負責人處理。雖然是人工控管，但目前這樣比較穩定，也能避免錯誤直接進主線。

Code Review：建立基本流程

目前的 Code Review 流程是每個 PR 提交給各模組有權限的代表做合併，主要看程式面和事前協調好的規範，畢竟實際功能只有各模組人員最清楚。

同時也讓參與開發者練習怎麼給具體、有幫助的 review 意見，慢慢建立起團隊的開發風格。

專案目錄規劃：從 layer-based 改為 feature-based

既有的專案是典型的 layer-based 架構，controller、service、repository 分得很細，但模組之間耦合高，專案一大就很難維護。

我提議改成 feature-based 架構，依功能模組劃分目錄，例如：

src/
├── user/
│   ├── controller/
│   ├── service/
│   └── repository/
├── order/
│   ├── controller/
│   ├── service/
│   └── repository/

這樣的好處是：

• 模組邊界清楚，維護更直覺
• 權責分明，避免跨模組亂改
• 未來要拆微服務也比較容易
• 新進成員只要理解某個模組就能快速上手

這不只是技術調整，也讓我開始思考怎麼建立清楚的專案架構，讓模組之間的溝通更穩定、邊界更明確。

小結

這次專案讓我真正參與到技術選擇與架構設計，也學到很多跟人協調、推動流程的事。技術決策不只是選工具，更是要考慮團隊背景、學習成本、維護難度。

希望未來能有更多這樣的機會，也期待自己能越來越有能力，在技術上帶得動團隊。