目錄
-專案簡介
-工具使用
-分工
-黑客松
-反思
-後續已優化
-其他組員心得專案簡介
前端repo：tzynwang/simple-twitter-frontend (github.com)
後端repo：JHIH-LEI/twitter-api-2020 (github.com)
live demo：Home | Simple Tweet (tzynwang.github.io)
測試帳密：user1 / 12345678
本次專案採前後端分離的方式，開發分為兩階段，分別為第一階段的指定功能，必須完成 Alphacamp 要求的 User story 和通過所有測試項目才算過關；第二階段則是挑戰功能，Alphacamp 會在開發期間的最後一個週末公布詳細的規格，必須使用從來沒學過的工具，在短時間內實作全新的功能。
前端使用Vue，後端則用Nodejs搭配Express框架＋SQL資料庫（後續已加上Redis作為緩存），並根據 RESTful 的風格設計 API 給前端組員使用。
工具使用
溝通工具
文字：slack
語音：Gather Town用於討論使用（Debug..）
協作工具
開發：git、github、postman
API文檔：apiary
Debug
ngrok，在一些地方埋console.log和前端一起測試。
宏觀分工
查理 & Raven 前端開發，Whaleep和我負責後端開發。
前端在黑客松的分工是一人先負責畫面切版，另一人先負責邏輯撰寫，後續因為時程關係，兩人皆投入邏輯撰寫，這邊先感謝前端夥伴們，在開發的過程中完全可以很放心，前端都不會出前端專業的包，整體開發過程很順暢。
在後端分工中，我是主要開發者，同時協助團隊降低共識成本。
Ex: 幫忙開when2meet、雲端、API文件這些比較文書的處理，這些基礎建設能增加團隊討論的效率，確保訊息一致。
美中不足的是我們沒有串接機器人到slack，變成我們需要人工去群組告訴大家「已經重新推上heroku」、「請求接受PR,幫我merge到develop」。
微觀後端分工
開發前
先把測試檔都看過一次，了解這次開發的根本目標為何（要達成哪些測試、各有哪些標準），並同時把測試路由寫入分工表及文檔中，避免路由設計與測試檔不相符。
開發過程-分工方式
分為基礎建設以及路由，基礎建設包含github設定、Heroku、Model..。
基礎建設
主要是我負責處理，因為是基礎建設，所以蠻快速的。沒什麼大礙。
路由分工
一開始這些路由都是來自測試檔，後續則是因應前端的需求而衍伸出來。
在路由開發上也有邏輯先後，方便手動測試，例如，要先有註冊跟登入路由，才有推文相關路由。
當完成一條路由後，會先進行手動測試，盡量把他玩爆，確定玩不爆後就跑自動測試，沒問題後才PR，並更新API文件、Excel分工表，並把測試結果放在Note，讓夥伴知道這真的有跑過測試，前端夥伴也能即時看到最新狀況，不須問說哪一條路好了沒，畢竟一問一答很沒效率。
＊補：在開發過程中，除了對照測試檔，也會對照User story以及UI，確保沒有miss掉的需求
開發過程-當有BUG發生
原則上誰的鍋誰來修，但有些屬於急迫性的，我就會直接先修。在專案開發的過程中，BUG都比較單純，通常都是資料需求，所以改很快。
結果
通過所有測試！而且很快就開發完畢～提早去研究挑戰功能。
黑客松
雖早有耳聞websocket的機制，但先前完全沒有應用過，所以socket.io對我來說是陌生的，一開始花了很多時間在搞懂背後的機制，當實作出來完整的公開聊天室其實就很快了，之後的邏輯都大同小異，只是多了房間跟socketId的概念。
在通知的邏輯上也比我想像中的簡單，不過單純只有後端自己寫簡單的view來做測試是不夠的，往往會有漏網之魚，要跟前端一起測才會發現有缺漏的地方，但這些bug修正很快，都只需要加一兩行程式碼就能解決。
整個過程最好玩的是跟前端一起Debug的時候，彼此都會把邏輯在順一次，猜測問題出在哪，往往猜的很精準，我們很多新的寫法都是從這個過程產出的，因為前端有個新的需求，我就想要怎麼實踐，有哪幾種方式、翻官方文件，然後去應用他。
實際前後端需求討論過程
「前端希望在關掉視窗的時候，後端也會emit離開聊天室訊息事件」。
這個需求一聽到就會知道要從disconnect事件開始著手，這個需求蠻簡單的，不過做好沒多久前端又加上一個條件，反正就是說：
「前端也會去實作這一塊，所以會造成二次發送離開聊天室的錯誤，後端要先判斷前端是否有觸發過離開聊天室的事件，再決定要不要幫忙emit」
聽起來好像很複雜？但其實很簡單，當下我想了三種方式，1.比對資料庫2.檢查在線名單3.官方提供的寫法，最後我秒選3，因為簡單很多也比1有效率，我只需要在加上if socekt.room.has(1)就好了（1代表公開聊天室）。
結果
黑客松三天後端有把通知功能做出來，但因為大家最後共識是專注完成公開與私人，所以我就先放下通知相關事宜，專注完善團隊目標。
我們最後完成前後端合作的為公開聊天室、私人聊天室。
反思
從這個專案得到的收穫…
- 前後端分離的協作經驗
- 認識TDD
- 對於SQL原生語法更加認識，ORM畢竟還是有他的限制，有些處理要仰賴SQL語法，像是想根據Boolean做排序。
- Status code也是從這個專案才可以刻意練習的，詳細可以看這篇筆記
- 對於儲存資料的格式有更深的認識。在專案中有些情況與其用陣列還不如用Map，像是在實作判斷使用者到底有無完全離開聊天室時，我是用Map來操作，Key存使用者的ID，Value用Set的格式，放該user的socketId，藉由判斷是否有set，從而得知是否已經達成emit離開公開聊天室事件的條件。
- socket，對於這種不用仰賴req, res的即時網路傳輸協定有初步的認識了，畢竟有用過才會體會。
- 如何管理Heroku同一專案兩個遠端的情況
- 在各個方面都更加進步了，像是API的規劃、git使用、passport的機制…
收穫真的太多了..這邊列舉下來好攏長，來講講心態上吧，他讓我更加確信，做side project可以進步更多，可以刻意練習要學得新技術，這才是真正有效的學習方式！
可以更好的地方
- 在Socket協作上，應該先取得資料共識。雖然後端有先將事件跟資料定義好，但是做完才發現前端可能還需要一些資料作為方便渲染使用，這樣一來一往其實蠻沒效率的。
- 優化資料讀寫的效率。1.使用Redis緩存2.運用Pagination機制，不一次撈出大量資料 3. 撈資料時加上時間限制，以社群媒體來說，我們不太可能會去滑到兩個禮拜前的貼文，那這裡就可以用類似的時間點做切割。
- 資料驗證，與其用手刻，不如仰賴一些套件。
- 沒有考量到SQL injection的情況
- Error handing改用維護性較高的寫法，例如Class。
還要在磨練的地方
- 程式碼封裝。我可以確定如果需要重複使用的就一定要封裝起來，Don’t repeat by yourself~但有些地方我還不太懂怎麼拿捏，像是有些code比較攏長，會影響易讀性，原本我是用註解的方式，但助教說如果能封裝成語易化的函式>註解。這我也很認同。再來，有一些我以為很棒的封裝，卻被助教點說業界上不會這樣做，像是turnToBoolean這支函式，我會將0,1轉成布林值方便前端使用，但這樣似乎會造成Debug變得困難。
- 當專案變複雜時，資料表之間的關聯也變得更加複雜，我有時就會不知要怎麼妥善的設定兩表之間的關聯。
- Javascript的一些Advance用法還需熟悉
後續已優化
重構程式碼->持續進行
撈推文的時候做時間(只撈最近7天的推文)限制，增進效能
使用Redis緩存一些資料，像是所有推文
