前後分離專案 — 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 也讓我們非常放心,基本畫面外的細心程度令人吃驚,夜間模式也酷到我一時無法自拔。以整體基本功能來說,我們這組也得到最佳的肯定,讓我的第一次協作就有這麼好的體驗,真的很感謝大家!