Sprint 協作專案 Alphitter — 歷程回顧

前後端分離畢業專案的流程紀錄與反思

14 min readDec 20, 2021

❖ 大綱：

1. 專案簡介、成果分享2. 團隊協作及分工
 ▪︎ 2-1. 團隊協作流程
 ▪︎ 2-2. 前端分工合作模式3. 技術回顧
 ▪︎ 3-1. 前端開發使用了什麼技術？
 ▪︎ 3-2. 哪部分相對能掌握？哪裡花最多時間？
 ▪︎ 3-3. 過程中碰到什麼困難？又如何克服？
 ▪︎ 3-4. 過程中對哪個前端技術有特別深刻的學習？4. 開發流程反思 
 ▪︎ 4-1. 團隊協作流程做的不錯的部分 / 可以再調整的部分
 ▪︎ 4-2. 開發過程中，做的不錯的部分 / 可以再調整的部分
 ▪︎ 4-3. 如果有時間，你會繼續開發哪個部分？5. 總結

1. 專案簡介、成果分享 — — — — — — — — —

Alphitter 專案是由 4 位開發者費時 2 週共同打造的前後端分離專案，目標在建立一個簡易的的社群網站，涵蓋的核心功能包含：註冊、登入/登出、發文、回覆、追蹤、按讚、修改個人資料…等，並設有一般使用者與管理帳號的權限區分。

細節請見 : Github

快速瀏覽專案

請進入網站： Alphitter
→ 歡迎使用前台測試帳號瀏覽： account：user1 / password：12345678
導覽：

Alphitter 1.0 功能

一般使用者：

註冊 — 未擁有帳號之使用者，可註冊帳號 ( 帳號、信箱不可重複 )
登入、登出 — 可運用帳號及密碼，登入系統，登出系統 ( 認證隨登入登出改動 )
發送推文與回覆 — 可於頁面進行推文與回覆之發送，頁面會隨即更新
修改資料 — 使用者可修改帳戶資料、自我介紹、照片及背景
使用者可追蹤他人 — 有頁面顯示追蹤與被追蹤之狀態
使用者可按推文讚 — 有頁面顯示使用者以按讚推文

後台管理員：

後台管理員不可註冊 — 由後端直接寫入資料庫
管理員可由後台入口登入 ( 使用頁面與一般使用者不同 )
管理員可刪除推文
管理員可瀏覽使用者之各式數據 ( 僅能瀏覽 )

2. 團隊協作及分工 — — — — — — — — —

Alphitter 專案是由 4 位開發者費時 2 週共同打造的前後端分離專案，前端由夥伴 David 及我 Dolly 使用 Vue.js 框架搭配 CSS preprocessor － SCSS 打造，後端則由夥伴高明與 WenTing 使用 Express.js 框架搭配 MySQL 資料庫建立。

整個開發為 Scrum 的工作模式，以目標為導向，不分前後端皆會互相協助，共同解決問題；在每個 Sprint 結束後皆會交付部分進度，檢視現有成果和最終目標的差距，迅速調整分工與開發策略；在緊湊的時間限制下，小組成員每日仍會透過線上會議進行例會，迅速回報進度，分享必要的資訊，共同排除重要的問題。

2–1. 協作流程 (Sprint1 → Sprint2 → Sprint 3)

▪︎ Sprint 1 — 確定開發規格、訂定 Acceptance Criteria 並確立分工

在這個階段中，我們團隊首先針對了 User Story 進行討論與分析，分享彼此的看法後定義下要做到的 Acceptance Criteria。

User Story to Acceptance Criteria（僅擷取部分資訊）

接著針對個別功能項目進行深入的討論，了解每個操作與畫面可能會牽涉到的前端元件與用戶流程是什麼、需要後端ＡＰＩ提供哪些資料格式，共同 review 可能的限制、解決方案以及開發流程，確保團隊對接下來要衝刺的方向有所共識。

最後，我們彙整了產品規格、定下產品發布前要達成的成功指標 DoD ( definition of done)，評估在有限時間內是否可發布所有功能，調整功能開發的優先順序，並訂下每日的時程進度表。

[DoD 檢核項目紀錄]

[安排開發優先順序]

▪︎ Sprint 2 — 前後端各自聚焦衝刺畫面開發與資料庫建構，為 API 串接做準備

前後端各別依據 Sprint 1 的結論進行分離開發，但在各自開發的過程中，若發現 sprint 1 規劃階段未討論到的規格細節，成員間會主動溝通，前後端互相理解彼此需求後找出可行的方案，再根據共識分配新的組織任務、各自進行開發。

若在前後端分離開發時遇到瓶頸，會由另一位前端/後端夥伴負責檢驗，Code review 並提供不同觀點建議。每日也會進行開發項目的驗證與測試，確保結果與 acceptance criteria 相符，盡可能地讓串接 API 前的不確定性收斂到最小。

Checklist of Acceptance Criteria — Checklist of our acceptance criteria （僅擷取部分資訊）

︎︎▪︎ Sprint 3 — 完成部署及交付前驗收

