前後分離協作專案 — 四人團隊打造 Simple Twitter

五月底加入 AlphaCamp 學期三,經過兩個月的磕磕絆絆,終於還是順利進到學期的尾聲 — 與團隊協作完成 Simple Twitter 專案。在學期倒數兩週內依據 AlphaCamp 規範的 User Story, UI 設計圖及 59 項大小單元測試檔,與夥伴翊廷、Tina、Marco 完成 Simple Twitter 的推文、回覆、追蹤、按讚等基本功能開發。並在最後的週末挑戰黑客松的公開聊天室、私人聊天室及訂閱通知等進階功能。

📦 專案資訊:專案網址後端 GitHub前端 GitHub
測試帳號密碼:user2 / 12345678

專案規劃

簡介

用 Express 、 Vue 和 MySQL, 以前後端分離模式開發的社群網站。供使用者推文、回覆、按讚、追蹤、訂閱他人,並可在公開聊天室聊天、傳私人訊息,另設有後台供管理員瀏覽使用者數據、管理文章。

專案規格與使用技術

開發採用前後分離,2 位後端(翊廷、我)+ 2 位前端(Tina、Marco),

  • 後端: 使用 Node.js 搭配 Express.js 框架開發,建立 RESTful API
  • 部署:Heroku
  • 資料庫:本地使用 Sequelize 操作 MySQL、部署使用 Heroku / ClearDB
  • 單元測試:mochachaisinonsupertest
  • 版本控管:GitHub

團隊協作

團隊分成 2 位後端 + 2 位前端,因為都是遠端協作,因此使用線上工具即時了解隊友狀況,也規劃了 2 ~ 3 天一次的前後端開會時間。

除了所有人一起開會的時間,平時開發為前後端各自討論、核改另一位的 PR,有階段性成果後大家一起測試功能,並給予評論 。

Trello — 專案管理 Kanban 工具

為管理專案進度,使用 kanban 方法視覺化作業流程,設計流程如下:

  • To Do:將需要完成的使用者故事開成一張張卡片,並標記開發人員
  • Blocked by:若有卡片開發遇到困難,將卡片拉至此處並向夥伴求助
  • 開發中:每人一次開發一張,將開發中的卡片移動至此處方便夥伴了解團隊進度
  • 跑單元測試:卡片完成開發進行測試中
  • Done - PR 等待 review:完成開發等待夥伴 review,有需修正的地方在 PR 中說明
  • 等待合併 To Merge :PR 通過,將 function 分支併入 develop,等待併入 master
  • 完成合併 Merge to master:develop 分支併入 master
使用 Trello 管理專案進度

Apiary — API 溝通文件

因為團隊是遠距合作,因此在溝通資料回傳格式時使用線上工具較方便,且 Apiary 的 API Blueprint 語法源自 Markdown 語法,較無學習成本,因此選擇使用 Apiary 作為工具。

在撰寫時由於第一次進行團隊開發缺乏經驗,一開始由前端依照 response 需求撰寫,進行討論時卻發現由於前端對資料庫較不熟悉,其實由後端提供資料格式再與前端溝通會使流程更順暢,因此後來改為由後端主筆再與前端進行溝通。

使用 Apiary 即時查看 API 規格

管理 GitHub Repository 分支

為了將開發中的程式碼和正式要用的程式碼分開,規劃分支為 master — develop — feature 三層,並在每次 merge 分支時都發 Pull Request 等待夥伴審核確認後才能併入:

  • master:長期穩定版本,由 develop 分支併入
  • develop:開發中版本
  • feature 分支:一個功能為一分支,從 develop 分支而出,依該次開發的功能命名,被審核後併入 develop

我在專案中負責的項目

1. 專案基礎建置

這次開發採行前後分離,前後端專案是在不同的 Repository,而後端是由我先建立一些基礎架構:建立 Node.js + Express.js 專案與 MVC 架構、透過 Passport.js 的 JWT 驗證策略完成使用者登入身份驗證。

