Web Front-end 菜鳥心得：從 UI 轉職到前端的瓶頸們

轉職到前端工程已經一年又兩個月而且公司還活著，這段期間常常卡關覺得崩潰，直到最近一兩個月，才開始有得心應手的感覺。如果有人跟我一樣從 UI 設計轉行過來，可能也會遇到類似的瓶頸，想說趁記憶新鮮的時候整理出來好了，看能不能幫到人 ٩( ᐛ )و

公民日記：離開 g0v 的第三年

昨天 g0v 揪松團的網站上，出現這篇公告：

https://jothon.g0v.tw/notice/

事隔三年，當初讓我離開 g0v 的因素，終究浮上了台面。什麼情況下才會發表這樣的聲明，有概念的人應該一看就懂，不需要我多做解釋吧... 😌

Web Front-End 菜鳥筆記：React Context、React Hooks 研究心得

為了即將在下個 milestone 增加的新功能，先前跟公司爭取到一週的時間做技術研究，在這邊紀錄一下結果。

---

一、研究動機

希望節省手動傳遞全域性資料 / 函式所需的人工，例如：

• 處理未登入 / 權限不足 / api 逾時的函式，需要傳遞給所有會用到 api 的 components
• 多個不同 api 回傳的資料，各自需要傳遞給多個會取用該資料的 components
• 將來可能會需要支援的 theme 設定，也會需要傳遞給所有樣式受影響的 components

二、研究材料

• [看完] react context 課程
• [看完] react hooks 文件
• [看一半] react hooks 課程（基礎）
• [還沒開始] react hooks 課程（進階）
• [完成] 拿 toy project 試寫

成果發表：用自畫像做 LINE / Telegram 貼圖（目前非開放授權）

前陣子和電資工會的夥伴一起發想了工會吉祥物——電資貓的貼圖，結果好像意外打開什麼開關，各種靈感源源不絕，於是拿平常在 blog 使用的 ET 自畫像畫了草稿，然後在好友們的鞭打（X）鼓勵（O）下做成 LINE 跟 Telegram 的貼圖。目前進度：第一組上架完成 XD

Web Front-End 菜鳥一週年：Clean Code

Clean Code 這本書，正好適合寫作風格還沒定型的菜鳥一邊工作一邊慢慢看。原本不知要累積多少年經驗才能做出明確決斷的事情，從書本上系統性地吸收前人的思考以後，摸索的時間明顯縮短了許多。

這個月結束，人生中第一份 web front-end engineer 工作就做滿一年了。這段期間，每隔一陣子隨著任務變化，會跟公司要求一週不受打擾的技術研究時間，研究完馬上實做，實做完馬上寫心得筆記、跟高手求教、制訂下一階段的戰術，然後再度進入研究階段。幾個循環下來，深深覺得對技術進步幫助很大 😃

繼 React patterns 跟 JavaScript testing 之後，還有一項沒有特別安排時程、僅僅耗費每天在馬桶上的零碎時間，但卻讓我覺得非常有感的技術研究：讀 Clean Code。

過去曾讀過一本跟 Clean Code 有點像的書，叫做「病歷寫作」，都是在講述「特定領域的從業人員如何透過專業文件做有效溝通」，不是講技術，而是講前人曾經使用哪些工作方法來發揮這項技術、各自遇過什麼狀況、以及根據這些經驗得出的 best practice 是什麼。

Web Front-End 菜鳥心得：用 Cypress 寫人生中第一個測試

目前作法 1. 挑選變化型最多（aka 人工測起來最麻煩）的 component 做自動化測試 2. 以撰寫規格書大綱的原則來替 test cases 分類與下標 3. 套用 Clean Code 第三章的原則自訂 functions 來處理同一參數的不同變化型 4. 用設定檔和自訂的 functions 開啟 / 關閉測試行程中的 screenshot 動作

之前上了 Testing JavaScript with Kent C. Dodds 課程後，開始替公司產品前端撰寫 end to end 測試，使用課程中介紹的 Cypress 這套工具。目前為止做了兩個 component 的自動化測試，這兩個 component 的性質分別是導覽精靈以及對話視窗。使用感想如下：

街舞日記：BTS 的 IDOL

這期 MV 舞課上 BTS 的 IDOL，從最後一堂課的錄影裡面，可以看到這幾年間 adidas 大舉攻佔運動服飾市場的威力...

