快轉到主要內容
  1. Posts/

ALPHA Camp 學期三 Simple Twitter 協作專案

·353 字·2 分鐘
Justin Huang
作者
Justin Huang
Senior Software Engineer@Delta Energy

前言
#

終於來到了學期三期末的協作專案了,這個專案可以選擇用熟悉的全端開發架構,或是使用初接觸的前後端分離開發架構,打造 SPA (single-page application)。不過由於這屆前端課程的同學很少,所以多數組別都是使用全端開發架構,我跟 Harry 很幸運找到一位前端的夥伴 Ivy 組隊,終於可以體驗一下傳說中的前後端分離開發架構啦~

基本分工
#

前端 Vue.js 由 Ivy 負責,後端 Node.js + Express.js 搭配 MySQL 由我(兼組長)和 Harry 負責。由於 Ivy 是在職前端工程師,所以已經預期會有部分前端刻板工作需要後端支援。 我和 Harry 在後端的分工一開始是滿隨意的,直接用 User Stories 來分,誰做得快就先做,但第一次 merge 時發現這樣衝突會很多。為了避免花太多時間在解這些 conflict ,決定由 Harry 先把 Model 建好,而我先寫註冊登入登出驗證等跟套件相關的功能。

協作方式 & 工具
#

組長的工作其實就跟 PM 一樣 (剛好我前一份工作就是 PM),所以要負責向 AC 回報專案進度、溝通專案問題等工作。

除了分工,協作的方式也很重要,如何讓夥伴們順利地執行專案也是組長的責任,這邊介紹一下我們選擇的協作工具:

  1. Slack 主要使用 backend, frontend, general 這三個 channel 來討論,並將 Trello 整合進 Slack,同時也把常用的文件連結用 PIN 功能儲存起來,方便大家查找。

1_fylAkCAHc8Tvo4OdSVUP6g

\2. Google Docs 將 User Stories、Tech Hour 討論結果、測試問題等資訊記錄在這,方便共筆。

1_mVfdd5NA9Y5ZaYfDmPGcEw

\3. Trello 把 Google Docs 上的工作標題轉換成一張張卡片,可以一眼看出大家正在做的、和已經完成的工作。

1_ZLFCwmBo0TjFBC93s4agEg

展開兩週的開發之旅
#

指定功能 & 後端 debug 地獄
#

Simple Twitter 開發的要求分為指定功能及挑戰功能,指定功能除了正常運作之外,還要能夠通過 AC 撰寫的自動化測試。

剛開始和 Harry 兩個人花了三天照著自己的意思把後端 API 建置起來,信心滿滿的跑自動化測試,跑完看著滿江紅的終端機畫面,當時還覺得很有趣,想說靠怎麼沒有一條路由是通過的 😂,殊不知自己正踏入 debug 地獄中…

bug 的分類大概可以分成三種:

  1. 自動化測試本身的 bug 這種 bug 會耗費最多時間,因為自動化測試的程式碼是用 mocha, chai, sinon 等測試套件或方法寫的,之前也沒學過,所以只能盡量閱讀這些程式碼,看久了會發現一些重複的關鍵字如 should, equal, expect 等等,就就可以大概猜出意思;再來是從錯誤訊息中尋找線索,加上在自己的程式碼和測試程式碼中用 console.log 來除錯。真的有發現錯誤就要趕快回報給 AC,避免卡住專案的進度,通常他們會儘速修好然後發佈更新版本(有時更新了會出現新的 bug 😵)。
  2. API 回傳的資料與測試要求不符合造成的 bug 這種 bug 通常可以從錯誤訊息及自動化測試的程式碼中發現,像測試的要求是回傳一個陣列,但我們回傳的是一個物件,那就會出現錯誤。
  3. 神奇的 bug 這次每一組都有遇到 Like Model 的 id 在跑 SQL 時無法自動讀取,造成自動化測試一直失敗的狀況,在兩個人 debug 許久後,我強大的隊友 Harry 想到直接把 id 手動寫進 model 的方法,才成功通過測試。向 AC 回報時,維元老師看了也是嘖嘖稱奇,只能說程式的世界真是無奇不有 🤔。

1_G7Br5dze8LVjHYJnzMzL6Q
Reply Model 會自動 INSERT id

1_zy0GP_qbPABjGa49Spp3pQ
Like Model 就是不會…

後端經歷過整整一週兩個人每天開 Zoom 分享螢幕進行 live degug 的 debug 地獄之後,終於迎來了全數通過自動化測試的這個 moment,眼淚差點都要滴下來了 😭,但是專案還沒結束呀,還要繼續衝刺才行!

1_kLk8UfoedGVRj5xK7-rYEw

部署 API server
#

部署 Heroku 的過程也是花了比預期多的時間,主要問題在於環境變數 NODE_ENV 的設定,短短 3 行 code 寫了 3 個小時…只能怪自己忘記 Heroku 還有 Procfile 要設定 😵。

1_YlJ1hPPSjtNTSeB84d5nNw

1_L3CU729g_3JYTE8ERU0lRg

挑戰功能:即時聊天室
#

指定功能的開發及 debug 就耗掉了一週的時間,加上有些 bug 需要等 AC 更新才能繼續開發,所以在等待期間我們也沒閒著,持續研究 ngrok 及 socket.io 的用法,我也順手將 ngrok 的設定過程寫成懶人包供大家參考。

5 分鐘完成 ngrok 設定(Mac) *ngrok 是一個可以快速讓外網連接本機 localhost 的工具,話不多說,六個步驟帶你快速完成設定!*medium.com

