某次面試時，技術主管向我問道：

「您有沒有參與過技術小聚或是一些研討會呢？」

雖然我不排斥參與活動，但過去一兩年下來，公開的活動也就去過兩三場，反而回去 bootcamp 分享心得的次數更多，可謂是窩在自己的小圈圈 XD

除了實體活動，社群網路也是一種社群，例如近年很多團體都選擇移駕到 Discord 上管理社群頻道、舉辦讀書會，或是 Threads 也有很多串文被爆炸式傳播和討論。

實體活動更容易拓展人脈，在寒暄的過程中交換一些秘辛（？），社群網路則可以快速取得新知、新聞，無論透過哪種管道都能增廣見聞，所以參與社群絕對有實際效益，至少能刺激出一些社交能量。

過濾資訊

實體活動可以直接觀察到對方，因此多少會因為對方的肢體語言讓我們辨認出一些資訊。

但社群網路大多是文字討論，在這個講求流量的時代，難免會運用一些誇張的措辭來吸引關注，像是「不能不會」、「必學」、「殺手級」、「核彈級」等等，容易引起資訊焦慮的形容詞。

思考自己真正需要的資訊是什麼之後，再去查證資訊來源的可靠性，查證的過程一定會有所收穫，也會慢慢養成剖析內容、明辨是非的習慣！

有時候我們需要的並不多，只需要先花一些時間了解自己。

接受衝突

「學校就是社會的縮影」。

大家從小到大應該多少聽過這句話吧？有人的地方就有社會，人多了就容易因為立場不同而產生衝突。

社群網路的衝突更加頻繁，因為與其比拳頭，打字留言的成本和風險非常低，只要不涉及誹謗和人身攻擊。所以很多留言並非志在討論，只是在抒發情緒、故意讓人不舒服，就是那種特地跑到你家門口丟垃圾，丟了就跑，你想罵他還找不到人的感覺。

即使是認真討論的留言，還是感覺得出火藥味，因為在不用面對面的情況下，用字會比日常口語還更直接粗暴，尤其是彼此的觀點討論不出一個共識的時候，不是三字經那種粗暴，而是「不懂哪裡難？」、「什麼咖？」、「這種程度？」之類的，語境大概類似這樣（如有雷同，那就雷同）。

和文學小說不同，就事論事的文字通常不經修飾，感覺比較冰冷，因此可以不用帶著任何情緒去看，和 code review 一樣，只要過濾出對你有幫助的資訊就好。至於過程…真的不用想太多，抽離情緒後再來看待這些留言，我相信很快就會發現，哪些留言是真的在探討問題的本質，哪些留言只是為了辯輸贏、維護自己的立場。

不要讓這些廉價的留言換取你的不開心！

小結

上述的情境都和「情緒」有關，這些情緒每天都在影響我們日常生活，例如衝動性購物、錯失恐懼症等等，在資訊發達的時代下，隨時都有大量的內容在試圖挑起我們的情緒，奪走我們的注意力。

所以參與社群活動時就保持平常心吧！記住心裡的那把尺，慢慢養成這個混亂的時代中需要的判斷力了，相信就不會時常感到焦慮，並且能正面化解焦慮的情緒！

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

接手一份缺乏文件或註解的專案，是人人都有機會歷經的噩夢，因為很難馬上理解這些 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 在重複消耗流量等等，有許多過往留下的技術債需要慢慢清除。

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

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