作為 AC 的畢業專案 Simple Twitter，AC 基本上除了提供 user story、規格、UI 設計稿之外，也另外提供了測試檔，其中包含了 59 項單元測試，必須要全數通過才算完成基本功能。學生們會自行組成 3~4 人的小組，採用前後端分離或是全端開發，在兩個星期內完成推文、回覆、追蹤、按讚等基本功能。在此附上本專案的相關連結：
筆者負責的 後端 github repo
前端夥伴的 github repo
可以使用 user1@example.com / 12345678 登入網站體驗團隊協作模式
本組採用 4 人團隊，採前後端分離的開發模式：
前端部分 ( 2 人)：使用 Vue.js 前端框架，串接後端組員的 API
後端部分 ( 2 人)：使用 Express.js 後端框架設立 RESTful API endpoint，資料庫使用 MySQL ，使用 Heroku 部屬
筆者為後端組員的其中一人，負責設計專案的基本架構，使用者相關的 API endpoint，與使用 Passport.js JWT 進行使用者登入驗證。
另一名後端同伴 (以下稱為查理)，負責推文、追蹤、按讚相關的 API endpoint，與撰寫 API 文件、部署至 Heroku。
事前準備
以下為後端部分的開發流程紀錄
研究規格細節
在完成基本功能時，必定要先通過單元測試，因此我們先開始研究 AC 提供的單元測試，看看規格內需要架設哪些 endpoint，每個 endpoint 需要回傳哪些資料，以及 model 需要哪些欄位等等，確認之後在開發過程中，需要特別注意哪些事情。
建立 git-flow 開發流程
在後端專案的開發過程前，我向查理提議 git-flow 的開發流程，除了可以使用 feature branches 來分工，也可以避免開發後期可能因為職責混亂而產生 merge conflict。
此外，我們也在 github 建立協作限制，每個 PR 都需要另一位協作者完成 code review 才能接上 develop 分支，藉此確保程式碼的品質與雙方資訊的對等。
開發過程
追蹤進度
在開發過程中，我們使用 trello 來追蹤前後端的開發進度，後端部分以功能，或是 API endpoint 為單位開票，並且串接 github repo ，在每一張票上附帶 github 的 commit、 PR等連結。
建立基礎架構
以下為本專案後端部分的基本架構
├── app.js
├── config #其中包含使用者驗證、跨域共享、資料庫等設定
│ ├── config.json
│ ├── cors.js
│ └── passport.js
├── controllers
│ └── #裡面包含 API endpoint 對應的 controller，包含表單驗證
├── _helpers.js
├── middlewares
│ └── auth.js
├── migrations
├── models
│ └── #裡面包含本專案的資料庫 model
├── package.json
├── package-lock.json
├── README.md
├── routes #裡面包含專案的 API endpoint
│ ├── apis
│ └── index.js
├── seeders
├── services
│ └── #裡面是直接操作 model 的各種函式
├── temp
├── test #內部包含 AC 提供的測試檔
└── utils
└── #裡面包含其他 helper function特殊開發過程 — 接力開發 (?
查理的活躍時間都是下午 2 點到半夜 1、2 點，而筆者是早上 7、8 點到晚上 10、11 點，因此在開發的第三、四天時，我們形成了一種獨特的協作模式：
(以下為筆者視點)
早上起來看查理的 PR -> 與查理一起討論開發的問題 -> 到了睡覺時，查理繼續開發 -> 查理睡覺前，發送一個新的 PR藉由職責清晰的架構，與特殊的協作模式，在 3 天內就讓前端組員可以開始串接一部分的 API，到了第 5 天，後端組已經完成基本功能所有 API endpoint ，並通過了全數 59 項單元測試。
前端串接
協作專案開始前一天，前後端組員第一次討論時，得出了一些概略的開發流程：
- 先完成後台，再完成前台。
- 後端會提供 API blueprint 製成的 API 文件，利用 apiary 生成假資料的功能，先讓前端組員進行 API 串接。
- 預估 2 天後可以完成後台基本功能
2 天後，後端將專案部署至 heroku ，前端組員也完成了畫面相關的功能，進行串接後，後台功能正式完成。
在之後的開發過程中，據前端組員的說明：
原本前端要使用資料時，會先做假資料，但是專案開發到現在，都沒有建立過，直接串接 API 就可以了 XD
自訂 model 欄位
在 MySQL 裡面，boolean value 是使用 1/0 儲存起來的，對前端組員來說似乎有點棘手，之後我便開始在 sequelize 文件尋找解決辦法，之後看到 sequelize virtual 資料型態的說明，發現可以特別處理額外加上去的欄位。之後便可以回傳 true/false 給前端，減輕前端處理額外資料的負擔。
挑戰功能 — 即時聊天室
完成基本功能後，AC 還有提供挑戰功能，要在兩天半的時間內使用 websocket 技術完成功能，依照難度分別為：公開聊天室、私人訊息、即時通知。在技術上，本組使用 socket.io 套件，並且在挑戰時間開始前建立測試用的 codepen 來摸索使用方法。
此外，考慮到該功能需要前後端的即時反應，因此筆者額外使用 ngrok 工具，可以將 localhost 的服務被外界使用，讓前端與後端在開發的同時，也能即時更改程式碼，省略繁瑣費時的部署步驟。
前後端剛開始串接時，又遇到了原本早已解決的 CORS 問題，後來經過幾小時的搜尋資料與嘗試方法後，發現前後端的 socket.io 的套件版本必須一致。
此外在前後端串接時，我想要特別感謝組長 — 負責前端的許丹，在開發即時聊天時，她完全授權我來設計 event name 與傳入的參數，避免了 event name 或是串接資料不一致的狀況。
在這兩天半的時間內，大家即時溝通的時間也比開發基本功能時還要長，在時間的壓力下要使用之前從未接觸的技術來完成至今沒有實作過的功能，稱作挑戰著實當之無愧，而最後完成了公開聊天室與私人訊息，也是盡了當下最大努力的成果。
完成後反思
Simple Twitter 協作專案比起單獨開發，著重的是開發者們互相溝通、釐清需求的協作過程。
在 git 使用方面，這是筆者第一次使用 git-flow 與 github 的協作模式，但是在筆者簡單了解 git-flow 的運作原理之後，發現這套開發流程可以避免某些在多人協作時可能會出現的問題。
在前後端溝通方面，筆者也要特別感謝查理額外製作的 API 文件，大幅減少開發前期的前後端溝通成本。
致謝
感謝參與專案的各位夥伴 — 後端的查理與前端的許丹、Ashley，在這 14 天之中，經過大家的互相配合，很順利地完成了第一次團隊協作，在專案完成的那一刻真的充滿成就感，讓這次的團隊協作留下美好回憶。
