此專案算是報名 AC 網頁開發課程的期末考核專案，從招募組員、開發規劃、分工討論等全都靠學生自行實踐，做出一個簡易的 twitter 社群網站。
在小組分工中，我負責後端 DB 、種子資料的實作、twitter 貼文相關路由功能、socket 公開聊天室的後端功能、測試除錯的部分。
開發前 : 尋覓組員, 確立開發模式, 確立分工模式
在 AC 學期三課程中有兩個學習分支: 全端專修、前端專修，對於不擅切板的我，選擇了能學習 MySQL、 Sequelize、資料表設計、路由設計、測試除錯等技能的全端專修。
學期三的第六週是需要自行組隊的社交週，受到學生專修人數的關係，有兩種開發模式可以選擇: 前後分離、全端開發。
覺得 AC 有提供 slack 這個交流社群非常受用，在這個疫情肆虐 WFH 普及的狀況下，透過主動自我介紹的方式很快就找到了未來打拼的夥伴，我們這一組共三個人，因為三個都是走全端專修的，因此是採用 MVC 開發模式來進行。
組隊完的假日，我們開了第一次小組會議，首先大致了解一下可以開會的時間與可以投入開發的時間，發現我與另一名組員平日要上班，只有晚上能投入開發，而另一名組員能投入的時間剛好相反!
雖然要找到討論時間看似困難，但我們還是很快有了共識，知道我們沒辦法即時的密集討論處理，因此我們盡可能在每次會議時間都把所有細節規畫好，包含: Model Entity 的屬性與命名規則、愈開發的所有路由、開發順序、工作分配、github reviewer 對應等等，讓組員都清楚份內任務，遇到問題需要討論再發到 slack 上，其他人就可以非同步處理，維持進度推進!
在開發過程中，我們使用了一些協作工具幫助開發，我們主要使用 Slack 回報進度、拋出問題；使用 Trello 安排工作任務，可視化理解開發進度；使用 Notion 定義明確資料表、路由定義規格；使用 github 管理專案開發分支、設立 reviewer 制度，在合併分支前確保有人審閱；會議部分我們有用過 Zoom與 Google Meet (小組心得: Google Meet 用起來比較順啦!)
團隊協作工具: Slack、Trello、Notion、Github、Google Meet、Zoom
開發中 : git merge 坑, 分工模式切換
開發過程中，我覺得小組氛圍是非常融洽的，彼此都很信任也常常給對方鼓勵，我們秉持著重點該放在我們有學到東西，至於成果的呈現可以放在次要，畢竟還可以再優化，至少基本的指定規格一定要完成。
我們小組都沒有實際利用 github 來進行團隊開發的經驗，我們就照著教案引導，討論出比較可能不出錯的方式管理專案。保護好 master 分支，不能任意覆寫，我們創建出另一個 development 的開發主分支(當作小組 master)，再基於這個 development 分支去開發新的功能，完成一個功能就 push 到遠端創建一個 pull request，請負責的隊友進行 review。此時隊友會先 pull 到本地端確認功能正常，再從 github 上看程式碼的異動狀況，給予反饋修正或是同意本次的更新，合併回 development 小組主分支上。
上述的流程在開發初期還滿好維護的，但是當新功能開發越來越多，專案越來越複雜的時候，我們就踩到了 git merge 的坑，後面在處理 pull request 往往會有快 10 個檔案都需要排除 merge conflic，還有許多 views 相關的頁面，都因為細節異動多導致合併困難。
後來去請教助教得到的回饋是，一般只要主分支有進行更新動作，我們其他正在開發的分支必須要進行 git pull 來更新異動狀況，在合併前就先排除掉合併衝突，若都是等到完成功能才在最後處理合併衝突，往往會耗費的心力會比想像的多，出錯率也更大，這真的是難得採坑體驗，學到了一課!!!
當我們把所有份內的路由功能開發完成後，我們估算一下測試除錯、優化UI、部屬 Heroku需要的時間偏緊迫，為了避免 git merge 在前端的部分常常有問題(因為還不清楚正確管理方法)，我們決定改變三個都投入MVC開發模式，改成讓擅長設計頁面懂藝術美感的組員負責前端UI的優化，保持開發一致性，而我與另外一名組員則負責所有的後端測試項目除錯，同時修正發現到的錯誤處理邏輯。
幸好當初我們有這麼決定，我們不擅長前端頁面的，就很努力的讓所有測試錯誤排除掉，看到所有73個測試全都變成綠勾勾的時候，真的是非常的感動! 而且組員的前端切板能力真的太優秀了，自己使用起來都覺得舒服又可愛XD。而且還特別幫小組設計了一個 Logo: MoNiEr，這個是用我們組員三個人的名字設計出來的: MOMOJ / Nina / Erwin。
開發後 : 2日挑戰功能
在完成41項指定使用者故事、73項測試規格、18頁UI頁面後，出現了為期2天的挑戰功能限時任務，在短時間內研究 socket.io 開發出三階段的挑戰功能: 公開聊天、私人聊天、訊息推播，作為加分項目。
我們小組評估似乎只有辦法在兩天內推進到第一階段的公開聊天室功能，(因為前幾天我們連續拚了40小時趕上繳交，小組已經元氣大傷)。但我們選擇把這項功能做到完善，一樣採用前後分離的方式，花一天將切板、研究 socket.io分頭進行，而這次都知道要為彼此留下串接接口，再花一天來整合串接佈署繳交。
點評那天發現我們這組的成績在全端開發小組中，還滿優秀的哈哈，沒有未達期望的項目，而靠著組員強大的介面，讓我們拿了兩項UI方面的超出期待評分。過程中收到自己小組的優化建議外，觀摩其他小組收到的反饋，也都有值得記錄可以消化的建議，最後就整理一些，這兩週認為未來還可以做更好的地方。
- 程式碼品質的一致性、易讀性、可維護性
開發過程中，我們容易因為為了先把功能寫出來，而去忽略要維持整個專案程式碼的寫法一致性，例如非同步邏輯，要使用 Promise then 還是 async/await，錯誤訊息如何處理；適當的註解也助於別人快速理解程式碼邏輯，除此之外恰當的函式命名與變數命名也都能達到一樣的效果；可以多注意是否有常出現的重複程式碼，也許可以整理抽出成共用變數或工具函式。最後就是在完成開發功能後，要把除錯用的程式碼刪除。
2. 在有時程壓力下，應該先放下完美主義，優先完成急迫需求
有時候會發現，為了解決某個使用者體驗不理想的問題上，不小心投入太多時間研究下去，導致一些該完成的功能被擱置，在投入研究前，應該要先評估一下這是否是必要且優先的項目，先處理掉那些該要完成的功能，有餘力再來優化那些項目，否則會落到兩頭空。
3. 要隨時保持紀錄備份的好習慣!!!
自己在測試除錯階段時，比較心急的排除掉所有細節問題，當時竟然沒有把每一次的修正做一個 commit 紀錄起來，等到要把隊友修正好的那些部分整合過來的時候，不小心蓋到我這邊擁有的專案，造成原本可以通過所有測試功能的專案版本，多了不少錯誤。
這個代價實在是太大了，當下覺得太對不起組員了，因為是自己的疏忽造成的問題，自己就默默崩潰，在夜裡重新除錯一遍，好好的 commit 每次的錯誤修正，還好最後有成功修復，這真的是寶貴的教訓，已經幫自己建立心理暗示，不容許這種事再犯!!!
結語:
特別感謝兩位組員，這是目前以來最好的一次專案合作經驗，沒有批評沒有爭吵，只有大量的鼓勵支持與成就歡笑。
感謝 Ivan 助教，在百忙之下協助我們解決問題，也給了一些找資料的方向與方法，跟我們相差12小時的時差，從南美洲與我們連線，聽了許多寶貴的職場經驗，非常受用。
感謝 AC 提供了這個難得的團隊協作機會，認識了新的開發模式，體驗了團隊協作的秘辛，還多認識了新的朋友建立了新的人脈。
最後
我終於從 AC 畢業啦 !~~~
