轉眼間轉職也快滿一年了，想分享一下這一年來維護舊專案的心得！

接手一份缺乏文件或註解的專案，是人人都有機會歷經的噩夢，因為很難馬上理解這些 magic number 的意圖，蠻有可能一改就爆炸。

這時需要先分析現況，擬定短、中、長期的解決方案，短期先以熟悉專案為主，之後再進行效能、架構方面的改善。

短期

以前端來說，我認為短期可以聚焦在使用者體驗相關的部分，包含：

1. 操作回饋：給予使用者操作成功或失敗的提示
2. 等待回饋：進度條、讀取動畫、按鈕禁用
3. 頁面跳轉：閃爍、路由守衛、錯誤頁面、重載機制
4. 點擊防禦：表單提交、報表匯入匯出的防抖、節流、狀態鎖
5. 樣式：各種 CSS 屬性沒設好導致的問題

這些功能都集中在展示層（presentational，也是最容易改動的，不會涉及太多資料管理，好改就會立竿見影，可以拿來衝績效（喂）。

中期

處理過展示層後就能更快辨認 issue 類型是偏向展示層還是邏輯層（container）。

邏輯層通常涉及比較多外部資料的整合，必須先梳理好資料流才能進行改善，例如我在工作上常遇到的案例有：

1. 重複打出 API
2. 多個頁面依賴同個 API 資料
3. 狀態管理器將 UI 狀態跟資料狀態包在一起

這階段會偏向資料流與邏輯邊界的優化，搭配防抖和節流，可以預防很多效能問題。

但「正確地」梳理資料流不是簡單的事，如果能夠初步區分出展示層 / 邏輯層，相信勝過毫無準則地濫用工具。

---

長期

現職 9 個月以來，我持續在做：

1. 寫註解：
   補了一些我覺得很難懂的 side effect 的目的，註記各個元件的功能
2. 導入 TypeScript：
   但也就是先導入，畢竟一千多個檔案不可能突然改好 XD
3. 改善專案架構：
   原本的架構其實就是 Vite 自動建起來的那樣，很扁平，東西不會太難找，但缺乏一些分類準則，目前持續參考 FSD、原子設計等等的架構，用破壞性最小的方式慢慢改善
4. 導入單元測試：
   針對一些資料重組或新加入的函式去測，我也沒有寫測試的經驗，所以後續還要研究元件的測試
5. 可讀性改善：
   Code Spell Checker 先裝上去再說（？）。我會一塊一塊地讀程式碼，所以看到很多邏輯黏在一起沒有空行，實在蠻痛苦的

接下來也預計嘗試我在培訓時期還沒有做過的事，像是整合測試、E2E 測試等等。

升版本要做比較縝密的測試，雖然自己有拷貝一份來升升看，似乎沒什麼大問題，就是一些寫法或是底層實作已經被標記 deprecated 或是 removed，需要替換掉。

所以專案 build 成功，也不保證完全沒有地方壞掉，我可以確定一定有蠻多我沒測出來的問題。不過如果能慢慢把測試補上來，應該就可以考慮升版本了！

祝大家寫 code 快樂 🤣

縱使不在了也必然會留下什麼

看到廖老大的串文，也讓我開始回顧過去半年多的生涯， 去年上岸不久後有收到一個工作邀約：帶學生做專題。

比較特別的是，工作內容不會幫學生處理任何程式寫作的問題， 而是以分享經驗、提供資源的方式，引導學生去摸索與思考。

這份工作比較像是在訓練多方對齊的管理與溝通能力， 也可以透過學生想做的主題方向，刺激自己去研究一些沒碰過的知識。

一開始會自我懷疑：我一個轉職仔能勝任這份工作嗎？ 但仔細想想，以前在 bootcamp 不也都是學長姐在引導我們嗎？ 我們只要盡我們所能，讓學生有信心能繼續前進就可以了。

過去的記憶會慢慢串連

之前會覺得自己一直都沒有專精在一個領域， 不論美術、設計、遊戲開發等，都沒做出什麼令人滿意的成果。

「和自己比較」也是洧杰老師最常跟我們說的雞湯（？

得失心往往會讓人忽略： 雖然努力不一定能得到盡善盡美的成果，但過程會累積很多記憶， 不論是情緒的記憶、還是知識的記憶等等， 它們都會串聯成往後人生的一部分，這也是我開始擔任教練後，慢慢理解到的。 因此我相信，如果離開這個環境，未來的生活也會將這些記憶延續下去。

先說結論，不確定現在求職市場的要求如何，但以我去年的求職經驗來說，轉職可能需要一點點，但不多。

我前期學習只靠 Huli 大大的網站教材，也有試著做 LeetCode 大概十幾題，喚回一點演算法的記憶。刷題除了可以建立寫程式的邏輯基礎與流程思路外，對我目前工作上幫助最多的應該是效能和可讀性的改善。

以入門好朋友 Two Sum 為例，剛開始通常會直覺地用迴圈裡面再執行迴圈來解決，但當我們照它的建議，試著把時間複雜度降到 O(n) 的話，如果沒有資料結構實作的經驗，有點難馬上聯想到 hash table 的概念。

我剛入職時發現專案內有很多地方都可以用 hash table 解決，像是各種 find 或 includes 等等的陣列查詢、靜態資料的格式轉來轉去等等，如果有映射查值的概念，可讀性可以改善很多。

網站開發需要不同領域的知識串聯，一開始感覺會很離散，像是迴圈、閉包、設計模式， 好像跟刻畫面、接 API 一點關係也沒有，但是接觸的業務邏輯越來越多之後，會發現很多東西是環環相扣的。

