【軟體職涯】前端工程師轉換全端工程師一年心得

各位新年快樂，祝大家 2025 蛇年行大運！

這一次久違地跟大家分享技術相關心得，就如同標題所說，我在 2024 年時，在有兩年多的前端工程師工作經驗下轉到到了全端工程師的角色，並且已經在這個崗位上即將滿一年。

在這過去的一年中，有許多的心得想跟大家分享，那就讓我們直接開始吧！

轉換原因

我在第二份前端工程師的工作中，主要是想要累積更多有關產品開發的經驗，於是我從原本接案性質的公司轉換到了另外一個軟體公司的產品開發團隊。

意料之外，在這份工作中我遇到了一些不可抗力的挑戰，例如：產品的生命週期長，有許多雜七雜八的產品線與專案，又或者是在團隊開發資源豐富度，以及服務架構的自動化程度等，與我當初預期的不同，現在來看相對其他軟體公司也一樣常見軟體產品會有的挑戰。

然而對當時的我來說，僅僅有純前端的技能，像是 React 、 TypeScript 、UI Testing 等技能遠遠不足以優化現有的軟體架構，於是我在工作期間額外研究了 GitLab CI/CD、node.js 與一些基礎的 Linux 概念來協助我改善目前的開發環境，也在其中加入了一些自動化的服務。

但我仍認為遠遠不夠，在整合環境是總是沒有人可以跟我一起討論，不論是做錯了還是做對了，都要自己犧牲太多的額外時間來通靈，這讓我起心動念去往網頁不能同面向的技能水平拓展。

所以 2023 年時我開始慢慢看一些後端的技能樹，並且嘗試把一些自動化的技巧帶入專案中，在這個過程中，我透過朋友得知他的部門正缺一個前端背景的工程師，但在職務安排上是以全端為主的工作介紹，誤打誤撞我就在 2024 年時轉職成全端工程師

轉換初期挑戰

在轉換到全端工程師時，遇到幾個我認為滿有挑戰性的工作情境，這是我以前作為前端工程師角色時，比較少的遇見的。

• 協作方式：

以近五年的工作環境來說，前端工程師大部分都是轉職者，不論是文科還是理工科跳過來的轉職者大部分是有其他領域的工作經驗。

在有不同領域的工作經驗下，轉職的前端工程師在協作面會比較體貼、比較能用淺顯易懂的方式進行團隊的溝通。

但由於全端工程師有一些可能是本科生，本身就已經很習慣一些貼近機器的溝通方式，所以常常溝通上會容易進行比較跳躍性的溝通，話題容易失焦、又或者是要花很多時間對齊認知。

也有另外一種可能性是，全端工程師離使用者較遠，久而久之自成一套自己的溝通模式，在我剛轉換為全端工程師的角色時，真的花了很多時間適應。

• 容錯率：

由於後端服務是所有軟體服務的基礎建設與參照，所以在一開始轉換時我常常會遇到自己想的不夠全面的狀況，因為資料結構或是商業邏輯一旦定型，其他配合的同事，例如：APP、前端、後端，甚至是網管的同時都需要一併配合，因此在開發功能時容錯率低、一定要多方驗證流程與正確性才能上線。

也因為牽一髮動全身的特性，在規劃流程時在後端的服務架構就需要花更多的時間思考與試做，這跟以往我在前端的時的開發方式與嚴謹性完全不一樣。

• 除錯手法：

我自己在後端領域最不習慣的就是如何追蹤錯誤， 我大概是到今年初時，自己 own 一個內部的服務（前後端含維運），自己從頭到尾起了全新的後端服務與申請主機服務，並且打通了 ELK 服務後我才比較知道怎麼看 Log 與分析錯誤的成因。

除了透過 Log 來追蹤錯誤外，在針對機器防火牆有沒有開、服務是不是還活著等狀況，我也是花了好長一段時間才搞懂一些網路層的概念以及對應除錯手法，例如：查看對應的 port 或是 dns 服務有沒有正常運作。

