歷經兩周的畢業專案，幾乎每天都熬夜，好久沒有這種時間壓力了(論文除外😭)。就讓我來記錄一下，這兩周的辛酸血淚史吧！打個預防針，這篇的重點在討論多人協作的過程，技術筆記的部分，就待之後慢慢整理發表吧！

前言

專案介紹

專案是模擬 twitter 產品進行簡化設計，可以分成 3 個主要的功能：

1. 推文類：發送推文、瀏覽推文、回覆貼文、喜歡貼文
2. 個人類：個人資料編輯、追蹤其他用戶、瀏覽其他使用者
3. 後台類：瀏覽推文清單、瀏覽使用者

協作模式

前後端共同開發，我們這組有 5 個同學，前端 3 人、後端 2 人(開發者資料，請見下方的 GitHub 連結)。因為採自由分組，我特別感謝後端的同學，是他們在我們社群上發布招募公告，鼓起勇氣應徵之後，才有機會同一組的，而且後端同學都是提早通過指標作業的，所以他們很早就開始分工合作，CY 、 Casey 真的非常優秀。

專題開始

我是負責前端的部分，這個多人協作對於我們組別的許多成員都是第一次，以前端來說，第一次多人合作、第一次使用 GitHub 遠端協作的功能 (branch、rebase、pull request)、第一次串接非專業的 API，總總都是第一次。

一開始我們以主題分工下去切版：

• main：首頁、單一回覆
• user: 個人資料頁面、共用元件 (Navbar、Sidebar)
• admin、login：登入、設定資料、後台

負責部分：user 頁面

user 頁面是我這次主要負責的部分，切版大概花了 2 天的時間吧！有了前幾次購物車專題的教訓，我把完成元件的順序訂為：基礎切版 → 串接資料 → 功能邏輯 → 簡化程式 → CSS 優化，如此一來才能在時間內和後端串接並且提早發現錯誤。

在這次的專案裡，我認為最困難的有兩點，第一點是能否遵循 single source of truth，區分好資料的傳遞與 UI 的呈現元件，以及第二點是搞清楚渲染的順序，不同元件之間，如何因為一個元件的資料改變，而去改變其他元件部分的渲染，例如我今天按了 Sidebar 的追蹤按鈕之後，能不能在 user 的 followings 頁面新增一筆資料。

溝通的重要

這次的專案特色就是多人協作，一開始的分工是有角色的，除了工程師角色之外，也有文書、 QA 以及 PM，我就只有負責建立這個專案的前端 GitHub repository，之後負責做前端部署和寫 README。 但是呢…我們的 PM 似乎就只有第一次會議時發聲，之後就不復存在了，因此我們組的進度規劃，就是按照第一次的會議紀錄，大家再各自調整，透過後端同學與前端同學的密切聯絡去跟進度，還好我們有報名 #sprint 2 的發表，讓我們在期中有多一次檢查的機會。

多人協作的成功的祕訣：頻繁的溝通 + 清楚的文件 + 善用 git

我們主要利用 Trello和 Google excel 作為任務安排和文件的溝通，用 slack 作為交流工具。

• 與後端同學的溝通：頻繁的和後端同學報告我們前端的進度，並且反映一些資料的問題，利用截圖的方式告知錯誤訊息，或直接用電話討論告知我們的需求，而後端同學都會在修改 API 之後，用 postman 文件告訴我們資料的格式與架構。
• 與前端同學的溝通：我們會彼此交流遇到的問題，完成的進度，討論一下後端的 API 有沒有需要修改的地方，有哪些元件可以抽出來，有哪些元件本來要共用但失敗了，哪個功能可能有問題，每天都會在一天結束前把進度 push 到 GitHub 再用 comments 的方式做總結。

任務危機

一周之後，因為進度實在落差太大，第三個部分由第一部分跟第二部分的同學平分，原本我們的想像是切版已經完成了，只剩下 API 的串接，後來卻發現那個 code 本身存在很多的問題，他只是一包 dummy code，最後的幾天都在完成這失落的幾頁，也連帶地讓自己原本的功能，本來要等著再優化的，例如 Loading 的畫面等，都來不及了，好在我們當初訂 Acceptance Criteria 比較保守，所訂出來的都是只符合 user stories 的最小 MVP (minimum viable product)，還算能交出一個可用但不好用的產品。

合作與衝突

經過這次的專案，讓我深刻的體會到，順利完成遠端實作需要對於 git 非常熟悉，熟練的操作 git 會讓你上天堂，相反的，你會掉入萬劫不復的深淵。我跟前端的夥伴，利用 git 很好的溝通彼此之間遇到什麼問題，有哪裡需要修改，進度到哪裡，也能透過 PR 預防亂七八糟的東西被 merge 到專案中。