所以不知道也沒關係，遇到的時候再補起來就好，畢竟寫程式的目的除了賺錢，還是要解決問題 💪

LeetCode 的題目可能有點生硬，可以先從 Codewar 開始培養語感，情境題或手寫題也是求職必考的！

刷題參考網站：

• Codewar
• ExplainThis
• GreatFrontEnd

接案公司會不斷有新專案在迭代，工作一兩年就有可能經手到數十個專案，因為業務會持續地向企業與政府單位拉案源，維持公司營運。

產品公司則是在經營自有產品，在不同的產品階段進去，就會接收到不同型態的任務。

過去前輩都會建議我們有機會進到產品公司就去試試看，而第二份工作我很幸運地能接觸到產品開發，並且能主導前端架構（因為只有我一個前端…）。

但我從來沒寫過 Vue，還好專案用的是 Composition API，因此從 React 的觀念轉換過去不會太難，也接觸到了 Monorepo 的概念。

開發日常

在接案公司裡一個人要同時經手數個專案，如果公司是走傳統的 MVC 架構，甚至一個人就要包辦前後端。不過專案通常至多三四個季度就會結案，開發週期很短，所以沒有什麼歷史包袱，可以說是用完就丟。只是在趕審查或結案時，加班加到並軌也是很常見的 XD

由於我進來產品公司時，專案已經到達 MVP 階段，所以我的工作大多是維護和重構，也嘗試把架構改得更好維護，偶爾需要開發新功能，開發壓力小很多，所以我能理解一般求職者偏好產品公司大於接案公司的原因。

但如同前面所說，產品的不同階段的任務內容落差會很大！

在產品早期階段，有機會歷經反覆重做的無間地獄，當利害關係人希望產品趕快發行變現，也是有可能加班加到並軌的…。

程式碼品質

接案公司比較常被討論的是一直趕趕趕結案，沒有明確的開發流程或是沒空做 Code Review，殘留的技術債就會很多，所以還蠻容易在保固合約的期間害到自己的維護工作。

不過即使是產品公司，規模小的新創也不一定有人力和餘力做控管，我現在維護的專案內容就是如此，像是拼錯字、語法誤用、語意不對、元件和資料流的設計問題，或是有一些奇怪的 side effect 在重複消耗流量等等，有許多過往留下的技術債需要慢慢清除。

所以在沒人把關的情況下，程式碼品質的好壞，就真的仰賴軟體工程師本人的造化和良心了…。

如果沒有規範或開發流程，對我來說在什麼地方工作差異都不大，但我不會說沒有這些東西的就是爛公司不要去，沒有的部分，我們可以試著建立和導入，這也是一個鍛鍊規劃能力的好機會（ 前提是賣肝賺錢的程度是自己可以接受的）。

從 bootcamp 畢業後，我的求職狀況不太樂觀，所以收到一兩個 offer 後就決定報到了。

第一份工作去到接案公司，基本上沒太多協作，一個專案就一兩個人支撐，大部分都是以後端 MVC 架構為主，前端負責切版和對接。每個人身上會有幾個專案在跑，所以時程蠻趕的，開發流程也相對混亂，有時還要配合甲方臨時調整需求。

這些狀況雖然對新手來說會有點壓力，但在台灣的軟體圈其實是很常見的。

不要在第一份工作中強求太多條件

雖然那時我大多能準時趕出來，但心裡還是很多抱怨，從制度、程式碼品質、到管理模式等等的，就是那種初入社會、對世上所有不公不義都忿忿不平的心情。

但本來就沒有真正完美的工作環境，想要好的薪資、有資深同事帶、完整的開發架構、良好的專案管理、健康的企業文化等等…同時滿足這些條件是很困難的，跟感情一樣 🤣

即使有這樣的天使公司，也可能某天公司突然解散、收到通知資遣、個人突發狀況沒辦法繼續工作等，對於人生的無常，我們只能預備，沒辦法預測。

後來在和培訓營的學弟妹聊怎麼選 offer 時，我的感想是：評估這些條件在自己心中的優先順序，再來篩選 offer，至少可以提醒自己這是一個評估過後的選擇，而不是一頭熱做的決定。

轉職仔第一份能握在手裡的選擇通常不多，我認為只要不是薪資遠低於市場行情、違反勞基法等離譜的條件，還是可以去試試看，但心態調適又是另一個話題了…有機會再分享 😊

決策的勇氣

俗話說小叮做事小叮噹，從過去的餐廚、行政，到現在的開發日常，我觀察到蠻多人對於「做決定」是感到害怕的。

倒不是說掌管公司營運或資產管理這方面的重責大任。

從買東西要不要報帳、午餐飲料要訂哪間大家會喜歡，到 commit message 可不可以這樣寫，PR 應不應該這樣發等等，我們可能因為怕犯錯，或是怕問了會被罵說「問什麼蠢問題」，這種恐懼往往令人下意識想要逃避，交給別人決定。

雖然任何決定的結果也許是不盡人意的，但如果能慢慢調適這些內耗的心情，我認為有「可以犯錯的空間」是很珍貴的，如果當時不去做決定，我們永遠也不知道結果是好是壞，不知道自己哪裡還可以改善，那麼進步是很有限的！

因此從我決定要轉職開始，我就想擺脫把命運交給別人決定的窠臼，嘗試很多我過去不喜歡或不敢做的事，希望將命運掌握在自己手裡。

成果不佳時難免會失落，不過這就如同重量訓練，只要持續下去就會適應越來越高的運動強度，沮喪的時間就會越來越短 😊