Vibe Coding 時代的架構陷阱心得
Vibe Coding 時代的架構陷阱心得 🪤 自認平時還算有系統分層的觀念，設計過不少 API 介面和服務層。但最近用使用 v0 (Next.js) + Supabase 這類 BaaS 快速開發模式時，還是被 Vibe coding 的高效率假象迷惑，差點搓出一團義大利麵程式碼 🫠
▍但問題不在工具，而在「隱形的架構債務」 Vibe 工具會給你直接可用的程式碼，但不會提醒你要思考：
- 這段邏輯該放前端還是後端?
- Service Layer 的邊界在哪?
- 資料聚合層該不該穿透到客戶端?
此外結合 BaSS 工具(如 Supabase) 帶來的高速開發感，也容易讓 vibe 工具在你不注意時，就把 DB 直連寫進 UI fetch。一開始跑得動沒問題，但隨著需求增加，fetch(‘/api’) 呼叫四散各處，整個專案會變得難以追蹤與維護。 當然，前端不是不能拉資料，但拉什麼、怎麼拉其實是架構設計問題，而不只是開發體驗問題。
▍我的作法(給也在用 BaaS 的朋友參考)：
- BaaS 很方便，但方便≠可以偷懶架構設計，該思考清楚的還是要先做，省下後面很多重構成本
- 先把 API Contract 跟 Service Interface 想清楚再開工，不然邏輯一旦散開，很快就收不回來
- Supabase 操作我一律集中封裝在 service 裡，方便後續維護權限、錯誤處理與邏輯轉換
Vibe coding 真的很好用，但建議大家別被”快”給吸引，而模糊掉原本應該存在的開發界線 😂。該寫的文件、該規劃的架構還是得先做，至少現階段 AI 還沒辦法通靈 (我們還得再撐一下)。
不曉得大家有沒有遇過類似狀況? 如果有踩過坑、或有自己的做法，歡迎留言交流，幫助大家避免踩坑👇
hashtag#VibeCoding hashtag#架構設計 hashtag#BaaS hashtag#開發心得