在 Sprint 3 完成 API 串接後，我們建立 QA 回報機制，一發現問題就馬上列單，分配修復人員及時調整。同時在產品準備交付前進行了兩次 Demo 與 Acceptance Criteria 的檢核，確保一切任務與規格皆以完成。

2–2. 前端分工合作模式

➤ 確認架構

前端組在開發初期，便共同確定與討論出整個 App 在 Vue.js 中的架構，並匯製成 Component Tree 作為之後開發討論的基礎。

➤ 訂定開發順序與分工模式

在開始進行任務分派前，我們先將任務拆解，並依照重要程度排序開發的優先順序。首要進行 infrastructure 的建設以及共用元件的開發，接著是共用樣式以及重複利用性高的 Utilities 撰寫，完成共用組件後就按照優先順序開發 Component Tree 的剩餘項目。

我們將任務拆解成 Kanban 的 task card，標註上優先度顏色，成員再依照約定好的領票原則主動領取開發卡片。利用看板來協作能避免重工，也能透過卡片的分布位置快速掌握開發的情形。

➤ 約定開發風格與準則

除了訂定任務開發順序，我們也在正式開發前先討論出要採取的開發風格與基本準則，讓多人協作的專案保有一制性，在維護與除錯上也能更有效率

開發約定準則 (Style & General Guideline) （僅擷取部分資訊）

➤ Code Review 以及 Github PR

每個功能開發完成後，會發送 pull request 上 Github，並和成員一同 review 程式碼以及變動的目的，若程式碼品質與畫面符合期待且沒有 merge conflict，就會同意 merge PR。

Code review 時的考量事項大致上為：

程式碼的改動是必要的
UI 的改動可接受，且符合設計稿
程式碼複雜度適中，命名適當，且有明確的註解說明程式碼目的

3. 技術回顧 — — — — — — — — —

3–1. 前端開發使用了什麼技術？

Vue.js 框架：處理資料狀態、拆分頁面元件，有結構的管理並提升網頁模版的重複利用性
Vuex 全域狀態管理：集中管理使用者權限認證、以及資料更新等事件
Vue-router 建立 SPA 網站：建立前端路由
API 串接：透過 axios 來向後端伺服器提取/發送資料，將資料呈現於畫面
SCSS: 使用 CSS 預處理器 SCSS 加速樣式開發效率、提高易維護性
Moment.js 套件：轉換時間日期格式或分析時間區間

3–2. 哪部分相對能掌握？哪裡花最多時間？

在這個專案之前，我已經在幾個 mini-project 中使用 SCSS 搭配 BEM 的命名原則開發，因此切版中的樣式設定對我來說相對容易。
在 Sprint2 階段中，花費較多時間的是在研究 Vue.js 框架的深入應用，對於 DOM 的操作知識，需要由原本 Vanilla JavaScript 的寫法改為遵循 Vue API 的語法，查閱 documentation 確認應用方式花費了不少時間。

就拿 Web API 的 event.preventDefault() 等事件處理方式來說，在 Vue 中可直接透過 v-on 搭配 evnet modifiers 做到各種處理，如： <a v-on:click.stop.prevent.self=”doThat”></a> ，在第一使用時需要翻找文件確認用法。

雖然查找文件看似很麻煩，但透過每一次的查找，能累積自己對 Vue 框架的掌握度，也能從中體悟到框架帶來的便利性。
Sprint3 花最多時間的是 API 串接，在將畫面中的 Dummy Data 改由後端提供的資料時，碰到很多格式或畫面不如預期的情形，這些問題需要前後端雙方互相合作攜手解決，來回修改測試花了不少的時間，團隊也費了很多心力與時間溝通以找出可行方案。

儘管開會時間拉長壓縮掉不少開發時間，但前後端在規格上的討論都是必要的，有共識及策略才能真正的提升開發效率，減少沒有意義的行動。很開心最後的成果反映出團隊的用心，呈現出來的結果令人滿意。

3–3. 過程中碰到什麼困難？又如何克服？

(1) 登入成功及個人資料更新成功的通知訊息 Toast，會因為 vue router 的迅速跳轉而無法呈現

克服方式：
由於 Toast message 的浮現時機是在表單透過 API 傳至後端，並收到後端回報成功的 status message 之後，評估在這之間不會存在其他 event 佔去 Call stack，所以可以搭配 setTimeout() 來延緩頁面跳轉的速度，讓使用者先看到 Toast 後才進行 vue router.push() 跳轉頁面。

(2) 即將使用後端資料取代切版 dummy data 時，發現後端提供的資料格式不如預期

在 Sprint 2 開發時，預期個人資料頁下方的三個推文清單「推文、推文與回覆、喜歡的內容」API 會提供相同的資料格式，所以將三個設計稿 UI 收斂成一個 Vue Component。

但到 Sprint 3 實際串接時才發現三個 API 回傳的資料格式不同、 key name 也有差異，難以在同一個 component 內使用 v-for 迴圈搭配 data binding 渲染重複的推文 block

