Alpha Camp 畢業專案 Twitter 小組協作回顧（全端組）

可以到這裡閱讀我寫的英文技術文章

Yu-Ming, CHANG (he/him)

6 min readAug 13, 2022

現在在電腦前的你，是不是也想轉職成軟體工程師呢？

在正文開始前，想與你分享我在 Alpha Camp 所有的心得文章，希望能幫助你做出適合自己的選擇：

轉眼間已經在 Alpha Camp 度過八個月，並且順利完成小組合作開發的 Twitter 專案，這一篇文章將包含：

Twitter 專案目標
小組最終成果
小組如何分工
我的角色
我負責的開發內容
Lesson Learned

Twitter 專案目標

在為期兩週的時間內，讓小組成員獲取使用 git 多人協作開發的實戰經驗。除此之外，共同研究 AC 提供的素材與測試檔案，討論出對最終結果的共識，並依此開始拆解任務，分頭開發，透過每天早上的 stand up meeting 讓小組清楚知道目前的進度，讓開發能順利進行。

小組開發的形式可以選擇全端開發，或前後分離模式開發，有鑑於本屆前端稀少的很，比例約莫 3 後 1 前，我們小組最後選擇全端模式。

小組最終成果

我們花了 3 天規畫， 6 天開發，中間安排 1 天休息，在第 10 天通過所有 74 項自動化測試，並將 Minimum Viable Product 部署到 Heroku，最後 4 天則開始優化使用者體驗。

這是我們部署到 Heroku 的專案入口，而這是我們的 GitHub Repo，如果你目前正在 AC 準備進行 Twitter 專案，那可千萬不要去看我們的程式碼哦！

小組如何分工

建立合作模式實在是很重要的步驟，合作專案的時候，絕對需要一些工具來輔助專案進行，但是如果太多工具，可能反而會讓團隊分心，所以一開始，我就先和團隊達成共識，這次專案只會使用 Notion，後續所有的分析文件，任務表，會議紀錄，都在 Notion 上保存。

因為是全端開發，所以彼此之間的互助性很高，所以我們先把所有需要的路由列出來，每個路由會對應到的 controller 和樣板也先行命名，這樣後續開發的時候就可以專心開發，而不用分神想檔案結構。

分工的大方向是依照路由分工，同一個路由讓同一個人開發，這樣同一個路由的 MVC 基本會是同一人的產出，這樣可以減少程式碼出衝突的機會。因為分工時，基本上所有需要的任務都已經列出來了，所以先讓大家挑自己有興趣的路由，挑完後，看大家身上的任務數量是否概略平均，有特別多的/特別少的，就知道是誰要放，誰要接。

很重要的分工前提

在專案開始分工，尚未進入開發前，要跟組員達到一個共識，就是這個分工是概略分，接下來每一天都會有 Stand-up Meeting 查看每個人的進度，屆時會看是不是有哪些任務可能會面臨比較高的風險，到時候會再重分配，以此平衡任務難度不均的狀況。

特別的 Code Review 機制

在這次的合作，我們也預先強制設定了 code review ，除了可以改善程式碼品質外，也可以讓我們親身體驗一個需要被其他人審核的 PR 它的流程會怎麼跑。

我的角色

一、專案經理

大概是因為之前的工作經驗，我很自然而然地承擔 PM 的角色：帶領專案規畫與衝刺會議的進行

二、Site Reliability Engineer

開發要能順利進行，就需要組員能無後顧之憂地專注在一件事情上，所以我率先把前期的開發環境建立好，讓組員直接 git clone 已建立好的 team repo 就可以開始上工。

除此之外，在開發第二天，我便開始部署程式到 Heroku，以及連上 AC 設定的 Travis CI 做自動化測試，即時掌控組員程式碼測試結果

三、軟體工程師

最後一個角色也相當重要，就是把計畫實現，這個實現，除了寫好自己負責的程式以外，我們小組有強制設定所有人都必須提交 PR 讓另一個人 review 過，通過 code review 才可以合併回主幹，所以我們每個人，除了寫自己的，還要看別人的！

我負責的開發內容

主要開發內容

基礎開發環境建設 ( 包含 eslint, app.js, 路由抽象化與引入, 基本資料夾結構, 部署至 Heroku, 撰寫 README.md)
前後台登入與使用者驗證 passport('local') (包含資料獲取與渲染)
後台登入後的管理首頁 (包含資料獲取與渲染)
前台右側導覽列 (包含資料獲取與渲染)
前台使用者追蹤與取消追蹤的功能
撰寫 Client JS 讓瀏覽器即時讀取目前輸入的文字數量

優化項目

優化使用者體驗

在註冊成為新使用者時，表單會即時反應目前選擇的帳號名稱是否可以使用（監聽 focusout 事件，發 api request 回伺服器，到資料庫檢查是否重複）
在註冊成為新使用者時，表單會即時反應兩次輸入的密碼是否一致
管理員登出後會回到後台登入頁；一般使用者登出則是回到前台登入頁
管理員若想進入一般使用者頁面，或一般使用者想進入管理員頁面，將自動被導回各自的首頁 (也就是無法進入的意思)

優化開發者體驗

使用 cross-env 解決 Windows & Linux 作業系統，設定環境變數的 command 不一致而會報錯的狀況
整體畫面的切版，會根據 HTTP Request 的路由自動切換，而無須在每頁樣板中設計：登入前一欄，登入後依照路由不同，可能兩欄，也可能三欄

Lesson Learned

我們小組的開發進度其實非常順利，開發第三天做組內驗收時，就已經通過 81% 的 Travis 自動化測試，這是為什麼我們可以在禮拜天放休一整天呢！

在這兩週的衝刺，我學到了：

合作面

溝通是萬事之母，寧願過度溝通，也不要不溝通
無時無刻管控好自己的產出很困難，但是要想個方法盡量做到，沒有做到的時候，一個良好的 code review 機制雖然可以幫忙抓出程式的疏漏，但是我們不能都依賴它來幫自己抓蟲。原因是負責 review 的工程師也是人，讓他看一個品質好的程式碼，會讓他今天的心情快樂一點
不過有一點，評審點評的時候有很委婉地提出，就是程式寫作風格不太一致，如果在開發前，就決定整個專案都用 Promise or Async 的寫法，小組整合起來後的風格就會更一致，看起來更好

技術面

真正跑了好多次 PR, Review 和解衝突的案例，也要頻繁切換不同分支和使用 git pull 來和同步本地程式碼到最新的狀況，減少推回 remote repo 後產生衝突的檔案，這是自學最難模擬的經驗

最後再次感謝組員建安和婉菁的合作，讓我們順利完成多人協作專案！

祝我們接下來轉職面試都順利囉！