Twitter 專案開發回顧

整個 Twitter 專案開發經歷了整整兩週，這也是我的第一個協作專案，整個過程都很有趣!因為想記錄的東西太多了，就直接用流水帳的方式呈現吧!

開發模式: 前後分離
前端組員: YT、Ziwen
後端組員: Ruby Lo、我
專案連結: 前端、後端
專案成果: link

尋找組員

感謝 Ruby 早早就來找我組隊，再來就是感謝無緣的 TzuChi 同學了。從學期二開始，觀摩作業就有注意到他了，前端畫面常常都會有美美的優化，趁著這次協作就跑去搭訕他，可惜他在開始前有事退出了。不過也多虧他牽線，讓我和 Ruby 遇到了負責、可靠又好相處的兩位前端夥伴 —— YT 和 Ziwen。

協作工具選擇

專案開始前其實大家都處於一種水深火熱的狀態中，同時要完成學期三的課程進度，又要開始閱讀 Twitter 專案的相關文件，再加上是第一次協作，其實我們連要用那些工具都沒有頭緒，最後是依照組員各自摸索、列出各項軟體初步使用感受後討論出來最好上手的工具。

通訊軟體(Discord、Google Meet)

我們在 Discord 裡自建了伺服器，利用身分組和頻道類別功能把前後端討論訊息做分流，避免組員被大量訊息轟炸，另外也用討論串功能依主題集中資訊；而語音頻道則是用來做簡短的臨時討論。視訊會議軟體則是因為 Zoom 免費版有會議時長限制，我們改用 Google Meet 作為主要工具。

小組 Workspace 整合(HackMD)

我們選了 HackMD 作為整合工具，有支援團隊協作功能、使用直覺，而且只要會寫 Markdown 就沒什麼問題。實際使用下來組員們上手非常快，所以利用率也滿高的。開發過程中，後端也用 HackMD 來製作 API 文件供前端參考，即時更新的情況下，前端能有效率的知道回傳資料結構、能拿到哪些資料、以及針對回傳內容跟後端做討論。

進度管理工具(Trello、Google sheet)

可能因為在 Discord 有做每日進度回報、即時討論，所以大致都能瞭解對方狀況的關係，我們小組對 Trello 的更新反而比較不及時。而 Google sheet 則是針對 API 路由的開發狀況、負責組員、文件完成與否、部署到 Heroku 了沒都有紀錄，算是後端更新最即時的工具。

我在協作中負責的工作

專案開發部分

1. 專案初步建置(資料 modal 建立、登入/註冊功能開發)
2. admin/like/followship/tweet 相關路由開發
3. Heroku 部署
4. 種子資料、文件協作

功能開發過程中其實沒有遇到太大的問題，唯一卡關比較久的的就只有登入功能(說明連結)，其他就是要時常提醒自己: 「我只是個處理資料的 API」。在前幾個學期的學習過程中，因為同時要做前端畫面的開發， Twitter 專案初期有時候還轉不過來，偶爾會以畫面為基礎來思考，到開發中期時終於完全調整過來。

小組支援部分

1. Discord 伺服器規劃/建立
2. 小組 Workspace 建立/整理
3. AC 交作業
4. 前後端串接溝通

在功能開發分配上，我份量較重的功能比較集中在專案前期，所以中後期的工作比較著重於小組支援上。像是資料整理、處理前端提出的問題和 API 調整。

協作後的反思

組員間溝通和配合

和後端組員 Ruby 在整個過程都沒有太多的障礙。可能因為都是後端學員，能夠很快理解對方在說什麼、卡到的點在哪裡。而且她也對我很包容，在我卡關焦慮的時候給我鼓勵、耐心等待，也試著一起找出解決辦法。 code review 的時候也會很細心的閱讀我寫的內容，然後一起討論為什麼要這樣寫、考量的點是什麼、有沒有更好的做法。

之前的學長姐分享有提到前後端協作會有「聽不懂對方在講什麼」的時候，我們小組對於這個狀況的處理也很有趣。我們會先用文字說明方式試圖讓對方理解，如果不行就再搭配圖片，如果還是不行就會分享教案連結或其他輔助資料幫助對方理解。有時候結論就是: 你們前/後端好強好辛苦! 🤣

