第一次前端接案打王(被王打)的心得

發表於 更新於 分類於 Disqus：

組隊打王示意圖

打王(被王打)示意圖

楔子

在 2019 年的年中，我在前端的路上陸續做了這些事情：接六角的遠端切版助教、參加 iT 邦幫忙的鐵人賽、以及邊上六角的課程。本來想說寫完鐵人賽 就回家去種田了 就專心上六角的課程，但在十月初、鐵人賽進行到一半的時候，我接到一封神秘的訊息。

這封訊息，讓我踏上了一段長達數個月的旅途。

究竟這封神秘的訊息透露出什麼資訊，以及在後續的路途上會有怎樣的遭遇呢？

讓我們繼續看下去…

第一章：接受任務

故事是從 2019.10.04 開始的：

哈囉，這邊有個案子，有興趣嗎？

看著彈出的視窗寫著王志誠老師的名字（後續以 Casper 代稱），發現前面的幾次對話是 老師安安初次見面可以好友加加嗎 當時參加六角同學會時，先當場詢問過志誠老師能不能加臉書好友，後來再到臉書上打招呼的訊息。

看到 Casper 的訊息後，大概知道發生了什麼事情。六角學院在 2019 年底時多了一個前端外包媒合服務，而目前 Casper 在詢問我有沒有接案的意願。

沒想到上次還只是在打招呼，接著就是在討論接案的事情了。不知為什麼，有一種回新手村找 NPC 拿任務的感覺 XD

幾經思量後，我決定接下這個遠端寫網頁的案子，開始第一次的接案打王(被王打)日子。

第二章：任務開始前的個人戰力與心態分析

其實從收到訊息到接受，我猶豫了一陣子。主要是不曉得自己的能力夠不夠接案。以下是我當時的能力經驗：

前端相關能力

  • 基礎前端：HTML、CSS
  • 樣式進階：RWD、SASS、BS
  • JS 技能：ES6、VUE (學到一半)
  • 前端相關：VSCode、Git、gulp

前端相關經驗

  • 六角遠端切版助教 (2019)
  • iT邦幫忙鐵人賽撰寫中 (2019.09-)
    • 後來得到佳作 (2020.01)

後來，Casper 說這個專案可能跟視差滾動有關，於是在等待專案開始的期間(10/04-10/08)，就複習了一下六角在響應式課程中介紹到的視差滾動課程，先備起來用。

第三章：任務介紹

有點像是辦營隊前的行前會概念，在這個專案開始前也有個線上會議(10/09)。在會議的過程中，我大概理解到這些事情：

一、開會成員與合作關係

開會的成員分別是 Fable 與六角的成員，而發包的是一間品牌設計公司。我想像中的合作關係大概是這樣：

  • 客戶公司：紐約的公司。為了實現商業規劃，尋求外部協助
  • 品牌設計公司：紐約的品牌設計公司。協助客戶的品牌設計需求
  • Fable：台灣的接外包專案的公司，依專案性質建立 UI、前端、後端等團隊以完成外包需求。在這次專案中接了品牌設計公司的發包
  • 六角學院：台灣的前端工程師教育公司。與 Fable 合作媒合前端人才
  • 我：完成前端切版、動畫、互動、接 API 需求

二、任務內容

客戶當時似乎是想重新設計官網，初期提出的需求是一頁式官網，以及問卷頁面。不過中後期有擴增需求，變成多頁式官網、也多了一些串 API、新增動畫效果等等的需求。原先預估是一個月的專案，最後擴增需求變成約三個月結案。

三、組隊成員

套句 Ray 說的話，我位於前端團隊中。剛開始的成員有兩個，六角方的我（切版、串 API）與 Fable 方的 Roy（類似 PM 角色）。在中後期因為一些原因，六角方的 Casper 和 Ray 有加進來協同開發一陣子。而 Roy 後期除了當 PM 角色外，還有擔當後端角色（猛猛的）

四、溝通與協作工具

在溝通工具部份以 Slack 為主，由於先前當六角助教期間有使用 Slack 幾個月的經驗，就沒什麼太大問題；當功能比較抽象，要清楚地傳遞需求時，就會另外用 zoom 視訊，或是附帶簡報。

協作工具部份，設計師（好像是 Fable 方的）會將設計稿上傳到 Zeplin，這樣我（前端工程師）就可以直接在瀏覽器上查看。另外程式碼是用 Git + Github 進行協作，我自己也會主動開 issue 整理需求與功能。感謝 Github 現在開私人專案不用錢錢。

