從 Frontend Engineer 轉到 Feature Analyst 的一週年心得

TL;DR 總結論

使用 as a - I want to - so that I can 的格式撰寫 user story，就不容易漏掉開發時需要的背景資訊，可以節省工程師反覆追問使用情境的時間

使用 cross-functional process flow 的格式繪製 user journey，就不容易漏掉 happy path 以外的操作邏輯，可以節省工程師反覆確認產品行為的時間（感謝強者前同事 19 教我這個招式）

使用 given - when - then 的格式撰寫 acceptance criteria，就不容易漏掉驗收時需要一併檢查的先決條件和分支路線，可以節省功能交付後才回過頭來東敲西補的時間

把 acceptance criteria 變成自動化測試的 test cases，就不容易記錯預期的產品行為，可以節省工程師翻閱 source code 回答 PM 問題的時間，也可以降低重構時把既有功能搞壞的機率

去年中的時候，也就是我轉職前端工程滿四年無法再藉由自稱菜鳥來逃避責任的時候，因為團隊裡寫規格的人手不夠，開始兼任文件寫手的工作

團隊成長的代價

轉職前端的頭兩三年，團隊很小，PO、QA、客服由同一條龍同一位同事擔任，任何事情問他就能得到最終答案。因為有這麼一個會走路的 single source of truth，開發過程中幾乎沒有寫文件的必要，同事從客戶那邊帶回新需求時，會找前後端一起討論，我出 wireframes 確認以後，大家就各自散開寫 code。當時這個以一條龍為祭品 conversation over documentation 的模式，從工程師的角度看，覺得運作得蠻順暢的

後來團隊跟著產品一起出售，來到一間比較大的公司，產品變複雜分工變細，溝通協調的難度也跟著變高

首先遇到的問題，是層層轉達造成的資訊衰減。客戶的意見過了 N 手、抵達工程師這裡時，我們只知道「決定要做某某功能了」，但究竟是為了滿足什麼需求、要在什麼情境下被如何使用，這類脈絡性的資訊往往會遺失

除此之外，由於產品範疇變大功能變多，超過一條龍一個人可以負擔的程度，工作自然會被拆到不同人身上。當設計跟前端由不同人處理，對介面行為的認知就會有不同版本；當 PO 跟 QA 由不同人擔任，對驗收標準的認知就會有不同版本；隨著時間過去，每個人的認知還會漸漸變模糊。由於不再有人能擔任祭品產品規格的 single source of truth，單靠 conversation 的溝通就不容易收斂出具體的結論

於是，為了讓資訊不會在多次傳遞之後衰減或佚失，以及為了找回產品規格的 single source of truth，文件的需求就浮上檯面來

g0v summit 2020 議程與 ⟪審稿小幫手⟫

去年因為跳坑議程委員的關係，要幫研討會的會眾們代客選修，每個選修工具人都要看完兩百多份稿件，而且這些稿件還會不斷新增和變更內容，因為數量太大、版本太多，單純開個試算表已經無法應付，因此替自己做了審稿工具。

• 開發歷程與功能介紹： https://twitter.com/ETBlue/status/1280194156816564224
• 原始碼： https://github.com/etblue/audit
• 授權：MIT

事後在 coscup telegram 頻道討論審稿流程的時候，得知 pycon 有超完整的文件，這種有條有理的做事方式，個人真的非常喜歡 😍

• 投稿指南： https://tw.pycon.org/2018/zh-hant/speaking/talk/
• 審稿指南： https://pycontw.github.io/reviewer-guidebook/reviewer-guide.html

原本想寫一篇完整的審稿心得文，不過因為豬血糕生病的關係，就只停留在和朋友閒聊然後記錄在 SNS 的階段了。

• 關於代客選修的閒聊： https://g0v.social/@etblue/105567956607555131

Web Front-end 菜鳥心得：用 React Custom Hooks 製作頭尾相依的連鎖反應

以下是一隻菜鳥在無窮迴圈之森與變數未宣告之谷中逃出生天的掉漆冒險故事

昨天花一整天才弄好的東西，過程中一度進退維谷、想衝去 slack 跟 senior 喊救命，最後菜鳥我終究還是靠著驚人的意志力，一邊維持不打擾別人休息時間的紀律，一邊奮力爬行抵達了終點... _:(´ཀ`」 ∠):

想解決的問題

系統中有三類物件，彼此互有關連，這些關連只會紀錄在其中一方，因此前端從 api 拿到資料後，會做一些計算，才能在每個物件的畫面上顯示出它和誰相關連。任一類物件新增、修改、刪除時，前端也需要重新計算，更新相關連物件的狀態。

前端這邊的計算任務為：

• 物件 A 變動時，自動更新物件 B 與物件 C
• 物件 B 變動時，自動更新物件 A
• 物件 C 變動時，自動更新物件 A

Web Front-end 菜鳥心得：將 stateful components 遷移到 React hooks 的第 17 週

灰底是各種跨 component 共用的東西，白底是會實際 render 到畫面上的部分

去年十月開始，egghead 電子報就陸陸續續提到 React hooks 的消息。今年二月隨著 React 16.8 發佈，hooks 正式成為內建的功能。今年四月底，Create React App 3.0 也開始支援 hooks。

這段時間，菜鳥我一直抱持觀望的態度，直到最後確定 hooks 是 React 家族不可逆的大轉向，就決定要盡可能趁手上專案還沒大到改不動的時候遷移過去。現在雖然還沒全數改版完，但算是稍微做到一個段落，趕快趁記憶新鮮時記錄一下，給其他有類似改版需求的人參考。

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

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

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 試寫

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

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

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

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

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

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

理論 vs 現實

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

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

Web Front-End 菜鳥筆記：在 2018 Q4 的小型 Single Page React App 函式庫 / 框架選擇

採用 create-react-app、react-router、axios、semantic-ui，暫不採用 redux / redux-saga、react-i18next，下階段預定採用 react-fns

人生中第一份前端工程的全職滿五個月了～公司還是沒倒喔（灑花）

從開始學 React 到現在，做過不少小型的 single page app，但畢竟都是自己的 toy project，從沒認真以 production quality 為基準做技術研究。這次負責公司 app 改版，爭取到一兩週的時間，把之前打馬虎眼欠下的知識債一口氣還完，覺得整個人神清氣爽～非常開心 :D

結果如下：

Web Front-End 菜鳥筆記：如何讓瀏覽器記住 form input field 的值（p.s. Chrome 的不合群行為還沒解開）

人生中第一份前端工程的全職滿三個月了～公司還沒倒（灑花）

這幾天解一個看起來簡單的小 issue，就是讓 browser 可以 autofill / autocomplete 登入表單中的欄位，結果意外的卡了超久 XDrz

目前在 Firefox / Safari 可以正常運作，但在 Chrome 則是時靈時不靈。先簡單筆記一下給將來的自己參考，順便看看有沒有過路神明會開示一下。

如何讓瀏覽器記住 input field 的值

有兩種方式

1. 由使用者自行利用瀏覽器內建的 autofill 功能
2. 由開發者撰寫會觸發 form submit 事件的 html elements

參考：Autofill: What web devs should know, but don’t - Cloud Four