前段時間離開做直播產業的前東家，整理一下這兩年遇到甚麼事。
每個階段都要來寫一篇心得，更多時候是怕自己過得太無趣，忘記過去發生的事情與學到的經驗。
寫完之後覺得有點流水帳，應該拆開根據主題寫比較好。
入職背景: 0 經驗 Junior Reactjs ，非 0 經驗前端工程師
前一份工作寫 Angular (v7), 只寫約半年，爛 code 多到吐那種。
轉寫 React.js 看官網隨便摸摸 + 跑各種面試，也花了兩個月才上岸
當時薪水定位就是 「非0經驗 Junior Reactjs 前端工程師」
最自豪是學完整套 《You Don’t Know JS》。
2020 年 4 月：onboarding，用 React 不會 Redux
onboarding 第一個月蠻痛苦的，
同樣時期入職，比我年輕的前端夥伴有一年左右撰寫 React 經驗，
我當時連 Redux 都還不會寫 (redux-saga)。
那段時間 Huli 有來公司面試，趁這個時候拼命求助、打擾 Huli 大大，學習各種經驗、各式偷師。
第一月的這段期間，真的是我最難熬的時候，一度還跑去找 BOSS 1 on 1 聊聊，想說是不是我要主動離職比較好。
因為我覺得我就是公司的廢人。
那段時間剛好簽約挖角實況紫色學校平台的最大亂源兄弟，配合原本遊戲直播平台 rebrand 和各式業務，兩個資深工程師各種加班加到吐，我只能做最簡單那種一頁活動，還要搞兩三天。
面談後 BOSS 笑著說不要給自己太大壓力，他們本來就沒有預期新人進來就要超強。
(對比同樣時期入職，比我年輕的前端夥伴都開始 commit code QQ)
2020 年 5 月 入職二個月: 承接內部專案，重點是要學習「溝通」
遊戲直播平台順利上線後一段時間，兩位資深工程師也不再加班，我也開始可以承接小型日常開發任務，看似都沒啥問題。
資深工程師這時候給我兩個任務選擇:
1. 公司主要直播產品的 web 版開發
2. 內部系統新需求
這時候沒想到，我選擇的內部系統，會成為陪伴我入職到離職這段期間，磨滅不去的最大的痛苦。 (離職前才稍微好一點，感謝夥伴的努力 QQ。)
這個內部系統基於 Ant Design of React，理論上不用寫啥元件，但是我第一個 task 只是加上一顆 button 就卡了三天。
- 內部系統從開始寫到上線只花一個多月快兩個月，元件拆分比較髒
- 當時 next.js 8.x 版 server side 相關 api 都沒有提供，所以當時又多套一層 nest.js 去處理一些 server side 的 code。
- 應該是因為時間很趕，同一套 code base 塞前/後台，用 flag 去區分前後台，然後 nest.js 裡面讀 flag 來 redirect 前/後台、Auth。
- 需求文件沒有人整理，一堆舊資料夾雜新資料，想知道最新版本需求還要查群組對話紀錄
更不幸的是，原本開發維護"遊戲直播平台"學的 redux-saga ，這個內部系統 state management 變成 redux-observable ，光追資料流就又追到吐血。
苦戰三天才發現，原來加那個 button 和上述技術點都沒關西 :)
需求只是丟一個 button 和 event handler 即可，然而這個需求是需求方 direct message 資深工程師，所以我查不到 。
:)
:P
:>
可惜，我那時還沒有學到教訓，好好「確認需求範疇」，溝通方式依然是
我 <— > 資深工程師 < — > 需求方
下一個任務分配下來，需要擴充更多功能，
資深工程師受不了我每天煩他(我猜的 XD) ，才拉個群組讓我直接和需求溝通，那位資深工程師偶爾確認狀況會看一下。
之前花的時間研究 code base 在這次開發上都沒有浪費，我很快給出解決方案和資深工程師討論、然後實作。
然後就爆了
我選的方案是基於之前沒用過的 API，對比原本方案就只是暴力解法做合成，
因為我覺得要處理暴力解，一個一個調很煩，也覺得用新 API 很帥。
結果就是用新 API 多寫一堆幹 code ，還是有一段避不了要花跟原本方案一樣的時間去暴力解定位問題。
最後導致 deadline 偏差，還好當初資深工程師給出去的時間有抓 buffer，才在期限內給出去。
然後就又爆了
交付給需求方後，才發現我做出的方案和需求方要的功能不一樣。
具體來說是有很多追加的新需求沒處理到，但是這時資深工程師已經差不多放生我們討論。
不會有人協助我確認需求，我也不知道要先整理一個版本 release ，後續需求再來疊代，
我。需。求。全。接。了。
我接需求的原則就是你給什麼，我就
「幹你娘接爆」
沒錯，就是幹你娘接爆，老子才不管甚麼公司 Deadline 三小的就無限延期延下去，最終延期兩個禮拜。
我還記得，我接這個需求後的第三週， BOSS 終於察覺不對勁跑來跟我說，這個需求不是兩週前要給，怎麼還沒完成，你有頭緒嗎？
我他媽的怎麼會知道。
這也是我第一次覺得靠北工程師版上都不是笑話 :(
這些失敗讓我學到四件事：
- 和需求方溝通要定義明確交付的成果，
無限追加的需求要會擋掉或是請對方排序權重優先序。 - 要會 show off 自己做得好的表現，過度謙虛會讓主管覺得你沒做事。
- 指派的任務是開發同時和需求接洽，如果處理不來(能力不足)要說明難點，有問題時提早尋求幫忙或是尋求資源。
- 不要接幹任務，幹任務給資深工程師處理，對產能(績效考核)來說 CP 高，自己也不用滿手髒又爛名聲爛績效。
- code base 掌握度夠高，估時才會准
四大天王五個人是常識 (?
2020 年 6–7 月： 入職蜜月期結束，前端資深工程師大逃殺
還記得剛入職，有兩個比較資深的前端工程師，這段期間陸續離職，有所感悟，寫了這一篇
前端專案大概剩下菜鳥，待退離職的資深工程師們，帶著菜鳥參加蠻多場的面試。
菜鳥們才是未來會和通過的面試者合作專案，所以待退離職的資深工程師們只是做技術上的把關。
這段期間蠻有趣的，剛入職沒多久的菜鳥可以參與面試流程，大概知道自己實力在哪個位置，或是看到一些厲害的人，期望未來可以共事、從對方的經驗中學習。
每一次參加共同面試都像是在做練習題，再次鞏固一下自己的基礎。
心態也相對比較多是「討論」，反正技術問題資深工程師會把關，討論焦點就會著重在未來共事的情境。
2020 年 Q3：混亂期 新主管、新的開始
差不多之前面試我們進來的資深工程師都離職了，BOSS 有找另一個資深工程師進來帶前端團隊。
最大的差別是之前資深工程師比較像是 mentor ，這次補進來的資深工程師很明顯就是 team leader。
這段期間也看看不同形式的管理方式，補進來的 team leader 也有帶一個之前團隊的成員，補足所缺的開發量能。
這時組裡沒有大人，因為 team leader 剛進公司，還在花時間熟悉、理解公司文化。
所有面試、工作任務分派都是我們幾個菜鳥說了算，我們也照之前離職的資深工程師舊有的方式去處理事情。
rebrand 後的遊戲直播平台有需求就去補補人，需求做完就回來做公司主要直播產品的 web 版開發，這時也沒有內部需求的坑要補，算是開發上軌道了，工作上蠻自由。
但也忽然覺得離職的兩位資深工程師可以完成目前團隊 5–6 人的工作量，自己要多多加油。
2020 年 Q4：沒啥印象的日常需求開發
team leader 熟悉公司之後，帶來很多比較正規的開發習慣或流程，以前面試、工作任務分派的工作也被接手回去。
這時已經是正常公司的開發日常，沒什麼值得提的，也沒甚麼好回憶。
基本上就是修修 bug，應付新需求學習新套件。
這時候新補進來的夥伴，提供一個之前用起來開發體感不錯的套件 Redux Toolkit ，
我也早就脫離剛加入那種不知道怎麼寫 code，無助或是失落的感覺。
少數時候也有遇到煩心事，比如:
- 同事的 code style 很奇怪，但又很難說服對方調整
- 髒 code 可以過 code review
- 有些問題追很久才發現根本和我們無關，但是鍋通常丟給 client team
- 需求許願池，以前打掉的需求又要拿回來談的鬼打牆
也是因為遇到這些問題，開始補足之前沒有學習好的錯誤打點紀錄、更好的溝通方式、團隊合作的細節，此時的目標已經是希望是幫助整體團隊的工程品質提升。
2021 年 Q1：公司新產品，從零到一，如何評估導入一項新技術
公司打算做新方向，原本遊戲直播平台做新功能的需求也放緩，人力多數丟去做新專案。
這時候體驗內部新創的好處，很多新技術可以嘗試，做了一波好玩的架構，在考量公司舊有專案上做不少變化。
比較難的是要考慮公司原有技術架構，避免一間公司要學三種 state management method (redux-saga, redux-observable, Mobx) and redux-toolkit 這種神奇的現象。
最後權衡的改動 :
- 拔掉 TypeScript，因為 jeremy 大大倡議 (x)
其實是新專案時間內一定要上線，新聞稿好像都弄好了，寫 TypeScript 工時應該會爆炸。
Review 當時選擇: 開發一年多快兩年，多數時候都是兩人開發，互相 code review 好像沒有 TypeScript 也不會遇到太多問題。 - 導入 Styled System，因為當時還是 styled-components 的專案居多，看很多 UI library 的 API 都長 Styled System 那種模式。
Review 當時選擇: 如果現在新專案 Windi/tailwind CSS 之類的應該會是更好的選擇，utility-first 真的太香了，只是真 D 沒想到 Styled system 後來沒維護了。
當然也有做不夠好的:
- 舊專案套件沒有全砍:
輪播之類的小套件，後續升級也還行不費事。 - 搬遷套件的壞習慣:
團隊有人有上 GitHub 找套件，把套件 source code 複製進 code base ，而不使用套件管理系統管理，我學他不小心拉一堆 source code (material modal) 進 code base … 離職前有發 mr 修復，我很抱歉 :( - 不敢拔掉 Redux:
Finite State Machines 如 XState 寫狀態應該是最舒服的。 只是這樣加下去真的就是一個專案一套 state management ，所以不敢加了 :(
同樣是 2021 年 （上）：公司又有新產品，從 0.1 開始組建專案
同事架構選型，選完開發不到一個月就離職，要繼續還是拆掉?
這次很像之前從零到一，又不完全像。
2021 剛好也是第一波大家開始習慣 WFH 的日常。
這段期間唯一有印象的是 1 on 1 想給 BOSS 的反饋
我覺得我這個組很不健康，多數時候都只有一個人，pm、營運又有重大變革，整體開發人數、進度都落後其他 app team 很多
整個想起來剛入職的內部系統慘況 :(
這段期間也見證好用的前端，缺起來是真的半年以上找不到人 ==
同樣是 2021 年 （下） : 後 WFH 時代的開發
這時團隊人數也補足了。
之前自己蠻痛苦在「到職上工第一個 task」，所以趁這個機會練習看看，把自己規劃好的任務，讓出去給別人執行完成。
真的挺難的，後來也理解到自己還是非常需要把產品完成、親手做出來的成就感。
後來其實蠻後悔，雖然也蠻慶幸當初有這個經驗，但估計短時間的未來我不會這樣做了，哈哈
2022 年 （上）
新產品做一段時間，在新創公司中最不想遇到的事情，但是一定會遇到的事情發生了：公司要調整營運方向，正在做的產品被腰斬。
公司這次沒有新產品、前端團隊開發量能也非常充足，
最後兩、三個月中，同一個念頭一直在腦海裡浮現……
我又覺得我就是公司的廢人了，
不過這次不是因為我的能力不足了 :)
2022 年 （下）: 離職
先休息看看接下來要做什麼。
這段職涯應該要做比較好，但是沒做到的事
- COVID-19 期間當藉口，就沒有任何社群參與。
- 寫文章只在公司內部分享，就沒有寫部落格了。
- CYBERSEC 2021 臺灣資安大會到底在做甚麼 (參展心得分享)
- Security Headers (經典攻擊介紹) / config CSP
- Testing React Web Applications
Core principles, how does testing frameworks works,
demo cases: jest, testing-library - LQIPs 實作 POC
- GraphQL intro
- brief web3 research
小結:
寫一寫發現，越寫越沒東西寫，
後期可以寫得基本上都是技術細節，主要學東西的感覺只有前一年半吧。
回想之後，每天都像是 auto-run ，真的沒啥印象。
所以才覺得自己過得太無趣，趕快寫一寫記下來，怕不寫會忘記過去發生的事情，與學到的經驗。
或許有空再更新最近一年吧，看下來覺得有點偷懶。
2022.08.06