真的不誇張，最近走在街上看到的運動服幾乎一半是 adidas 啊！包括肥宅我這一兩年發現 adidas 的運動服真的比較可以修飾肥肉（X）剪裁好看（O）所以也從 Nike 跳槽過來了 lol

Web Front-End 菜鳥筆記：替小型的 React App 加上測試

採用 Testing JavaScript with Kent C. Dodds 課程做為快速入門教材，採用 Create React App 內建的 ESLint 跟 PropTypes 做 static analysis，採用 Create React App 內建的 Jest 做 unit test 跟 integration test，採用 Cypress 做開發工具跟 end to end test，採用課程附件的 worksheet 決定測試對象

前陣子公司產品前端重寫完，想說整個過程蠻小心的，應該不會有太多 bug，結果被 QA 同事一測... 😅 總之，接下來除了 debug 之外，還有一整個功能區塊的操作邏輯要大改。

先前開發時已經竭盡所能地謹慎，結果卻是 bug 叢生，於是不知所措的菜鳥又哭著（誇飾法）跑去跟 ddio 求救～～～原本以為我需要設計更好的架構、更乾淨的封裝來避免產生 bug，結果發現，該做的不是繼續在實做細節上鑽牛角尖，而是該面對先前因為覺得煩而從沒做過的那件事：寫、測、試！

反正程式 deploy 前，一定有個倒楣鬼要去測產品，然後每次程式更新，一模一樣的操作就又要重做一遍。橫豎都要測，何不乾脆讓電腦代勞呢？你ごん對毋對？ 😇

去年 10 月左右，看到 egghead 電子報介紹 Testing JavaScript with Kent C. Dodds 這個同屬 egghead 家族的課程，當時課程還沒上架但有早鳥 40% off 優惠，剛好也工作了幾個月有存點錢，就趁著打折買下去了。現在覺得有買到實在非常幸運，這正是我需要的那根浮木啊！總之，跟 PM 要了一週的時間上課，上完以後覺得像是撿到槍，手超癢超想掃射的 😂

半成品發表：電資貓 - 電資工會 LINE 貼圖草稿發想（集體創作）

某位佛心設計師替電資工會設計了吉祥物，讓敝會可以賣賣貼圖補貼家用，現在貼圖終於上架囉 😍 https://line.me/S/sticker/6337334

前陣子企畫期間跟工會夥伴一起發想了不少構圖，開一篇文章來紀錄，作者應該算電資工會全體吧，我只是負責畫框線圖的 😆

使用工具：iPad Air、Apple Pencil、Notability（朋友用過都說讚的筆記 app）

Web Front-End 菜鳥心得：安排自己的工作時程

我犯的錯誤：1. 沒有把國定假日考慮進來，簡直整死自己 2. 沒有詳細分析導致漏掉一個大功能沒算進來，簡直整死自己 3. 連續排滿四個月沒有中場休息時間，簡直整死自己 4. 以為設計工時只要用產品頁面的數量來估算，簡直整死自己 5. 以為程式複雜度跟專案規模之間只是單純的正比關係，簡直整死自己

最近幾個月重做了公司產品的前端，不算太複雜，是一隻菜鳥勉強可以獨力完成的規模。開發時程是去年的我訂的，後來有微幅變更兩次，總之最後是從 9/24 做到 1/20，總共 17 週。

前半段 UI / UX 原以為已經爛熟，結果花了快兩倍時間。後半段程式開發已經多排了一倍的時間當緩衝，結果不僅緩衝用光光、規格打折扣、還開 turbo 拿肝換，到最後關頭才追上。前陣子趕工趕得快吐血，一邊寫 code 一邊心裡狂幹譙去年的自己，超想坐時光機回去打他啦 (／‵Д′)／~ ╧╧

理論 vs 現實

這張圖的左邊，是最初的時程預估，右邊則是實際的工作記錄。黃底的那幾週，工時還算正常但有負荷過重的主觀感受；紅底的那幾週，則是毫無疑問的過勞。

算一算，原本預估 4 週設計 5 週程式，穿插 4 週的休息緩衝；實際上則是 6 週設計 10 週程式，而且如果把紅色的加班工時攤開來看，其實程式需要 12 週。然後我沒寫測試，所以如果要包含測試的話，應該至少要再乘以二之類的吧 😅