Alpha Camp 學期三團體專案回顧
從 0 到 1 的專案開發心得
在 Alpha Camp (AC) 第三學期的 Simple Twitter 專案中，我們團隊採取前後端分離的開發方式：
- 後端開發：利用 Node.js 和 Express 框架建立 API 伺服器
- 前端開發：利用 Vue.js 建立頁面並串接 API 取得資料
最後，再將前後端成果結合成一個具備基本 Twitter 功能的平臺。
我的開發角色
在團隊中，我是後端 API 開發的其中一員，負責開發以下功能：
- 一般使用者功能：取回及編輯使用者資料、對推文及回覆按讚或取消讚、取回使用者按讚或回覆的推文
- admin 管理員功能：取得所有使用者資料、取得所有推文資料及任意刪除推文
前後端串接完後，我和另一位後端開發成員 Jessie，一起依據 AC 提供的檢查表確認成品是否如預期正常運作。
另外，進行 socket.io 挑戰題時，我先依官方教學文件建立初步的實驗環境，發佈到暫時性的 ngrok 公開伺服器，讓團隊成員體驗、觀察 socket.io 的運作方式。後續正式開發則由 Jessie 為主力。
完成專案的關鍵
回顧兩周精實的開發過程，整理了一些我自己覺得專案能夠順利前進的關鍵。
強力組員及助教支援
Jessie 在工作上已經有開發經驗，很迅速地為全組規劃了開發時程，讓大家能有立即可追求的目標，減少猶豫的時間。而且具備豐富的技術能力，在我們其他新手組員遇到技術問題時，也能跳下來跟我們一起討論、排解，順利推進開發進度。
Eli 獨自負責前端開發。由於我和 Jessie 對於前端工具了解有限，Eli 自行解決許多排版和串接問題，最終成果令人驚豔！
更棒的是，我們也從團隊助教 Eugene 得到不少開發的線索，在解決部署、資料庫使用、前端處理上有很多收穫。
前端引導後端
由於前後端各自開發，要順利將雙邊成果整合在一起會是個潛在難點。
參考了先前的學員專案開發心得後，發現一項很好的建議：
以前端為主，讓前端需求引導後端實作。
由於最終成果是以前端頁面呈現，再加上前端開發只有一人負責，由後端二人協助滿足前端需求會更有效率。
試想，如果後端提供的 API 不夠友善、方便，前端還得花更多心思串接和處理資料，一定會影響整體進度。
多面向的溝通管道
團體專案完全採遠端協作，我們大量使用 Zoom 和 Google Meet 進行視訊或語音溝通。
Google Meet 很適合開發時長時間掛在上面，一有問題可以直接透過語音和組員溝通 (類似在公司隨時用內線打給同事的感覺)。
如果覺得語音溝通不夠清楚 (例如要看 code)，會再轉用 Zoom 或打開 Google Meet 的分享螢幕來討論。
專案一開始，我們就立刻用 Zoom 開了第一場視訊會議。雖然當時的討論沒有觸及太多細節，卻是透過影音認識團隊夥伴、建立團隊連結的好機會。我想，這也是開發時相處的很不錯的原因之一。
我們也在 Google Doc 上建立 API 文件，紀錄呼叫 API 的路由、參數、回傳結果和錯誤訊息。前端能夠藉此確認回傳的資料和格式是否符合需求，也能了解有哪些錯誤訊息可以利用。後端修改程式碼時也不致於亂了頭緒。
再次體會到，API 文件在團隊開發中不可或缺，是所有人開發時的最終依歸。
AC 推薦使用的 Basecamp 群組也是我們常用的服務：我們在上面匯整了重要開發資源，方便隨時使用；如果進行沒那麼即時的交流，通常會在上面留言、討論。
技術學習
專案實作過程中，對於先前所學有更加深入的理解，同時也學到新的技術。
非同步 Promise 及 async… await 語法
實務上必須和資料庫溝通和使用外部服務，幾乎都脫離不了非同步處理。累積了大量使用非同步 Promise 和 async… await 語法的經驗。親身體驗到非同步語法真的很重要！
多虧專案中有大量實作，現在更能掌握非同步處理流程。Promise 也不再感覺那麼虛無縹緲。
Git 協作流程
在專案前期，為了讓自己本地的程式碼和團隊 repo 程式碼同步，總是得先把自己本地的專案資料夾整個砍掉，再用 git clone 把團隊 repo 內容下載到本機。
反覆幾次，實在是覺得效率低落且無比麻煩，而且每次都要重新建立 .env 檔案內的設定。(抱頭)
後來，查了資料後才更清楚如何用 git fetch 和 git merge 來整合本機和團隊的程式碼，用起來非常方便！整合程式碼後，就能順利開啟 pull request 把更新內容推上團隊專案 repo。
果然是有痛點才會有成長動力！
自動化測試
由於 AC 要求專案的最終結果必須通過自動化測試，因此也額外學了如何理解測試程式碼，推敲出我們如何處理資料和設定資料庫。
例如，回傳單筆資料時，測試希望直接回傳一個物件，而非一個內含物件的陣列。
為了通過測試花了不少時間，但認識了自動化測試也算是值得 (只要沒有耽誤到開發進度)。
後端開發思維
開發時觀察到，後端程式開發時採取限制導向的思維。裡面通常會加入不少限制。例如，推文內容不能超過 140 個字元、某些欄位必填等等。如果傳入的請求沒有滿足這些限制，不會執行接下來的程式碼，或是不會和資料庫進行溝通。
前端頁面其實可以執行不少檢查。然而，後端程式作為與資料庫溝通的最後一道防線，還是要設下檢查機制，避免使用者繞過前端頁面趁機存取敏感資料。
假設，某使用者猜出 URL 代表的意義，可能直接輸入帶有特定參數值的 URL。如果後端程式沒有加上必要的限制條件，使用者就有機會動用資料。
設下限制的額外好處是：當請求沒有通過限制時，也就不需動用資源和資料庫溝通，減少不必要的問題發生。
請求沒有通過限制時，我們也儘量提供客製化的錯誤訊息。不僅方便前後端開發時除錯，也能給使用者明確的回饋，強化使用體驗。
另外，回傳資料給前端時，也得避免回傳密碼等機密、敏感資訊，避免資料曝光。
資料庫併發問題
有趣的是，在開發時遇到了從來沒有想過的併發 (concurrency) 問題：
當使用者 A 修改某筆資料，同時使用者 B 剛好在讀取同一筆資料。如果修改和讀取時間極為接近，可能導致使用者 B 讀取到修改前的資料，產生資料不一致的問題。
經過團隊助教提醒，Sequelize 提供某些能夠直接將改動寫入資料庫的方法，能夠避免併發問題。不需先從資料庫拿到資料，在伺服器端修改，再等待資料庫寫入。
如果能再重來
首先，希望自己可以早點研究 socket.io 的用法，有助推進團隊在挑戰題的完成度，也能多分擔一點開發進度。
另外，也希望減少熬夜寫 code 的次數。由於全職工作，無法每天抽出大量時間進行專案，雖然請了幾天假，但平日還是得靠熬夜撐出寫 code 的時間。
即使發現熬夜好夥伴 — 維他命 B 群 — 能夠緩解熬夜的不適，但次數一多，還是會累積不少疲勞，讓頭腦愈來愈不清楚。
頭腦清醒的話，整個開發過程應該會更輕鬆、愉快，效率更好。
結論
這次 Simple Twitter 專案是非常難得的實作經驗。完整感受從 0 到 1 打造可運作產品的不確定感、成就感和有限時程帶來的壓力，規模也比以往作業都大上不少，是更接近業界實況的實作。
其中感受最深的是團隊合作：每個成員都是專案中不可缺少的一部份，有自己獨特的貢獻。
面對壓力時，我們能夠理解彼此的辛苦，所以能夠體諒和給予支援，帶來很多的團體凝聚感和同理心運作體驗。
對於寫程式開發產品，有了更深一層體會：
不僅要單打獨鬥，更需要團隊合作。
最後，還是要感謝團隊成員 Jessie 和 Eli。沒有你們，專案不會如此順利。