身為對機器熱情一般般的我來說，當服務異常時，要能準確地查看成因依然是需要持續累積與學習的地方。

而從前端到全端的轉換，真的會獲得不一樣的 Debug 方式與經驗，雖然一開始不是很適應，但卻是我收穫最多的一個技能。

技術棧（tech stacks）

以前端來說我使用的技術一樣是以 React 生態系為主，這一點倒是沒有變得太多，但部署服務有搭配 Nginx 作為 Proxy server。

後端的工具就變化地很多，後端服務的部分主要使用 Kotlin + Spring Boot 來開發，DB 的部分使用 Mongo DB 為主，自動化的工具使用開源的 Jenkins。

前陣子因為部門有規劃論調機制，因此學了一陣子的 Flutter 、Dart 來支援跨平台服務的同事。

透過這一年來的經驗，真的有感受到全端工程師這個角色時常水平拓展技術能力，如果沒有特別花時間研究，真的會變成大概用一用有做出東西能懂就好的狀況，這一點我覺得是作為全端工程師要適當取捨與留意的部分。

工作內容

從前端到全端，工作內容簡單概括的話：「工作職責變大變廣」，也因為前後端服務都自己、又或者同個團隊的同事負責，可以配合、異動的深度與廣度與我以前單純寫前端是完全不同個世界。

雖然工作的內容變深變廣，但對我來說是一件踏實的事，因為對於整體的服務掌控內容變多了，姑且不談要做多麽複雜的功能，至少在需要交付內容時，你會更知道要怎麼截長補短，以及在可行性、優先順序上作出較適合的決策。

可以說如果我一直維持寫前端的工作的話，我可能永遠不會體會到開發軟體服務時，在有限的資源中該怎麼做出最適當決策。

雖然我並不是什麼特別會寫、資深的工程師，但我認為工程師如果可以領悟到體制內的局勢與自身角色的職責，在開發上可以省去不少力氣與跟其他人產生摩擦的機會。

AI 元年的時代紅利

在我轉換到全端的那一年，可以說是AI 服務起飛並且有許多成熟應用的階段，而老實說我也透過 AI 的協助能輕鬆掌握大部分工作上的需求，可以說是搭上 AI 的順風車，也透過 AI 轉換到一個更具競爭力的跑道。

然而我相信有許多讀者目前正在考慮轉職，又或者在思考要不要從自己的領域往後端、資料面的領域去做延伸，我的建議是：如果你是有經驗的開發者，那恭喜你可以透過 AI 作為槓桿撬動你的職涯路線。

對於完全沒有經驗的轉職者來說，我會建議你需要以自身興趣優先作為轉職的考量，因為軟體服務這個領域門檻的確因為 AI 的誕生變得更高了，面試的流程可能也因此變得更加嚴謹，如果你是看到網路上轉職班的廣告，真的需要好好深思並且多做功課。

而我覺得自己真的很幸運，一個普通努力的轉職仔能搭上 AI 列車轉換成全端，除了努力還要感謝這個時代科技的演進。

滿一年心得

覺得從前端轉換到全端的這段時間時間流逝得很慢，尤其是當有需要立即處理的問題需要釐清與調整的時候，有一種從頭當新人的感受。

老實說，我對於自己在軟體業職涯的規劃與想像大概也在一年多以前有點卡關，至目前為止也跟大家一樣處於邊走邊看的狀況。

我可以很確定的說自己喜歡這個領域，也願意花時間深耕，不過也許在未來的這段時間內，我會嘗試看看在這個新的領域有沒有什麼東西可以引起我的興趣，能激起我的興趣、讓我特別再深入耕耘研究。

以上大概就是我目前轉換跑道一年以來的心得啦，我覺得相較於以往的轉職回顧，這一篇的內容可能較於平淡，希望各位沒有什麼感受到我些微職業倦怠的心情哈哈，而希望來年還會有機會跟各位分享年度的職涯回顧。

感謝看到這裡的每一個你，我是 Vivian ，我們下次見啦。