五、開發流程

Roy（PM）會先跟案主、設計師開會，了解需求、討論出需要什麼功能、畫面，設計師會出稿到 Zepzin 上。我（前端工程師）則在理解需求與功能後，開始切版或實做功能。

前期的前端工作因為主要是我開發，所以開發流程的版控幾乎就是一路在 master 主分支上操作 XD。中後期開始有比較多的協作，採用的開發流程比較像是狂開分支的 git flow，有時再搭配 Pull Request 讓程式碼在推送合併到 Github 前，讓團隊有檢視程式碼的機會。

第四章：挑戰舉隅

在打王(被王打)的過程中，最常面對的一個挑戰就是解決未知的、沒處理過的需求。舉幾個在專案過程中遇到的、比較容易視覺化出來的功能需求好了。

一）漸層色進度提示條。當時因為看不太懂需求是什麼，處理得有點久，後來就陸續調整成符合自適應、線段間距粗細、漸層色等需求的形式。動態效果是我後來才加在 Codepen 上的，沒有用到專案中。

漸層色進度條

二）展開動畫提示框。當時這個需求一開始不太知道該怎麼實做，即提示框的外框先延展開來，過個幾秒內文才浮現。後來想起動畫就像魔術一樣，是一種障眼法，表象認為的結構與實際形成的結構是不需要一樣的，只要有看起來的效果符合預期即可。於是後來把外框與文字各自獨立成不同的元素，這樣動畫就可以分別控制外框的展開與文字的出現時機，且這樣文字就不受外框大小擠壓的影響了。

展開動畫提示框

三）IG 圖片牆。這個需求我苦惱了好一陣子，因為我之前沒研究過 Instagram 的 API，且它的 API 持續在變動，有很多限制與不可控因素，光是研究就一個頭兩個大。研究過很多方案後，這個需求最後是好心的 Roy (中後期兼職後端) 在後端開了一個抓 IG 資料的 API 給我才解決的。

IG圖片牆

第五章：初期任務卡卡的咚吱咚吱

專案開始後，一路上遇上不少挑戰。在專案的初期，我自覺有進行的比較慢，有段時間 Roy(PM) 也有提醒我要盡量趕上進度。以下是我認為當時會比較慢的可能原因：

一、架構的挑選

當時我在考慮專案的架構要怎麼安排時想了一陣子。後來想說因為需求是一頁式官網、問卷服務，加起來有兩個頁面，可能會有比較多重複的區塊與樣式，就決定用比較熟悉的 gulp 建構工具 + EJS 模板 + SASS 去處理。

另外，因為也有一些畫面互動、資料處理的需求，就引入了前端框架 vue 來處理，當時是用 cdn 的方式引入。不過後來 Roy 有跟我建議說，之後有用到 vue 的話，搭配 webpack 來使用會比較好。這我也同意。之後應該要研究一下 vue 怎麼達到多頁面配置的需求，例如預渲染或伺服器端渲染等解決方案。

這部份我自己的檢討是，當時應該要先清楚講出自己要採用的架構方案，在 Slack 中跟大家討論可行性、擴充性等部份，這樣才不會自己想老半天拖慢進度、或之後要改變架構時會很麻煩。

二、問題的解決

在專案初期時，如果我遇到了問題，我會先自己搜尋解決方案，像是過去的課程筆記、google、Stack Overflow、前端社群、開發文件等等。雖然大部分都能找到堪用的方案，但就是開發時間會被拉長，而且不確定這方案是不是最佳解。

後來經過各方人馬(?)的開導後，都一致同意 你不會更新你要先講 如果遇到暫時無法解決且會拖到進度的狀況，就回報到 Slack 中讓大家一起想辦法解決。

我的檢討是，在這種有時間壓力的專案中，以開發進度為優先考量。不要想說這種功能自己竟然不會覺得自己很遜、或不敢問別人之類的。在合理(真的有困難度)、有邏輯(有先自行除錯、把需求過程理順)的請教下，在 Slack 群中的人會願意幫忙的。

三、協作的磨合

這跟第二點有點類似。因為是第一次接案，我對於協同開發的模式較陌生，沒有過往的經驗能讓我遵循。像是該怎麼把遇到的做不太到的功能清楚表達出來讓 PM 知道、該怎麼回饋給設計師有些可能缺少的 UI 界面。熟悉這些協作模式讓我摸索了一陣子。

