成果連結 https://github.com/Armogo/simple-twitter-vue
專案簡介
開發時程: 2週。
目標成果: 做出類似 Twitter 介面的社群軟體。
前台
- user 能夠創建新帳號
- user 需登入前台
- user 能夠更新帳號資料
- user 能夠查看推文跟其他 user 資料
- user 能夠推文
- user 能夠留言、按讚跟追隨
後台
- amdin需登入後台
- admin 能夠查看所有推文
- admin 能夠刪除某一則推文
- admin 能夠查看 user 簡易資料
我的角色
- 前端
- 協助專案git flow建置
- 協助團隊統整資訊
- 協調前後端溝通
- 協助釐清問題且解決問題
分工
前端: Vue.js 建置 SPA 作為 client side 使用介面，2人共同開發。
後端: Node.js 建置 API server，根據 client side 送來的 request 路由處理資料以及呼叫 database 做 CRUD，2人共同開發。
遠端協作
專案剛開始時，大家先找資料了解 Git flow 的概念以及 pull request 這項機制，決定在本次專案設立三類分支，master — dev — feature
設定 branch protection:
避免任一開發者隨意 push 程式碼到重要的分支，或是避免不小心 force push 覆蓋原本專案內容的慘痛狀況，如: master/main 被強制覆蓋。
要搭配 pull request( PR ) 審核機制(通知團隊中的其他人來檢查程式碼)，以此機制維護良好的程式碼品質。
Pull request( PR ):
任一開發者要將自己的程式碼 merge 進受到保護的分支前，須將程式碼交給其他成員檢查，確保每一次 commit 的程式碼品質都是符合團隊規格，減少 Git 版本管理的複雜度。
PR的使用情境大概分兩種
- 有這個 repo 的操作權，如: 共同開發者。
為了避免人為失誤影響到重要分支的程式碼(如: master)，這些重要分支有設定 branch protection。
共同開發者需在 repo 額外開一個分支撰寫程式碼，再從這個分支發出 pull request 到有 branch protection 的重要分支，由其他共同開發者進行 code review，確認無誤後才允許 merge。 - 沒有這個 repo 的操作權，屬於其他人的專案，如: open source。
若想要參加這個專案，需先 fork 該 repo 到自己的帳戶( 複製一模一樣的專案內容給自己，對方的 repo 是上游，自己 fork 回來的 repo 是下游)，在自己的 fork repo 撰寫程式碼，再從 fork repo 對上游 repo 發出 pull request，由上游 repo 的擁有者進行 code review，獲得對方許可之後才能將自己改良過的程式碼加進去這個上游 repo。
我們的前端分支
- master(main) 分支
有 branch protection。 當各項功能在 dev 分支合併完成且功能都運作正常，我們的專案成果要交出去時，才會從 dev 分支向 master 發出 pull request，將 dev 分支的進度 merge 到 master。 - dev 分支
有 branch protection。 當 feature 分支有完成新功能，就會把進度 merge 到此 dev 分支做整合測試，發現 bug 時，先在 feature 分支做處理，待修正完之後再把新的進度 merge 到 dev。 因此這個分支會有很頻繁的程式碼迭代。 - feature 分支
我自己開發功能用的分支，當小功能完成時就會對 dev 分支發出 pull request，觀察不同小功能整合之後的狀況是否如預期。 - fork repo (另外一個獨立的 repo)
另一位組員採用 fork repo 的方式，在自己的 fork repo 開發，待完成進度時再透過 pull request 更新我這邊的 repo 程式碼。
我們的後端分支
- master(main)
有 branch protection。同前面說明。 - dev
有 branch protection。同前面說明。 - branch A
組員A開發功能用的分支，同前面提到 feature 分支的意思。 - branch B
組員B開發功能用的分支，同前面提到 feature 分支的意思。
專案管理工具
- Trello
將專案拆解成小事項，以卡片顯示由哪幾位成員負責處理特定事項，方便所有人查看進度 - Slack
即時溝通以及留言 - Gather
即時語音討論以及視訊開會 - Google sheets
問題整理表、vue 組件拆分及分工、QA 測試表 - Notion
以文字紀錄開會討論事項，以及專案遇到的問題
心得:
- 協作時，資訊透明以及清晰的描述非常重要，尤其是在討論開發方向時，透過圖像跟量化的方式解說，較能夠讓大家的預期產出一致。
- 學習到專案管理的重點，在時間有限的情況下遇到問題，應區分輕重緩急，須懂得斷捨離。
不是每個 bug 都能夠在短時間內靠一己之力解決，設定停損點才是有彈性的作法。
我在這次專案當中就發生了這樣的情境，在測試 API 串接時遇到了 CORS 設定的問題，跟組員一起找了好幾天仍然無法解決，這時除了 API 串接之外，我自己本身的進度也尚未完成，但我執著在只想靠自己砸時間解決 API 串接問題，並未優先進行其他自己可掌握的項目，延誤了自己負責的進度，最終也不是由我找到 API 串接問題的解決方法，當 API 串接 debug 完成，就只剩下我這邊的項目落後，導致團隊的進度停滯不前。 - 未來我遇到問題時，會先以區分輕重緩急的策略來應對，先向團隊成員確認該問題是否能夠先擱置或協調其他人處理，優先把自己能掌握住的事項完成，避免鑽牛角尖。
- 盡可能貫徹 MVP 概念，先求有再求好，先把產品的基本流程做出來，聚焦在核心項目，再從基本流程中列出需要優化的項目。
- 使用專案管理工具的體驗，使用到很多溝通資訊的軟體，因此體驗到資訊整合的重要性，尤其是有關 bug 的處理進度跟紀錄。
我們組採用 scrum 方式，每天有使用 Gather 視訊開會討論，其他時間就用 Slack 或 Trello 留下訊息，討論過程中產生的資訊量很多樣也很分散，剛開始資訊量少，還容易記。
後續有越來越多 bug 時，每天除了新的事項要記錄之外，也需追蹤過去的 bug 處理狀況，開始產生資訊混亂的情況，組員A已經處理好某些 bug，組員B沒有掌握到這個資訊，且程式碼尚未跟組員A的版本合併，因此重覆遇到同樣的 bug，類似這樣的情況發生好幾次。
又或者，有些事項在 Slack 提出，並且在 Slack 的討論串裡有些許討論，但是忘記在會議的討論清單列出，大家就疏漏了這個項目，等到過了幾天遇到 bug 了，才想起來曾經有討論過這件事，大家又要回去 Slack 翻找討論記錄，並且努力回想當時處理到哪個階段，多費了好大的心力。後來我們改善資訊整理的方式，任何問題跟進度都盡量集中在開會記錄跟 google sheets 這2個頻道，讓大家以查看這兩種工具為主，確保最新資訊同步。
Slack 作為留言工具，以簡短的說明搭配網址連結，使所有人可以直接跳轉到開會記錄或 google sheets 做進一步了解或編修，從而讓資訊的源頭保持集中，較好維持資訊同步。 - 評審在點評時有提到前端要適當顯示提示訊息，良好的UI/UX除了介面美觀，也注重 user 在操作時能不能獲得清晰的回饋資訊，這一部分也是得好好琢磨的方向。
Hackthon挑戰賽
利用周末時間，以團隊形式共同研究某一技術，並且在原先的 twitter 專案實現，增加即時傳訊功能。
簡介
這次挑戰主題是 socket.io ，是讓 browser 跟 server 能夠即時且雙向溝通事件的技術工具。
在原先的 twitter 專案，我們都是以 client 的 browser 發出訊息，server 被動接收到 request 後才有對應的 response，流程如下:
client A 觸發事件 → 通知 server → server respond 特定事件 → client A 得到 response
Socket.io 使用 Websocket 連線協定或是HTTP long polling，目的是讓 client 跟 server 之間具備低延遲跟全雙工( full-duplex ) 通訊。
全雙工使 client 跟 server 之間可以在同一時間雙向處理傳輸資訊跟接收資訊的行為，client → server 跟 server → client 這兩件事情可以同時進行。
應用在我們的即時傳訊功能，當多個不同的 client 發送即時訊息時，server 能夠一邊接收來自不同 client 的訊息，一邊把訊息傳送給指定的 client 或多個 client，做到 server 主動傳訊到 client 的行為，流程如下:
同時間
client A 發出通知 → 通知 server → server 通知 client B → client B 收到通知
client B 發出通知 → 通知 server → server 通知 client A → client A 收到通知
心得:
- 挑戰賽的時間比起 twitter 專案更短，並且是我們從未學習過的技術，鑒於之前有專案延誤的經驗，我們後端的組員就提早開始研究 socket.io。
socket.io 是用事件溝通，因此 client 跟 server 在傳送跟接收資訊的事件名稱要完全一致，我們強大的後端組員就順手把 server side 跟 client side 要用的相關程式碼都寫好了，感激涕零! 感激涕零!
令人扼腕的是，我這邊因為還在補前面落後的進度，使得挑戰賽的前端介面最終無法在時限內完成，沒把後端組員的心血結晶充分展現出來，真的很慚愧。 - 因為前面進度落後，導致挑戰賽也做不完的結果，再次警惕我面對問題時要有策略，輕重緩急一定要分清楚，避免拖累團隊。日後必定會面臨無數種情境，我應時時變通，也需跟團隊保持流暢的溝通，讓團隊即時提供支援。
