Vue 筆記寫到一半就消失了好一陣子，就是因為突然得到了一個接案的機會，「第一次」總是糊裡糊塗的，某些情況下還會頗痛，接案也是如此。不過因為是個很可貴的經驗，所以值得寫一篇心得來記錄這個過程。
以下不會在技術上著墨太多，比較多的是一些自我觀照。
接案契機
六角學院在幾個月前推出了接案媒合服務，與六角合作的其中一個廠商名為 Fable 寓意科技，它本身是一間接案公司，這家公司裡的正職通通都是 PM，等接了案子後再去找外包的工程師團隊、文案團隊以及設計師團隊等一起合作開發。
上個月下旬，透過六角學院的引薦，我得到了跟 Fable 配合的接案機會，很特別的是這次的業主正是 Fable 本身，他們的官網要改版，於是透過六角尋找適合的前端。
協作方式
跟我一起共事的 Fable PM 叫做 Roy，在跟他談過專案的開發方向後，我心裡對專案的把握從 50% 降到 20%，於是六角的天使助教 Ray 作為我的技術指導也加入了專案的協作行列。
溝通工具
工作過程中都是透過 Slack 作為溝通工具，例如 Roy 會在 Slack 上公布開發時程，不過出於一些我也不太清楚的原因，時程往往是參考用（可能計畫趕不上變化吧）。實際上從設計稿出來到部屬到 heroku，中間大約是經過兩個禮拜左右。開發時遇到的問題也都會在上面即時地討論。
版本控制
版本控制採用 Github flow，基本上都是從 develop 各自創分支來開發功能，我一開始連分支名都可以取錯，後來經過 Ray 指正之後才取成不會造成其他開發者困擾的分支名。專案開發途中有待修的 Bug 或是回報工作進度，也會在 Github 發 Issue。開發到一個程度後需要發 Pull Request 給 Roy，請他把變更的部分合併到 develop 裡面，關於發 PR 我也是表現得很落漆，因為對介面不熟結果發三次才成功 😂
開發遇到的困難
開發時程與個人行程衝突
原本聽六角說該專案 12 月才會開始動，但在跟 Roy 洽談過後，發現當下就要立即動工，而該專案預計要在 12 月上旬上線。尷尬的是，11/30 - 12/4 我已預定要帶家人去日本旅遊，根據開發時程，我必須利用出國前大約 5 天的時間完成 PC 版的排版。那 5 天對我來說算是蠻修羅場的。當然也是很感謝 Roy 跟我的技術指導 Ray，在我出國期間幫我代班、大力支援，千言萬語就化作我帶回來的歐咪呀給 XD
球球動畫與 D3.js
雖然該專案是一頁式形象網頁，不過每個 section 都很有設計感，其中有一個 section 要做一堆球球衝出螢幕、互相撞擊的動畫效果。
一開始 Ray 指引我可以用 D3.js 來實現，於是我從原本對 SVG 繪圖 0 認識，開始努力惡補該如何用 D3.js 做出設計師要的效果，花了不少時間查教學文、研究文件、Stackoverflow、Youtube 上的英文教學影片，後來輾轉看到 three.js 才發現好像比較適合，但腦袋已經吃不下 three.js 的使用方法了 😢
最後這個 section 還是二次外包給比較有經驗的工程師幫忙做（賺）。
其他問題
都是一些比較瑣碎但還是讓人煩惱的問題，舉幾個例子：
- Gulp 自動化管理，我對 Gulp 環境很苦手，一開始有很多奇怪的毛病，在 Ray 的幫忙之下才搞定
- 有個跨 sections 的圖形要 hover 顯示，所以只好把兩個 sections 寫在同一個結構裡
- 為了便於維護，所以從純 HTML 換成 EJS，在這之前完全不知道 EJS 是什麼
- 設計稿給的螢幕寬度跟主流裝置寬度有落差
- 圖層很多，要用定位慢慢疊
- 開發人員工具看起來畫面正常，但有些物件在實機會跑版
- 自作聰明用 JS 換背景圖，結果圖片切換時會產生瞬間的空白
- 開發後期發現 AWD 比 RWD 更適合該專案，不過因為來不及改結構了，所以最後是兩者混用
在專案中的個人問題
接下來是自我檢討的 part….. 以下內容會以我自己的感受以及 Ray 的客觀評論穿插呈現。
一次到位的開發思維
當我準備要開發時，我可能會在腦中先想一遍整體做法才動工，因為我會擔心自己花時間精力做出 A 段落，接著做 B、C、D 段落時萬一跟前面的程式碼衝突，所有東西都要大改。但卻忽略了這樣會拖慢工作進度，甚至會有一種不知從何開始著手的挫折感。所以比較好的做法是拆解工作項目，並且先求有再求好，對廠商比較有個交代。
部分課程技巧遺忘
對，I have no excuses，我真的就是學了後面忘了前面 orz
例如我把 jQuery 忘得差不多了，這一次有個地方是要做出「一次只顯示一個文字方塊，其他文字方塊收闔」，我記得 jQuery 課程有教過，所以我有回去找當時自己寫的程式碼，但用在這次專案上效果卻出不來，自己也不知道問題出在哪，最後還是只好提出來求助。
雖然很多人說 jQuery 快要被淘汰了，但有了這次經驗後我覺得在一些小專案上 jQuery 還是很好用，之後有空想要好好整理一下 jQuery 筆記。
時間掌握不準確
根據 Ray 的評語，我很容易卡在一個區塊太久而犧牲了後面自己能做的事。我認為這一點其實跟前面兩點有很大的關係，再加上沒經驗，往往一個很簡單的項目或是 Bug 之類的，我都需要先 google 確認一下做法才敢開始動。然後因為也有碰到一些沒用過的工具或技術，要閱讀大量資料。綜合以上因素，就導致花費了很多時間。
給自己太大壓力
我把這一項放在壓軸，因為這是我自己主觀感受最深的一項。前面也有提到，跟 Roy 洽談過後我就覺得這一次學習曲線會很陡，而且卡到要出國，實際工作時間又更加緊迫。
我的一天可能是這樣的：早上 7:30 起床，8:00 坐在電腦前檢查 Slack 訊息確認有沒有新的交辦事項，然後開始一天的工作進度。中午會忘記吃飯或是沒食慾。晚上 18:00 左右跟 Roy 回報今天做了些什麼，但有時候可能超過這個時間我還無法為這一天的工作進行恰當的收尾。晚餐也常常沒胃口，可能在家人逼迫下草草扒個幾口後，又坐回電腦前看能不能多做一些進度，或是跟工作夥伴討論一些錯誤要怎麼解之類的。就寢時間可能是 0:30 左右。
總之，除了晚上睡覺以外，其他時間都在工作。
老實說我並不是可以一整天維持高精神力 coding 的人，所以我這樣在電腦前坐一整天並沒有讓工作變順利，但我只要稍微離開電腦就會很焦慮，因為怕無法即時看到 Slack 的新訊息，甚至我隨時都覺得好像聽到「答答答」的訊息聲 😢
在這個過程中，我大概跟 Ray 談過兩三次壓力的問題，我說我自己本身就比較容易焦慮，也害怕讓六角丟臉，或是擔心自己寫得太慢，最後造成其他夥伴的工作量。Ray 說，其實這些都是無謂的擔心，有時候寫不出來往往就是因為被這些壓力跟擔心給絆住。卡斯伯老師也關心過我的工作狀況，然後跟我說「就當作是練習囉」。Roy 也是有兩度問我「還 ok 嗎」之類的，並且在Bug 解不出來的時候幫忙處理。
到了後期，我就決定不要這樣虐待自己，然後發現當我吃飽睡好、用「這個寫出來算我賺到」的心態在寫一些項目時，就真的順很多，之前一些想不通為啥不能動的地方，也順利修好了。
得到的收穫
這一次不敢說自己功力暴增一甲子，但最起碼得到了 Github flow 多人協作經驗，現在對 Git 比以前更熟悉了；也學到了一些 D3.js 的皮毛，做出一個有互動效果的 Bubble Chart Demo。
此外，能夠意識到上一段提到的個人問題並思考它們是怎麼發生的、該如何改進，也是這次很可貴的收穫，雖然可能沒辦法在短時間就把自己這些缺點都改掉，但至少知道該往哪些方向改進。
還有一項很重要的是，雙向溝通的重要。作為工程師，與他人溝通的重要性從洧杰老師今年鐵人賽文章中可見一斑。工作優先順序、工作分配、開發遇到的問題......，這些東西都有拿出來大家一起討論的必要。我很幸運，這次遇到的夥伴不只對我很包容，也都很能溝通、一起解決問題，是他們的幫助，才讓我得到這麼多寶貴的經驗。
不過經過接案經驗的洗禮，我也意識到自己還是比較喜歡有明確上班時間的工作性質，畢竟......賺錢有數健康要顧 orz
結語
依據開發時程，專案應該要在今天上線，不過我現在還在等待驗收，希望一切順利，大家祝我好運 😂
12.18 更新：
Roy 本人看到這篇心得文以後，特別跑來跟我澄清。
誤會大惹，好險，如果 PM 技術力都這麼強，我想我應該也不用混下去了 😂