雖然溝通這件事情 slack 也做得到，但是 git 就是完美呈現了「走過必留下痕跡」，即便前人寫了一個很爛的東西，也能透過 git 知道他就是在打漿糊，真正讓 code 能順利運行的是誰。

除了 AC 的教材和網路資料，我很大力的參考了高見龍先生的《為你自己學 Git》這本書，在你手足無措的時候，翻這本書會帶給自己很大的安全感。

至於衝突嘛？當我發現其中一位同學的進度大大跟不上、切版亂七八糟、甚至他從來沒有 run 過自己的 code 的時候，我情緒波動劇烈 😁，簡直氣到想寫信給 AC 踢掉這個人，但是沒有時間，因為相信而交付的那些任務，只能趕快在最後幾天把進度補上，還好我不是一個人，在這裡真的謝謝 Howard 大大了！🙏

我理解這只是個畢業專題，目的是取得學期三修課的證書，這個人未來跟我應該也是毫無交集了吧！如果今天合作時間變長，甚至是我的公司同事，那才會有向上反應的意義，這樣子失格的工程師，未來如果能靠這種品質的程式碼取得工作機會，那也真的是想問天問大地了。只希望這位同學能理解到自己的能力，再好好學習補上那個大坑。

黑客松挑戰

專案結束後，星期六、星期天是挑戰賽時間，挑戰做出聊天室的功能，指定用 socket.io 來完成功能。這部分我沒有特別想拉出來說，最主要的原因是大家都累了，我也累了，雖然說這是我人生中第一次的黑客松經驗，但體驗很差，把版切好之後，API 一直出問題，因為 CORS policy 被擋下來，一直嘗試無果之後，就放棄了。 所以雖然前端把版切出來了、後端也把需要用的 API 做好了，但兩者串接失敗，我跟後端同學在星期天的晚上也有共同想解決這個問題，但我們真的累了。

或許，之後 AC 可以改變企劃，可以設定在專案結束後的星期六12:00 – 20:00，大家一起完成 1 個挑戰功能，有興趣的同學就會安排時間參加了吧！比起鬆散的給我們兩天的時間，這樣或許更有黑客松的意義。

總結

這兩周是很疲倦的兩周，疲倦的點不只是完成一個作品。更多是和不在同一個小空間的同學利用網路世界進行合作。我自己是很嚮往 remote 工作的，所以我認為空間不是一個侷限工作效率的原因；但是要能夠有效的工作，必須仰賴很多工具，例如具有共識的文件、有效率的定期會議、每天的 task 回報，還有找得到的同事，這些條件都符合才能夠順利的完成遠距合作的任務。

我很感謝後端的 Casey 同學總是領導我們的會議順利進行、按時繳交作業，他不只是文書，更像是我們真正的 PM，我相信他未來在職場一定會很順利的！後端的 CY 同學遠在香港，還是全職上班族，更是一位父親，卻都能和 Casey 維持密切的聯繫，完全沒有溝通阻礙，真的很厲害。 前端的 Howard，雖然自稱內向，但總是能用文字表達出自己的做法、研究可以改進的地方、不同的寫法，需要找他的時候，slack 過去就好了！真的很感謝這些罩到不行的組員。

這個專案是非常不成熟的，評審老師的評語和我們自己的自我審查結果其實不謀而合，有許多點都是可以再修正的：

1. 切版完程度：這次的切板很低程度的符合 RWD，我認為在多設備的現代， RWD 已經成為前端工程師在切板時需要時時刻刻在意的點，但在這個專案並沒有反應出這個事實。
2. 功能想像：前面有提到我們的專案只是符合最低程度的 user stories，但是在使用者體驗上是不完整的，沒有辦法讓使用者知道他現在處於什麼階段，是在等資料、還是操作錯誤、在表格區，也沒有體貼使用者，這些都是這個專案所缺乏，值得修正的地方。
3. 程式碼的優化，我們對於 vue 框架、 vuex 還不夠熟悉，就好像放著許多尚方寶劍而未去使用，這也是我經過這次專案之後，發現自己的短處。

還有很多可以增進的地方，就有待我慢慢地修正吧！轉體工程師好像沒有結業式啊，每一個專案的結束都是職涯的另一個開學日。

---

有興趣的朋友，可以玩玩我們的專案：
👉 APP 由此進入
👉 前端 GitHub
👉 後端 GitHub