Twitter前後分離協作專案開發紀錄

yu
Mar 13, 2022

--

專案畫面預覽

前言

此次專案配置為2位前端+2位後端進行為期12天的專案開發,個人負責前端的開發工作。專案流程模擬業界的Scrum的方式進行。過程中會有三次sprint check-in,小組需在AC指定的時間繳交符合規範的開發文件和達到當次sprint的進度。

專案成果

專案demo:https://jiangshuuu.github.io/twitter_project/

使用者測試帳號:
account: user1
email: user1@example.com
password: 12345678

管理者測試帳號:
account: root
email: root@example.com
password: 12345678

前端repo:https://github.com/JiangShuuu/twitter_project
後端repo:https://github.com/Yung-Che/twitter-api-2020

指定規格

前台

  • 使用者帳號無法登入後台
  • 未擁有帳號的使用者可以註冊新帳號登入(帳號、名稱、email不可重複)
  • 使用者需要登入才能進入網站,不可透過修改路由、表單元件繞過登入程序
  • 使用者登入後會保存登入憑證,若使用者登出則刪除認證
  • 使用者登入後可以創建推文、回覆推文、查看喜歡的推文(排序由新至舊)
  • 追蹤其他使用者、對喜歡的貼文按愛心、查看其他使用者資料
  • 使用者可以編輯個人資料,個人頭照、背景照片、暱稱、自我介紹,符合字數和不重複的規定才能儲存變更
  • 使用者無法編輯其他使用者資料、追蹤自己
  • 使用者可以修改帳號設定,變更帳號、名稱、Email

後台

  • 管理者帳號無法登入前台
  • 管理者可以在後台瀏覽全部推文、刪除推文
  • 使用者可以看到全部的使用者資料,推文數、愛心數、追蹤數、被追蹤數(排序由多至少)

開發心得

組隊

推特專案組員需要自己去找且要通過幾項指標性作業後才能夠參賽。由於先前幾屆有因為前後端人數落差太大導致無法順利分組,於是我們這組在學期三前期就已經完成組隊了。組員們來自於早期(?)同學創建的discord作業交流群,想說平時大家溝通時都沒有太多問題,應該合作也OK吧?抱持著試試看的心態就成團報名了。

遠端協作

由於大家都是線上同學,沒有私人的聯繫方式,開發過程均使用線上通訊軟體溝通

  • 如果是優先排序比較低的討論議題,我們會使用Slack文字溝通,請看過的組員給予emoji符號表示已收到這個訊息。
  • 如果是需要共同討論的事項我們會先約定彼此能上線的時間,使用slack的螢幕分享進行討論。
  • 如果某個議題當下得不到共識,我們會先暫緩,給彼此一些時間,得到共識後再繼續討論這個議題。
  • 實際進行開發時會使用Trello追蹤前後端開發狀況
Trello截圖

角色擔當

在這個專案中,我擔任的角色是前端的輔助開發和PM的角色。因為此次專案時程緊湊,必須要在12天內完成MVP功能,考量到前端夥伴-John開發經驗比我豐富,所以請他主導開發方向,我配合他的方式進行開發。除了擔任前端開發外,我另外兼任PM的職責,負責在小組討論時push討論進度、給予目前專案流程建議(例如串API時,原本後端是要全部完成才給予前端API文件,我建議後端夥伴可以先試著給予手上完成的API讓前端試串,避免後續有問題需要臨時修復)、會議記錄、關心前後端開發進度。

負責開發項目

  • 前端元件資料分析
  • NavBar元件製作
  • Popular元件製作
  • Main元件製作
  • Follower元件製作

開發過程反思

  1. 溝通與協作
    我認為此次推特專案最難的部分是在溝通,雖然大家在同一個bootcamp受訓了半年,不過期間也沒有太多合作的機會,突然在畢業前要共同完成專案..如果中途有人不小心下線已讀不回,真的是運氣QQ。好在我的組員們都很給力..有正職卻請假熬夜趕工的雍澈、夜貓子熬夜到早上守候後端Server的Orion、開發速度像鬼的大哥John
  2. 沒有訂出命名規範
    在開始製作路由時才發現,我們並沒有討論我們要使用什麼風格來撰寫樣式名稱。在我所負責的元件是採用BEM風格開發,組員則是使用單連號製作。在初期時影響並不大,因為各自負責各自的元件開發,但是在後期互相測試功能時就會遇到需要修改對方程式碼的情況,這時候就會需要花些時間去了解對方的架構和怎麼寫才能夠維持先前的樣式又能達到修改的目的。
  3. 重工問題
    因為是依照元件去分各個元件需要的功能,不過我們沒有考慮到有些功能是重複的。例如5個元件,條列功能後可能有50項,但實際只有10種,這部分是當初沒有考量到的,以至於在開發時曾發生A功能有兩種寫法…還好我們都很關心彼此的進度,才沒有讓這事情一再的發生,也算是即早止血了。
  4. SCSS共用樣式設定
    我們都是使用SCSS撰寫樣式,不過並沒有先針對專案所需要的樣式事先規劃哪些可以先做成通用樣式給對方套用就好,是在第一次Merge後才發現有這問題,但因為這次只製作桌機版,所以沒有另外花時間去琢磨這問題。
  5. API串接
    我覺得API這部分是我認為這專案第二難的部分,一開始串接API時我以為應該要等父元件的部分完成了再去串接子元件的部分,所以在串接時都會被這點給框著,造成進度緩慢。後來和大哥求救後才發現是自己的觀念錯誤,我應該試著以假資料去串接或是先確認目前API是有串上的再逐步去完成未完成的部分,而不是想著一次到位。

總結

經歷12天的開發後,我確定我是喜歡寫程式這件事。儘管過程很焦慮又疲累,但看到自己逐步實踐這些功能,我是開心的同時又看到自己的不足,於是我決定在AC結業後開始補強自已不足的部分。

--

--

yu

設計本科背景,前3D Lighting Artist,現為Web前端工程師。