哪些地方可以做得更好?

• 變數命名統一
  前後端在開發初期沒有對變數命名進行統一，所以中後期有段時間大家會針對命名部分不斷修改。如果能在開發前達到共識，就可以減少溝通成本，進行更有效率的開發。

• 發 PR 前更仔細檢查 code 內容
  細心的 Ruby 在看 PR 時常常能找到我粗心的一些小錯誤，這也間接造成我們的 commit 記錄因為這些修正變得不夠乾淨。在獨立開發的專案上，可以用很多方式來整理 commit 紀錄；但在協作專案修改 commit 紀錄就不太適合了。這次經驗也提醒我，應該更細心地對待自己寫出來的 code。

• 縮減 PR 粒度
  前期的 PR 一次會包含很多功能，造成 reviewer 比較重的負擔。可以適時調整每次 PR 的內容量，讓 reviewer 可以一次專注在一件事情上。縮小 review 範圍也能減少出錯機率!

怎麼確保協作順利進行?

第一溝通! 第二溝通! 第三還是溝通!

製作文件資料

其實我們小組的開發前期，前後端有點「各自為政」，各自專注在自己部份的開發，前期並沒有太多的進度交流。但我們會為了讓對方理解自己的需求，先做出相對應的資料給對方參考。像是前端就做出了整份文件，讓後端可以清楚知道各個畫面依照切版可能會串幾條 API、而各 API 會需要哪些資料。而後端則是先提供 API 清單，列出每條 API 功能及預計產出資料，單項 API 路由完成時也會即時製作文件給前端了解回傳資料結構。

需求/能力互相協調

協作的小夥伴們在遇到問題時都會及時表達，不會一個人埋頭苦幹。在提出討論後，我們會依各自的能力互相支援。例如: 後端為了配合自動化測試，對變數命名跟回傳資料結構都有硬性要求時，前端都會很迅速地調整配合；而前端提出資料排序、計數…等資料處理較困難後，後端也會主動提出可以回傳處理過的資料給前端。因為在學期三專修的是不同方向的專業，對對方能做到什麼其實不是很了解，但藉由這樣直接的溝通，讓我們的分工更有效率也夠輕鬆。

問題溝通

當串接遇到問題時，我們都會馬上提出互相討論，然後找出問題發生原因。有一次前端提出無法接收到後端的錯誤訊息，就先互相實驗，找出問題是發生在前端還是後端。之後雖然發現是前端 axios 攔截錯誤訊息，但前後端夥伴都會保持問題追蹤，然後一起想辦法解決。

藉由協作專案學到什麼?

Git 與 Github 操作

以前獨立開發時，從來沒有碰過 pull request、開很多分支，這次在協作中做了很多的練習。後期進行 debug 和優化時，也和 Ruby 一起試著使用 Issue 功能來做 task list 管理。真心覺得 Github 做了很多針對協作的方便功能，在這次協作中的嘗試學到了很多!

溝通的方式與重要性

怎麼說明可以讓對方理解我想表達的東西? 怎麼提問能讓對方知道我卡在哪裡? 怎麼對開發夥伴求救?
這些問題在開發過程中都經過很多次練習，也藉由良好的溝通解決了很多問題。

放寬視野

在前後端串接時發生了一些問題，而參與解決問題的過程也能讓我注意到: 我的專案使用者可能會碰到什麼問題、發生的原因是什麼。了解除了專案本身以外更多面向的知識，也能讓我在以後做其他開發時能有更全面的考量。

小結

這次的協作是個很棒的體驗，學到如何有效溝通、時間管理、新工具應用…等。很幸運能遇到超棒、超 carry 的神仙隊友們，整個協作的過程都非常愉快!

隊友們的部落格

• YT - AC 畢業專案 Simple Twitter 開發心得
• Ziwen - AC_Simple Twitter 專案體驗
• Ruby - ALPHA Camp畢業專案 - Simple Twitter 專案回顧與反思

文章內容如有錯誤，歡迎留言討論！