Photo by Helena Lopes on Unsplash

[團隊協作] 14天打造社群聊天平台

De_

--

這次的專案使用了 Vue.js 和 Express.js 這兩個開發框架,用前後分離的方式進行開發。團隊成員總共有四人,兩人負責前端,兩人負責後端。

還記得專案一開始雖然有提供設計稿和User Story,但因為是第一次進行協作,有點不知該從哪裡下手。像是突然中了一百萬,你拿著白花花的錢卻不知道要從何開始花起 XD。

在第一次討論後,我們讓前端先把需要的資料整理出來,後端則是依照測試檔的規範命名先把需要的資料模型(Model)建出來,並且完成使用者的驗證機制。在前端資料準備差不多後,後端再一次確認資料有沒有問題(像是路由命名、資料名稱和測試檔是否一致),確認好就開始進行正式的分工了!

基本功能

前端的分工以頁面作為單位,後端則是依照 api 路由進行分配。團隊溝通的主要平台是Slack,另外使用 Trello 追蹤進度,上面分了不同階段,以後端來說可以分成正在開發中、正在處理測試問題、測試成功等前端串接等區塊。每隔 2-3 天進行一次視訊開會。

我主要負責 Tweet, Reply 和 Like這三個路由以及種子資料撰寫,過程都還算順利,偶爾會碰到一些資料庫操作的問題,透過 StackOverflow 大致都能夠解決。我和同伴主要都是卡在測試的問題,像是測試時明明console.log能夠印出id,可是卻一直報錯說抓不到model的id等,在自己嘗試幾次無解後,我們會在Slack上互傳截圖,看對方程式碼哪邊寫錯。

雖然因為卡測試的關係,一開始後端開發進度有點慢,不過也在解決問題的同時我漸漸知道要怎麼看測試檔,在後期串接 api 時,前端曾提出一些資料格式上的要求導致測試檔沒過,這時因為看得懂測試檔的要求,我能很快發現問題是出在哪裡。

在開發差不多以後,後端先進行code review,我主要做的事情如下:

  1. 統一錯誤回應
  2. 清除沒有用到的變數、引用、或資料的撈取
  3. 重構程式碼 (e.g. 資料操作全部改成在資料庫進行,而非整包撈回來整理callback改寫為promise語法)
  4. 查看程式碼是否符合規格要求並補上少寫的判斷 (e.g.管理者和使用者登入分流)

完成到這邊大概過了一周的時間,接著將api 伺服器放到Heroku讓前端串接

剛串的一開始就遇到跨來源問題(CORS)以及資料格式抓不到的問題,當下我還很擔心又要花時間來debug,幸好加上套件後就都解決了。

前端串接被CORS Policy擋下來

前端順利接到 api 後接著就是不斷溝通、更改程式碼的過程。

需要溝通、更改程式碼的原因主要可以分成三種:

  1. 因為測試檔要求,有些資料名稱有更改,但是後端沒有通知前端,導致串接有問題
  2. 前端在實際串接後想多撈資料
  3. 前後端預期的資料格式不同 (e.g. array vs. object)
  4. 後端功能出錯要改

在渲染頁面時前端有自己的需求,後端則是在測試檔能通過的前提下配合前端修改。

這邊也特別感謝前端同伴的細心檢查,有發現後端出錯的部分,像是撈model的關聯設定時指令寫錯導致無法撈出正確的資料,不然我不知道要到什麼時候才會知道原來這種寫法是行不通的。

串接完成後就是 Do re mi so~ 如同本文第一張照片的樣子!

個人資料頁面

挑戰功能

基本功能完成後,我們團隊又繼續往下做了挑戰功能,也就是公開聊天室。之所以會說是挑戰是因為這個功能使用到了socket.io —我們過去從沒接觸過。

連線卡關

一開始團隊先花了一些時間研讀官方文件,在本地自己生出畫面嘗試傳遞訊息,接著再進行前後端連線,和第一次串接時很像,一連線就遇上問題,不過這次是根本連不到線。折騰了好一陣子才發現原來是前端連線的網址和後端提供的網址不同XD

驗證機制

連線成功後再來處理驗證問題,這裡我們使用第三方套件passport-jwt.socketio,驗證成功後使用者資料會放在socket.handshake.user物件中,用這個套件的目的除了驗證以外,也是方便我們將使用者資料傳到前端給他們渲染。

完成後的畫面長這樣,從上面敘述來看這個功能好像很容易,但是中間我們看官方文件、本地自行測試、連線卡關,處理驗證還有畫面等也是花了兩三天的時間才完成。

結語

經過兩周的時間,很開心終於把這個專案做出來,當然這個專案還是有許多進步空間,像是程式碼架構可以再優化,聊天室也可以再繼續挑戰私人一對一功能等等,這部分我們將會持續優化。

如果有機會能夠重新做一次專案,有幾點我覺得是可以先改善的:

  1. 寫程式碼之前,架構事先劃分清楚,比方將錯誤判斷和資料庫操作分開放,提高程式碼的可讀性。
  2. 在看前端需要的資料格式時,如果有發現不同頁面重複撈取同一份資料,可以先和前端溝通,看是否能以重複的資料作為撈取的單位,而不是以一個頁面所需的所有資料當作單位。如此可以減少一次資料的撈取量,增加效能。
  3. 規格前後端一開始定下來之後不要輕易更改,若真的要改要記得通知另外一端,減少溝通成本。

以上就是本次團隊協作的紀錄,若對專案有興趣可以點擊 github 查看更多資訊,也歡迎留言分享想法!

--

--

De_
De_

Written by De_

Who dares, wins. | Backend Engineer | Voracious Reader | Dog Person | Open to challenge

No responses yet