克服方式：
利用 JS ES6 的解構賦值技巧，搭配 Array 的 map() 操作，將陣列各項的物件資料解開成為新參數，重新組裝資料並給賦予期待的 key name ，如下圖。

(3) 畫面渲染發生於 API 回傳使用者圖像之前，非同步的時間差造成畫面短暫的破圖(如下圖右側)，使用者體驗差

克服方式：
增加 v-show 的渲染機制，當後單伺服器還未提供資料時，隱藏使用者個人資料卡片，改為呈現 loading 中的圖示，避免讓使用者看到空資料

3–4. 過程中對哪個前端技術有特別深刻的學習？

在實作 Navbar 與 NavPills 所在頁面的樣式設定時，我們發現 Vue Router 的 router-link-active是模糊比對，而 router-link-exact-active 是準確比對，由前者驅動添加的 class 會出現在多個 path 上，而後者只會有一個。這樣的特性差異讓我們可以更彈性更便利的去設定 Navbar 與 NavPills 的樣式，讓我印象深刻。
在使用 Moment.js 套件時，我花費了一些時間去瞭解如何改變顯示語言和客製化時間格式，在研究官方文件的過程中，我發現整個套件的設計邏輯其實不複雜，但要建構出功能如此齊全、使用如此靈活的工具想必開發者花了不少時間，越發覺得套件的存在著實提升了我們工作的效率，減少花費在撰寫這些瑣碎設定的時間，讓我們可以聚焦在產品的核心功能上，感謝有這些開發者對前端社群的貢獻。

4. 開發流程反思

4–1 團隊協作流程做的不錯的部分 / 可以再調整的部分

做得好的地方：
我認為我們團隊能夠成功，歸功於成員間主動積極的溝通和對目標的一致的認同。
所有的規格與開發規劃都是在成員間交換意見、取得共識後才產生，若開發過程中碰到問題，大家會互相給予意見，主動協助彼此除錯。另外，雖然是前後端分離的專案，但我們仍盡量保持資料透明公開，讓所有成員皆能看到前後端的進展與架構，掌控整個團隊的現況與願景。
可以再調整的地方：
我認為團隊在 Github 多人協作的流程上可以再優化。
此次開發是全體成員第一次體驗多人協作的 Github，對於分支的應用與 PR、merge 的時間點都是到後期才漸漸掌握，版本紀錄較無系統，也頻繁的發生 merge conflict，這部分是團隊可以再進步的地方。

4–2. 開發過程中，做的不錯的部分 / 可以再調整的部分

做得好的地方：
1. 使用 BEM 命名搭配 SCSS 撰寫，並有拆分成多個 SCSS module 方便維護與開發，有結構化且提升不少效率

2. 有針對使用者流程做對應設計，比如利用 Toast 提供登入及發文狀態的資訊給使用者，在表單提交的相關按鈕上加入防止連續點擊的防範機制，避免後端伺服器重複收到使用者的請求。

3. 雖然因為時程緊湊所以沒有實作 RWD，但有考量到桌機的最小顯示寬度，不讓桌機在伸縮頁面時壓縮區塊內容，盡量透過 min-width/ max-width/ flex box 等設定去保有區塊內容完整性
可以再調整的地方：
1. 資料夾管理的結構可以再調整，觀察別人專案時發現 styles 的資料夾應該擺在 /src 底下，而非 /assets 底下。

2. 在實作時只想到要為資料載入的時間差做過場的 loading 畫面，而忽略了資料送出也可以添加，一方面是由畫面來防只使用者重複點按，二來是可以增加使用體驗上的流暢感。

3. 團隊的 Coding Style 以及 VS Code 的設定可以統一標準，避免因為分號、斷行等設定不同造成提交的 git 修改紀錄混亂難讀，當 conflict 發生時難以比對。

4–3. 如果有時間，你會繼續開發哪個部分？

依據專案設計稿所呈現的後台管理功能太過簡易，與一般對管理後台的權限期望有落差，因此如果有時間，我會想將管理員後台的功能強化，比如：

將載入的使用者資料分頁，方便查看也能避免大量資料載入造成效能負擔
增加使用者搜尋功能
增加管理員修改使用者資料的權限
新增管理員對回覆留言的管理頁面

5. 總結

在這兩週的緊湊開發中，實戰給了我機會融合過往所學，重新提煉出能應用的技巧，讓我脫胎換骨、感覺又再次成長了。其中最珍貴的是每一次解決未知問題的經驗，每次釐清問題、找尋答案、成功突破的過程，讓我對程式有更寬廣的認識，也對應用的技術有更深的理解。

很開心這次畢業專案能順利完成，這一切都要感謝與我一起奮鬥的好夥伴 David、WenTing 還有高明，我覺得自己很幸運，能在 AC 找到一群志同道合的好朋友，大家都很有想法，也願意溝通與接納不同的意見，共同為目標努力。謝謝你們成為我的夥伴，一起為這個專案付出這麼多努力，因為有你們這群值得信賴的好夥伴，才能創造成功的團隊協作。

畢業專案落幕，大家辛苦拉！希望未來的我們能有機會繼續合作～