這篇要從我第一次正式打開 PawPal 專案開始。
原本以為只要找到自己要修改的畫面就好，沒想到眼前卻是一大堆資料夾、元件、API、後端和資料庫設定。
對當時的我來說，真正困難的不是先寫哪一段程式，而是根本不知道這些檔案之間有什麼關係。
這篇會整理我怎麼從「完全看不懂專案架構」，慢慢理解前端、後端、API 和資料庫是怎麼一起完成一個功能。
第一次打開 PawPal 專案時，映入眼簾的是大量的資料夾與檔案。
當時最直接的反應就是：
這什麼鬼，怎麼這麼多資料夾？
以前練習切版時，通常只需要處理幾個 HTML、CSS 和 JavaScript 檔案。
但 PawPal 不只有前端，還有後端、資料庫、部署設定和第三方服務。
最讓我困惑的是，為什麼完成同一個功能，會需要同時修改前端和後端？
這些分散在不同資料夾裡的檔案，最後又是怎麼組合成一個完整的網站？
剛開始參與專案時，我最熟悉的仍然是畫面切版。
看到設計稿後，我大概知道按鈕、表單和卡片要怎麼排版，卻不知道畫面背後的資料是從哪裡來的。
當時甚至會覺得：
如果連切版都做不好，後面的功能可能就更做不出來了。
面對沒有接觸過的內容，我只能先把問題拆小，自己查資料、詢問 AI，再向同學、助教或老師確認。
至少先完成眼前能理解的部分，再慢慢處理下一個問題。
當時最不理解的是 Vue。
我不知道：
views 和 components 有什麼差別。我也曾經詢問同學，但因為當時真的完全沒有概念，對方解釋到最後只跟我說：
做完你就知道了。
當下聽起來很無奈，但後來我才發現，這句話其實沒有錯。
有些東西只看文字很難理解，真的開始實作後，才會慢慢知道每一個檔案到底在做什麼。
PawPal 採用前後端分離架構。
專案主要可以拆成幾個部分：
PawPal 的前端使用 Vue 3，後端使用 Node.js 與 Express，資料則儲存在 PostgreSQL，並使用 Supabase 提供資料庫服務。
簡單來說，Vue 是我們建立前端畫面與互動功能時使用的主要框架，頁面、元件和畫面上的資料變化，都會在這個架構下組合起來。
前端部署於 Vercel，後端部署於 Render。
除此之外，專案也串接了 Cloudinary、Gemini API、LINE Login、Google Auth 和 Google Calendar API 等服務。
這些名稱當時看起來都很陌生，但後來我發現，現階段最重要的不是一次把所有技術背起來，而是先知道每個部分大概負責什麼。
真正開始接觸功能後，我才慢慢看懂 PawPal 前端資料夾的分工。
在 PawPal 這個專案裡：
views 主要放置頁面層級的內容。components 放置可以被頁面組合或重複使用的介面元件。api 集中管理前端送往後端的 API 請求。stores 負責管理不同元件需要共用的前端資料與狀態，例如寵物列表、目前選取的寵物和載入狀態。我不是一次就記住所有資料夾的用途。
而是每次修改一個功能時，才慢慢知道：
原來這個檔案負責畫面，另一個檔案負責送出資料，還有一個地方負責保存前端正在使用的資料。
原本看起來毫無關聯的檔案，開始慢慢連在一起。
一開始我不會直接看懂整個專案，只能從畫面上的功能反推檔案位置。
例如看到一個新增寵物按鈕，我會先找它出現在哪個頁面，再往下找這個頁面使用了哪些元件、呼叫哪一支 API，最後才慢慢知道資料還會經過 store、後端和資料庫。
這種找法雖然很慢，但對當時的我來說，比一次硬看完整個資料夾更容易理解。
我不是先把所有資料夾背起來，而是透過一個實際功能，把相關檔案一個一個串在一起。
現在的我會把前後端分離想成餐廳的前台與廚房。
前端就像前台。
使用者可以看到畫面、填寫資料、點擊按鈕，也會在這裡看到系統回傳的結果。
後端則像廚房。
它會接收前端送來的需求，檢查資料、執行規則，再與資料庫溝通。
例如新增寵物時，流程大致是：
使用者填寫寵物資料
↓
前端整理表單內容
↓
透過 API 傳給後端
↓
後端驗證並處理資料
↓
將資料存入資料庫
↓
後端回傳新增完成的寵物資料
↓
前端更新狀態與畫面
前端與後端雖然分開開發，最後仍然會透過 API 一起完成同一個功能。
後來我開始接觸寵物資料相關功能，這也成為我理解整個專案架構的入口。
以前我只看得到新增寵物的按鈕、表單和卡片，但真正準備開發時，才發現畫面背後還有 API、後端處理、資料庫和前端狀態。
我開始知道，原來完成一個看似簡單的功能，需要許多不同檔案一起合作。
只是當時的我還不知道，真正開始動手後，光是新增一筆寵物資料，就會遇到比想像中更多的問題。
至於新增寵物時實際遇到了哪些問題，就留到下一篇再慢慢說。
一開始我以為，應該要先完全理解整個架構，才能開始寫功能。
但實際情況剛好相反。
我是先開始做，遇到問題後再一個一個查：
每解決一個問題，原本模糊的架構就清楚一點。
我並不是在某一天突然完全看懂 Vue，而是在功能逐漸完成後，才慢慢把每個部分連起來。
每個專案的架構都可能不同。
但當團隊決定使用某一種架構後，就需要理解每個部分負責什麼，以及它們如何互相合作。
對當時的我來說，只看文章或架構圖，很難真正理解前端、後端與資料庫的關係。
反而是在實際開發、遇到問題、查找檔案和修正錯誤的過程中，我才慢慢看懂整個網站是怎麼運作的。
如果現在重新接觸一個新的專案，我不會再要求自己一開始就看懂所有資料夾。
我會先從一個實際功能開始，沿著畫面、元件、API、store、後端與資料庫，一層一層確認資料是怎麼流動的。
比起一次打開所有檔案硬看，我會先問幾個問題：
這樣理解專案，對我來說比背資料夾名稱更有幫助。
這篇可以先記住幾件事：
views、components、api 和 stores 各自負責不同工作。以前我會覺得，應該先把整個 Vue 專案架構看懂，才有資格開始寫功能。
但後來我才知道，很多時候剛好相反。
我是先從一個功能開始，遇到問題後再往下找檔案、看資料流，原本陌生的架構才慢慢變得有意義。
理解 PawPal 的基本架構後，下一步就是正式接手寵物功能。
原本我以為，新增寵物只是把表單資料送出去，但真正開始做後，才發現畫面、欄位、API 和資料庫只要有一個地方對不上，功能就可能無法正常運作。
下一篇：
Day 6｜第一次接手寵物功能，真的沒有想像中簡單
iThome鐵人賽
看影片追技術