ALPHA Camp 學期三 Simple Twitter 協作專案
我有新的部落格了，歡迎來逛逛 https://blog.jhdev.pro/
前言
終於來到了學期三期末的協作專案了，這個專案可以選擇用熟悉的全端開發架構，或是使用初接觸的前後端分離開發架構，打造 SPA (single-page application)。不過由於這屆前端課程的同學很少，所以多數組別都是使用全端開發架構，我跟 Harry 很幸運找到一位前端的夥伴 Ivy 組隊，終於可以體驗一下傳說中的前後端分離開發架構啦～
基本分工
前端 Vue.js 由 Ivy 負責，後端 Node.js + Express.js 搭配 MySQL 由我(兼組長)和 Harry 負責。由於 Ivy 是在職前端工程師，所以已經預期會有部分前端刻板工作需要後端支援。
我和 Harry 在後端的分工一開始是滿隨意的，直接用 User Stories 來分，誰做得快就先做，但第一次 merge 時發現這樣衝突會很多。為了避免花太多時間在解這些 conflict ，決定由 Harry 先把 Model 建好，而我先寫註冊登入登出驗證等跟套件相關的功能。
協作方式 & 工具
組長的工作其實就跟 PM 一樣 (剛好我前一份工作就是 PM)，所以要負責向 AC 回報專案進度、溝通專案問題等工作。
除了分工，協作的方式也很重要，如何讓夥伴們順利地執行專案也是組長的責任，這邊介紹一下我們選擇的協作工具：
- Slack
主要使用 backend, frontend, general 這三個 channel 來討論，並將 Trello 整合進 Slack，同時也把常用的文件連結用 PIN 功能儲存起來，方便大家查找。
2. Google Docs
將 User Stories、Tech Hour 討論結果、測試問題等資訊記錄在這，方便共筆。
3. Trello
把 Google Docs 上的工作標題轉換成一張張卡片，可以一眼看出大家正在做的、和已經完成的工作。
展開兩週的開發之旅
指定功能 & 後端 debug 地獄
Simple Twitter 開發的要求分為指定功能及挑戰功能，指定功能除了正常運作之外，還要能夠通過 AC 撰寫的自動化測試。
剛開始和 Harry 兩個人花了三天照著自己的意思把後端 API 建置起來，信心滿滿的跑自動化測試，跑完看著滿江紅的終端機畫面，當時還覺得很有趣，想說靠怎麼沒有一條路由是通過的😂，殊不知自己正踏入 debug 地獄中...
bug 的分類大概可以分成三種：
- 自動化測試本身的 bug
這種 bug 會耗費最多時間，因為自動化測試的程式碼是用 mocha, chai, sinon 等測試套件或方法寫的，之前也沒學過，所以只能盡量閱讀這些程式碼，看久了會發現一些重複的關鍵字如 should, equal, expect 等等，就就可以大概猜出意思；再來是從錯誤訊息中尋找線索，加上在自己的程式碼和測試程式碼中用 console.log 來除錯。真的有發現錯誤就要趕快回報給 AC，避免卡住專案的進度，通常他們會儘速修好然後發佈更新版本(有時更新了會出現新的 bug 😵)。 - API 回傳的資料與測試要求不符合造成的 bug
這種 bug 通常可以從錯誤訊息及自動化測試的程式碼中發現，像測試的要求是回傳一個陣列，但我們回傳的是一個物件，那就會出現錯誤。 - 神奇的 bug
這次每一組都有遇到 Like Model 的 id 在跑SQL 時無法自動讀取，造成自動化測試一直失敗的狀況，在兩個人 debug 許久後，我強大的隊友 Harry 想到直接把 id 手動寫進 model 的方法，才成功通過測試。向 AC 回報時，維元老師看了也是嘖嘖稱奇，只能說程式的世界真是無奇不有🤔。
後端經歷過整整一週兩個人每天開 Zoom 分享螢幕進行 live degug 的 debug 地獄之後，終於迎來了全數通過自動化測試的這個 moment，眼淚差點都要滴下來了😭，但是專案還沒結束呀，還要繼續衝刺才行！
部署 API server
部署 Heroku 的過程也是花了比預期多的時間，主要問題在於環境變數 NODE_ENV 的設定，短短 3 行 code 寫了 3 個小時...只能怪自己忘記 Heroku 還有 Procfile 要設定😵。
挑戰功能：即時聊天室
指定功能的開發及 debug 就耗掉了一週的時間，加上有些 bug 需要等 AC 更新才能繼續開發，所以在等待期間我們也沒閒著，持續研究 ngrok 及 socket.io 的用法，我也順手將 ngrok 的設定過程寫成懶人包供大家參考。
過程中前端夥伴因為工作關係無法準時完成進度，加上我和 Harry 都不諳 Vue.js ，只好當機立斷，臨時改用全端開發架構來完成即時聊天室。
挑戰功能是採用黑客松的方式，在48小時內盡可能的開發，所以改用全端開發架構也代表，我們需要從零開始刻畫面並且在48小時內完成😵，由於我在指定功能階段就有支援前端一些簡單的畫面，所以畫面由我負責，Harry 則基於我們之前研究的 socket.io 基礎，繼續開發私訊、通知等其他功能。
兩個人經過兩天幾乎沒睡的密集開發，最終結果還算滿意，真的是 盡 · 全 · 力了。
test account
帳號 user0 ~ user4
密碼 12345678
總結我做了哪些事情？
- 建置專案協作環境及共筆文件
- ERD 設計繪製、共同撰寫 API 文件
- 註冊登入登出、使用者驗證功能
- 使用者資料、相片更新功能
- 種子資料設計
- Heroku 部署 API server
- 掌握 ngrok 使用方法
- socket.io 基本環境建立
- 挑戰題聊天室前端頁面切版及資料串接
感想
前後端分離開發架構確實有其優勢
在兩週內因緣際會經歷了全端及前後端分離的開發架構，我很深刻的感受到前後端分離的開發優勢，在寫 API 時是從 Model 出發，所以後端變得相對單純，可以完全專注在邏輯上，只要依照前後端講好的 API 文件下去開發即可，不需要像全端開發時還需要顧慮前端樣板寫邏輯所需的資料，這麼一來後端的開發效率就高很多 💪。
Git Flow 協作經驗
學習運用 Git, GitHub, Git Flow，這真的需要多人協作才能學會，運用分支來區分不同階段、任務的程式碼；體會到開發時要管理 commit 的粒度，以便 merge 時可以更順利地解 conflict。
要 merge 時我們都直接開 Zoom 分享螢幕來一起解 conflict，還記得第一次 merge 時遇到好幾個 conflict 緊張得要死，其實就只是兩個人都建立了一樣的 model 而已，到後期三兩下就可以完成 merge。
其中最大的差異是程式碼分工，如果可以先預想到會重複的程式碼如 Model ，就可以先由一個人來建立，而兩個人開發的功能也要注意會不會有重複的程式碼，這樣可以避免重工又要解 conflict 的狀況發生，加速開發。
每一次作業的畫面刻板都要認真做
如果不是從學期一開始就認真學習前端切版技術，每一次作業也都嘗試多做一點把自己心中的畫面實現，現在突然要我在短時間做出聊天室畫面我想是不可能的，何況之前的作業也很少使用到 position: relative, absolute, fixed 等屬性，真的能成功刻出來我自己也有點小驚訝就是了 🤣。
使用第三方套件的能力
現代開發模式多須依賴開源軟體或套件，避免自己重新製造輪子，加快開發的速度。因此閱讀官方文件的能力很重要，這與英文能力和程式實作能力有關，官方文件通常都寫得很簡單、陽春，如何轉化為符合自己專案架構的寫法，並解決過程中發生的問題（如非同步處理），我想這就是工程師的價值所在。
先釐清測試要求再開發
如果可以重來，在有自動化測試檔案的情況下，我會先研究自動化測試的要求，再開始開發 API。開發的過程中也要持續跑自動化測試，例如先寫測試要求的部分，確定通過後，再寫完整功能，這樣會更有效率。而且自動化測試本身也會有寫錯的地方，同樣需要 debug，一來一往會耗費許多時間。
專案的風險管理
專案初期太樂觀，與前端夥伴只有口頭上交流；之後後端自動化測試一波三折，加上沒有特別去 follow 前端夥伴的進度，導致第二週統整指定功能的進度時，發現前端已經嚴重落後，無法挽回了。
如果後端兩個人都無法支援前端 Vue.js 的部分，那還是建議使用全端開發方式，避免前端進度落後時，沒有人可以支援。
因為這個三人專案不會有專職的 PM，所以進度的掌握需要靠每個人共同努力，真的陷入開發漩渦或是有外務導致無法準時交件，儘早把問題丟出來討論，讓團隊有更多時間可以集思廣益，會是比較好的方式，畢竟最糟的狀況也就是從零開始而已，只要時間夠，沒有什麼不可能的。
感謝夥伴們
很感謝 Harry 和 Ivy 兩位願意和我組隊，也很榮幸和你們組隊。
和 Harry 在一開始的後端開發，到黑客松的全端開發，合作的過程都相當愉快，也從你身上學到很多 debug 及開發新功能的思維。一起在 Zoom 做 live debug 的夜晚、靈光一閃想到解法的瞬間、經過不斷討論激盪出的想法，到最後既使指定功能已經 delay ，挑戰題也不能輸的那種拚勁，相信這些都會是我們相當難忘的回憶。
Ivy 一開始就分享了許多業界的做法，像是後端在撈資料時可以先回傳 wait ，讓前端可以跑過場動畫等等。過程中也分享了你在公司的專案，我知道你是個在意細節且不服輸的前端工程師，如果有更多時間，相信我們可以合作完成更好的作品！
計畫趕不上變化，大概就是這次專案最好的寫照了，是吧？
後記
指定功能完成會再放上來的 😎
