2019年7月5日 星期五

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

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

2019年6月11日 星期二

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

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

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

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

2019年6月4日 星期二

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

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



一、研究動機


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

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

二、研究材料


2019年4月17日 星期三

成果發表:用自畫像做 LINE / Telegram 貼圖(目前非開放授權)


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

2019年4月8日 星期一

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

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

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

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

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

2019年4月7日 星期日

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 的性質分別是導覽精靈以及對話視窗。使用感想如下:

2019年2月25日 星期一

街舞日記:BTS 的 IDOL

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


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

2019年2月19日 星期二

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 要了一週的時間上課,上完以後覺得像是撿到槍,手超癢超想掃射的 😂

2019年1月23日 星期三

半成品發表:電資貓 - 電資工會 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 週。然後我沒寫測試,所以如果要包含測試的話,應該至少要再乘以二之類的吧 😅