過程中前端夥伴因為工作關係無法準時完成進度,加上我和 Harry 都不諳 Vue.js ,只好當機立斷,臨時改用全端開發架構來完成即時聊天室。

挑戰功能是採用黑客松的方式,在 48 小時內盡可能的開發,所以改用全端開發架構也代表,我們需要從零開始刻畫面並且在 48 小時內完成 😵,由於我在指定功能階段就有支援前端一些簡單的畫面,所以畫面由我負責,Harry 則基於我們之前研究的 socket.io 基礎,繼續開發私訊、通知等其他功能。

兩個人經過兩天幾乎沒睡的密集開發,最終結果還算滿意,真的是 盡 · 全 · 力了。

1_vY9xf_koaAwGV18spSYz_A
https://twitter-proj-chat.herokuapp.com/

test account 帳號 user0 ~ user4 密碼 12345678

總結我做了哪些事情?
#

  1. 建置專案協作環境及共筆文件
  2. ERD 設計繪製、共同撰寫 API 文件
  3. 註冊登入登出、使用者驗證功能
  4. 使用者資料、相片更新功能
  5. 種子資料設計
  6. Heroku 部署 API server
  7. 掌握 ngrok 使用方法
  8. socket.io 基本環境建立
  9. 挑戰題聊天室前端頁面切版及資料串接

感想
#

前後端分離開發架構確實有其優勢
#

在兩週內因緣際會經歷了全端及前後端分離的開發架構,我很深刻的感受到前後端分離的開發優勢,在寫 API 時是從 Model 出發,所以後端變得相對單純,可以完全專注在邏輯上,只要依照前後端講好的 API 文件下去開發即可,不需要像全端開發時還需要顧慮前端樣板寫邏輯所需的資料,這麼一來後端的開發效率就高很多 💪。

Git Flow 協作經驗
#

學習運用 Git, GitHub, Git Flow,這真的需要多人協作才能學會,運用分支來區分不同階段、任務的程式碼;體會到開發時要管理 commit 的粒度,以便 merge 時可以更順利地解 conflict。

要 merge 時我們都直接開 Zoom 分享螢幕來一起解 conflict,還記得第一次 merge 時遇到好幾個 conflict 緊張得要死,其實就只是兩個人都建立了一樣的 model 而已,到後期三兩下就可以完成 merge。

其中最大的差異是程式碼分工,如果可以先預想到會重複的程式碼如 Model ,就可以先由一個人來建立,而兩個人開發的功能也要注意會不會有重複的程式碼,這樣可以避免重工又要解 conflict 的狀況發生,加速開發。

每一次作業的畫面刻板都要認真做
#

如果不是從學期一開始就認真學習前端切版技術,每一次作業也都嘗試多做一點把自己心中的畫面實現,現在突然要我在短時間做出聊天室畫面我想是不可能的,何況之前的作業也很少使用到 position: relative, absolute, fixed 等屬性,真的能成功刻出來我自己也有點小驚訝就是了 🤣。

使用第三方套件的能力
#

現代開發模式多須依賴開源軟體或套件,避免自己重新製造輪子,加快開發的速度。因此閱讀官方文件的能力很重要,這與英文能力和程式實作能力有關,官方文件通常都寫得很簡單、陽春,如何轉化為符合自己專案架構的寫法,並解決過程中發生的問題(如非同步處理),我想這就是工程師的價值所在。

先釐清測試要求再開發
#

如果可以重來,在有自動化測試檔案的情況下,我會先研究自動化測試的要求,再開始開發 API。開發的過程中也要持續跑自動化測試,例如先寫測試要求的部分,確定通過後,再寫完整功能,這樣會更有效率。而且自動化測試本身也會有寫錯的地方,同樣需要 debug,一來一往會耗費許多時間。

專案的風險管理
#

專案初期太樂觀,與前端夥伴只有口頭上交流;之後後端自動化測試一波三折,加上沒有特別去 follow 前端夥伴的進度,導致第二週統整指定功能的進度時,發現前端已經嚴重落後,無法挽回了。

如果後端兩個人都無法支援前端 Vue.js 的部分,那還是建議使用全端開發方式,避免前端進度落後時,沒有人可以支援。

因為這個三人專案不會有專職的 PM,所以進度的掌握需要靠每個人共同努力,真的陷入開發漩渦或是有外務導致無法準時交件,儘早把問題丟出來討論,讓團隊有更多時間可以集思廣益,會是比較好的方式,畢竟最糟的狀況也就是從零開始而已,只要時間夠,沒有什麼不可能的。

感謝夥伴們
#

很感謝 Harry 和 Ivy 兩位願意和我組隊,也很榮幸和你們組隊。

和 Harry 在一開始的後端開發,到黑客松的全端開發,合作的過程都相當愉快,也從你身上學到很多 debug 及開發新功能的思維。一起在 Zoom 做 live debug 的夜晚、靈光一閃想到解法的瞬間、經過不斷討論激盪出的想法,到最後既使指定功能已經 delay ,挑戰題也不能輸的那種拚勁,相信這些都會是我們相當難忘的回憶。

Ivy 一開始就分享了許多業界的做法,像是後端在撈資料時可以先回傳 wait ,讓前端可以跑過場動畫等等。過程中也分享了你在公司的專案,我知道你是個在意細節且不服輸的前端工程師,如果有更多時間,相信我們可以合作完成更好的作品!

計畫趕不上變化,大概就是這次專案最好的寫照了,是吧?