前後分離專案 — Simple Twitter 回顧與反思
此文同步轉載於我的部落格：richard-widjaya.me
Simple Twitter 專案是我第一次嘗試與他人以團隊形式進行開發的專案，嘗試前後端分離開發、設計資料庫、開發 API，在過程中遇到形形色色不管是開發還是溝通的問題，對我來說都是非常寶貴的經驗。在開始前先附上我們的專案成果吧！
你可以在這裡體驗 Simple Twitter Live Demo。
- 前端 Github Repo
- 後端 API Server Github Repo
團隊協作分工
Simple Twitter 專案使用前後分離模式進行開發，後端 API Server 由我和另一位後端夥伴 Louis 使用 Node.js, Express.js, MySQL 進行開發，並將 API Server 部署在 Heroku。前端則是由兩位夥伴 Ethon 和 Nixon 使用 Vue.js 進行畫面開發。
專案開始前
因為這是我們第一次在沒有輔助，只有被給予 User Story 和產品規格的情況下進行開發，所以在剛開始時心中充滿焦慮和不知手措，不過絕大部分來自於自己的 Imposter Syndrom，深怕自己拖累隊友。
一、拆解 User Story
在捲袖子寫程式前，我們拆解了每條 User Story，將使用者故事拆分成規格更明確的 Acceptance of Criteria 及 Definition of Done，讓我們可以以粒度最小的關注點進行開發，以免失焦。
二、後端會議
結束拆分後我和 Louis 開始了第一次的後端會議，我提出以 RESTful 為中心，以資源來分配路由開發。我們依照各自負責的資源整理了所有需要的路由，並整理成表單方便管理開發進度。而因為各自在不同路由工作，結果也大幅減少了後續開發中遇到的 merge conflict，讓後端的開發進程不阻塞能持續推進。
三、確認分工細節
我在專案中負責 tweets 和 users 相關，共 14 條路由的開發與測試。並負責撰寫所有種子資料的腳本、使用 passport.js 實作 token-based 登入機制、登入相關基礎建設、撰寫並維護 API 文件、撰寫 Github README 等。
四、專案管理
在專案開始前我為團隊建立 Trello 看板，為符合 Agile 開發精神由左至右新增了 Backlog、To Do、Blocked By、Developing — WIP4、Testing、Code Review、Merged、Deployed 欄位，定義每張卡片只能是一個功能或工作，且每個人一次只能有一個正在開發的功能，限制專案中半成品的數量。每張卡片的 life cycle 也只會從左至右，如果進度卡住需要隊友救援，才會將卡片丟回 Blocked by。好在隊友都很優秀，整個專案都沒有使用到這個欄位。
我也整合 Trello、Github 和我們溝通使用的 Slack，讓每張卡片上都能連結 PR、branch、commit，讓團隊成員可以方便管理功能與對應程式碼，並從 Slack 的討論串中找到卡片和程式碼更動連結。
專案開始
Test-Driven Development 測試驅動開發
在前置討論和規劃完成後，我和 Louis 就分頭進行開發。我們遵照 TDD 原則進行開發，在動工程式碼前研讀測試檔案，了解每支路由的預期行為，然後以 MVP 的思維對待每支 API 的開發。在滿足測試規格後，才接續進行功能擴充。
這個方式讓我們無須擔心開發到最後才開始依照測試檔調整邏輯，讓整個開發流程隨時 on schedule。了解測試內容的同時，也讓我們在一開始就對專案規格有全盤的掌握。
實作路由及前後端串接 API
因為在專案開始前已經實作過多次 CRUD，所以在專案開始三天，後端就已經實作完所有的基本功能，並通過所有測試案例。開發快速也讓後端可以提早交付規格進行查驗，也讓我有更多時間使用 Postman 撰寫 API 文件，讓前端可以預期 API 資料回傳格式，讓後續前端串接 API 可以更順利。
專案後期收尾－危機處理
在即將迎來交付期限，我們與前端夥伴的串接也差不多結束了，但因為四散各處的小 bug，讓有些規格遲遲無法完成提前驗收。而在交付前 24 小時，因為 33 全台大停電的緣故，讓居住在南部使用桌機的 Louis 無法工作，導致當時後端無法做 code review，PR 沒辦法 merge 到主幹，自然沒辦法部署 API 給前端使用，整個流程遭到 block 外，Github Repo 的 owner 是 Louis，所以我們無法交付產品。
由於時間壓力，當時我判斷應該先提早與前端進行最後交付前的 Demo 會議，於是我就和兩位前端夥伴依照完成指標表上的事項，逐一檢查是否達成指標項目，並在線上進行 debug，跳過 PR 和 code review 階段直接部署到 Heroku 讓前端串接。
與此同時我聯絡專案 stackholder（AC 的教練群），告知預期外的情況發生，並溝通原先交付限制之外的解決方案。最後除了新的交付方式外，也獲得了額外 4 小時的交付寬限期。到這個階段前後端皆已經透過上述的驗收，達成了所有指標規格，加上剛討論的交付結論，讓危機順利解決。
但就在剛與 stackholder 討論完這個危機，準備要跟其他組員講最新的交付方式時，斷電整整 12 小時的 Louis 就回來了（XD）。後面我跟他更新了最新進度後，再由他進行最終測試驗收，我們這組也成功地如期交付專案。
挑戰功能
在專案結束後，緊接著就是為期兩天的挑戰功能黑客松，這次的挑戰是使用 Socket.io 實作聊天室、訂閱、及時通知功能。但可惜的是一位前端夥伴經過兩週的密集開發身體抱恙，不得不退出挑戰，讓另一位前端夥伴必須扛起獨自切版和串接的開發。
此時前端已經將畫面都完成，後端也實做出儲存訊息、本地聊天室功能及訂閱功能。原本希望能在時間的壓力下完成所有挑戰的功能，但人力吃緊的情況下，所以最後很可惜的止步於串接階段。
專案反思
我認為這次專案做得最好的地方就是溝通和危機處理的部分，收穫最大的也莫過於整體協作經驗，讓我更了解在前後分離的團隊專案中該如何溝通和分工，是埋頭自學絕沒辦法得到的經驗。技術的部分則是因為前後分離的關係，更體認到系統效能的重要性，也因為這樣自己又重新啃了一遍又一遍的 Sequelize 官方文件，想盡辦法使用資料庫分擔伺服器效能。這也讓我更熟練 SQL 和 ORM join table 的使用方式。
可以改進的地方
因為是第一次的協作專案，所以在開始時雖然知道團隊需要大量有效的溝通，卻有點像無頭蒼蠅不知道從哪裡開始討論起，隨著專案的推進才慢慢發現問題。經過了這次的經驗也知道未來協作時該從哪裡起手溝通：前後端 API 共同定義資料格式、何時開始階段性驗收等等，都是之後團隊開發可以先考慮的事情。
感恩的心
真的很感謝一開始後端夥伴 Louis 邀請我當他的組員，雖然剛開始是 Louis 說因為觀摩我的作業想從一起協作中學到更多 coding 的技巧，不過在專案結束後我也從 Louis 身上學到了很多溝通和 coding style 上的眉角。另外前端的兩位夥伴－Ethon 和 Nixon 也讓我們非常放心，基本畫面外的細心程度令人吃驚，夜間模式也酷到我一時無法自拔。以整體基本功能來說，我們這組也得到最佳的肯定，讓我的第一次協作就有這麼好的體驗，真的很感謝大家！