在專案初期，PM 可能會不了解我的能力在哪，不曉得我是否能跟上開發的時程。這導致 PM 在整個專案期間，會需要主動追我目前的開發進度到哪了。

我的檢討是，首先，和第二點一樣，要不害怕溝通與詢問，以開發進度為優先考量。其次，主動和團隊說明自己的進度在那，時間點可以在某個功能完成時、或是每天的晚上。

第六章：Feedback 轟炸

開發到一定程度後，就會開始數次的驗收、或是追加需求。我記得我在專案初期時完全沒注意到驗收這件事情，以為整個專案時間就是我的開發時間，讓我自己在初期的開發時間沒有抓好。

除了驗收的 feedback 外，還有其他一些會影響開發時程的變數。像是有 bug、需求追加、有些比較難實現的需求、或是趕在客戶方開會前修完 feedback。

舉一個比較極端的例子。有天下午我正準備替目前進度收尾時，我阿嬤在浴室跌倒撞破頭出血。我一邊試著幫忙止血與清理現場、一邊聯絡我爸準備一起去急診、一邊急忙收尾進度與聯絡 PM 告知部份狀況。

後來晚上在急診時被告知有 feedback 要修，問說明天早上有沒有辦法處理好，我就快崩潰了 QQ。於是先告知我目前無法處理，PM 說他會想辦法，先讓我專心處理好家裡的事情。

半夜十二點回家後，我可能腦袋壞掉了，跟 PM 說我接手剩下來的 feedback (PM 有問我真的 OK 嗎不要勉強 QQ)。當時雖然有在想說，這時間安排是要逼死誰，但還是想說這是我第一次接案，想要盡量做好，就還是接下來修了。

最後修 feedback 修到早上八點，跟 Slack 群組交接一下進度後就去補眠到早上十點，陪阿嬤去醫院洗腎。處理到一個段落時，大概中午就先離開回家補眠。我記得我在補眠時回想過去幾個小時發生的事情，在心裡面一直問自己「我是誰、我在哪、我為什麼要這麼累地做這些事情」QQ

我的檢討是，要做好時間控管，預留時間給修 bug 或 feedback、提前思考未來可能會追加什麼功能預先做好準備。注意自己的壓力與健康狀況，來不及做的功能就說出來。

終章：回顧

在經過三個多月後的二〇二〇的一月底，終於結案惹（灑花）。這接案的過程中很感謝 Fable 的 Roy，以及六角的 Ray、Casper。

Roy 除了擔任 PM 的角色，與案主、設計溝通完需求與功能會通知我外，在專案中後期也有處理後端與後台的部份。有些時候還會陪我研究一些 issue，真的很 小叮噹 很厲害。Casper 除了介紹我接案的機會外，也有詢問我目前進度如何、在有困難時提供我資源。感謝 Ray 當時在我無暇顧及專案的時候，幫我處理了一些 issue，讓我有時間處理家裡的事情。

我在這個專案中獲得滿多東西的。除了比較直觀的像是獲得磨練前端技術的機會（如輪播、動畫、接API、SASS架構等等），也體驗到整個專案是如何進行的，以及實際地協作溝通。

雖然過程滿累的，但對第一次接案的我來說，收穫頗豐。

參考的資料

在做專案期間，有時會產生迷惘，像是有些東西我都不會因而沒信心、突然開始懷疑人生與未來。這時就會等比較空閒時（等待 feedback），看一些前人的經驗談。以下是我看過的一些文章

軟體工程師菜鳥時期可參考。看完後可以體會到，就算是很厲害的人，當時也曾迷惘過，因此心情就會好一點（？）

開發習慣。因為開發初期時主要只有我寫前端部份，撰寫風格感覺比較沒規範與奔放。後來需要和別人協作時（如 Roy 和 Ray）就對他們不好意思，好像讓他們看到爛 code 了 orz。

除了前端技術外，接案的過程本身就是值得分享、聽聽別人經驗的事情。之前有看過六角其他接案前輩的心得，讓我在開發時覺得自己其實不孤單 QQ

後記

因為有報名六角學院舉辦的「鼠年全馬鐵人挑戰賽」寫文活動，加上自己也想整理這次接案學到的東西，估計接下來幾篇都會是跟這次專案相關的文章，再請有興趣的人多多指教惹。