2. 資料庫建立

和翊廷討論後決定由一個人先建立好所有的資料庫 models 並通過所有相關測試檔,除了基本功能的資料庫建置,黑客松階段的資料庫建置也大部分是由我負責。

3. 路由開發

路由依據 RESTful 分成幾個大項:Admin, Followship, Users, Tweets。其中 Users 為最多路由的項目,而一開始基礎建設中的使用者身份驗證是我建置的,因此在分開發項目時也繼續由我負責所有 Users 的路由。

使用者相關路由大致包含:

  • 新增 / 登入帳號
  • 取得 / 編輯使用者資料
  • 取得其他使用者的推文 / 追蹤人 / 回覆 / 按過的喜歡 等等

而在最後三天完成聊天室功能的黑客松,我負責大部分的路由,包含訂閱通知、取得歷史通知、取得歷史訊息等等。

4. 團隊協作

負責項目的開發,也和夥伴翊廷互相協助完成 Code review。

黑客松 — 挑戰功能

黑客松限時兩天半,要完成即時公開 / 私人聊天室以及訂閱別人的功能。

公開聊天室畫面

Gather Town

在黑客松期間我們使用 Gather Town 幫助即時溝通、測試,有自己的辦公區可以在自己的小區塊做事,但又可以隨時走到別人的位子進行通話、螢幕分享,也可以在不方便的時候掛上忙碌狀態,Gather Town 對於時間緊迫的黑客松真的很便利。

大家在自己的位子做事!自己裝飾辦公區~

在兩天半的時間要完成所有挑戰功能其實有點困難,一開始團隊的進行方式是以完成所有功能為目標,但後來發現時間不太夠所以成果都差一點點。但在黑客松結束隔天,睡飽的大家又開始討論優化,也在後來完成聊天室跟訂閱功能!

開發心得與感觸

研究文件 — 看起來最麻煩的可能是最簡單的

因為是第一次主導較大的專案,中間遇到困難查文件時有時想偷懶找找有沒有別人寫好的解決方法,但看了看到最後還是只能看官方文件。幾次後就學乖不再想走捷徑了。

每次遇到問題都在練習下關鍵字的能力,不管是在 StackOverflow 還是看官方文件,解決問題常常需要的是知道要用什麼關鍵字搜尋 😂

遠端協作 — 尊重個體工作習慣,建立共識

這次開發都是遠端協作,因為大家習慣的作業時間不同(我的作息時間 6:00–18:00,其他三人更喜歡晚上做事),因此開發前先與密切合作的後端夥伴翊廷約定好一天 4 次的查看訊息時間點及固定的全體開會時間。透過事先溝通建立協作的共識比較不會有找不到人的焦慮,建立起固定的聯絡時間更能在其他時間專注開發不被訊息通知打擾。

經過這次我發現自己喜歡遠端的合作模式,雖然遠端相較於面對面需要花更多時間在溝通上,但也因為會先自己花時間整理成文字所以更知道想說的重點。固定的回訊息時間也讓我減少看到訊息就會焦慮影響做事效率的狀況。我想每個人都有適合自己的工作模式,而遠端比起轉身就能叫到人的辦公室對我而言是更能調整成符合個體差異的。

程式碼重構 — 前期規劃很重要

在一開始規劃專案架構時想得不夠全面,導致後面發現需要做一些重構跟整理花了不少時間。如果在前期花更多時間思考架構跟可以重覆利用的程式碼,就能減少後續的重構。

結語

很開心這次能和翊廷、Tina、Marco 合作完成 Simple Twitter 的開發,中間遇到不少問題但大家都很願意一起解決一起討論,也很感謝大家接受我不太尋常的工作時程,和在晚上開會時會有點休眠的大腦,每次到晚上都會關心我是不是該睡了大家真的很可愛 😆

黑客松結束後的 gather town 合照

整理一下筆記。

整理一下筆記。