最近看到前端臉書討論區的一篇貼文之後有一些感想，就順便寫下來了。

那篇貼文主要是在說不要把自己侷限在前端工程師，整個網頁的世界還有很多值得探索的地方，例如說後端啦或是一些部署的東西等等。

雖然說我不覺得每個人都需要往全端邁進，都必須擁有「可以在工作上寫後端程式碼」的能力，但我認同這個概念的大方向，就是「不要被前端所侷限住了」。

身為前端工程師，理所當然我們必須懂前端，必須知道怎麼樣做出一個網站的前端，那除了前端之外的其他任務呢？我們也有義務需要參與嗎？還是可以用：「我只是前端，這應該是___負責的」這個理由去拒絕一些任務？

這個回答顯然會根據任務的不同而改變。

舉個最極端的例子，叫一個前端工程師去管財務算帳，怎麼想都不覺得這是合理的工作內容，那如果叫一個前端工程師去幫忙寫一些後端呢？似乎也有一些討論空間，再離前端更近一點，讓前端工程師寫前端專案部署的 Dockerfile 呢？這算是前端必須負責的，還是公司的 SRE 要做的呢？

先不管一些極端的案例，在實際工作中，本來就會有許多模糊的狀況存在，有些並沒有對錯，而你也可以做選擇。你可以選擇把這些工作接下來，也可以選擇不接，或甚至是去網路上發文，問說大家在工作上是不是都這樣，這樣是否合理。

但就算不合理，不代表它不存在，合不合理跟現實狀況是兩回事，就像臺灣很多道路設計也不合理，但因為各種原因，它就是存在。從現實面來看，你已經無法避開「走在設計不良的道路」上這件事情，因此你能做的第一點是參與公共事務，盡可能讓未來不要出現這些不合理的設計，第二點是走在路上的時候小心一點，盡可能增加自己的存活機率，或也可以不管它，當作沒看到。

而我前面提的狀況也是這樣的，先不論合不合理，現實狀況就是在我自己的職涯當中，就算職稱是「前端工程師」，也不保證真的只會碰到前端，完全不用接觸伺服器或是其他部分。

而且仔細想一想，就會發現這件事情很合理。

我這邊指的「接觸」不是代表要你去寫後端程式，我自己是幾乎沒碰過這種狀況，更多時候其實是開發上必然會碰到的。舉例來說，前端專案寫完之後應該怎麼部署？這件事情當然可以跟 SRE 討論，但你自己必須先知道這個專案怎麼 build，怎麼跑起來，要下哪些指令，最後是以什麼樣的形式建置出來。

是一些靜態檔案而已，還是需要一台新的 server 動態跑？需要一台 server 的話，該怎麼跑起來？有什麼其他需求？

再來就是實際開發的時候，有些狀況可能需要在本機把後端跑起來，我有碰過用 docker 的狀況，也有碰過需要自己安裝環境跑 Java、MySQL 以及 Nginx 等等一堆有的沒有的東西，還需要自己進資料庫下一些指令，才能成功把專案跑起來。

這些都代表在工作上你很有可能會需要一些除了 JavaScript 以外的知識。

再者，身為網頁前端工程師，我認為後端知識本來就是必備的，就像我之前寫過的紮實的網頁前端學習路線與資源推薦有提到：

「網頁前端」，這同時代表著「網頁裡的前端」以及「網頁與前端」兩個意思。網頁分為前端跟後端，如果你只理解前端，你是永遠不可能理解整個網頁的。就如同我在第五點網路基礎概念裡面提到的一樣，許多人都是缺乏了整體概念，才會導致出錯時定位錯問題，或是根本不知道問題發生在哪裡。學習後端最主要的理由就是補齊自己缺少的概念，當發生問題時你才知道問題到底出在哪裡。

如果只把自己侷限在「HTML、CSS 與 JavaScript」，那就看不到網站的全貌，缺少了整體架構的概念。

我自己在工作中其實也寫過一點後端，但通常都是自己要求的，我會說：「這個簡單，我來吧！」。例如說要寫一個產生 PDF 報告的服務好了，PDF 這一段是 HTML 轉 PDF，顯然是前端工程師比較適合做，而後端的話就是簡單開一個 server 接收資料，丟給 headless browser 轉換以後再回傳檔案，我覺得自己做比較快，也比較能掌握整個服務，就自己來了。

我會寫一些後端，但不會稱自己是全端工程師，也不會在工作上主動去接後端的任務。但如果真的需要救火或是支援，我也可以擔下這個任務。

這是在技術上不被前端所侷限，可以讓自己擁有更多技能，而還有一種則是不被團隊中的角色所侷限，就是我前幾天看的 Taiming 寫的【心得】2023 WebConf 為自己留下記錄的參與心得中，PJ 提到的觀念：

PJ 也告訴我們一個很重要的觀念，「你也是團隊的一份子，不要被角色侷限住」。DevOps 相關的建置，一定要由 DevOps 工程師來做嗎？這流程的東西不就是 PM 要處理的，關我什麼事？但如果我們自己放下這些想法上的侷限，或許團隊就會因為我們的付出而變得更好。

開頭講的臉書那篇貼文談的比較像是技術上的發展，而 PJ 那一段則是再往外擴張到團隊，一個人強終究是一個人，但如果能帶動整個團隊的發展，能發揮的影響力就更大，通常也代表著在工作上你的價值會更高。

但說穿了，最有價值的能力就是「解決問題」，如果有個人像小叮噹那樣什麼問題都可以變出一個法寶來解決，自然也就會很有價值。

可是通常我們沒這麼厲害，光是能做到「解決技術相關的問題」就不容易了，這個的意思是小明原先可能做後端，接著公司說：「我們接下來要做一些資料工程的建置，交給你負責吧」，於是小明跑去從零開始研究資料工程有哪些東西要做，然後把這個架構都弄好，專案順利上線。

過了半年，公司又跟小明說：「最近 Web3 很夯，你去研究一下吧，順便寫個智慧合約出來看看」，於是小明轉去研究這個領域，還真的開始開發智慧合約，並且在時間內交出了 MVP。

像小明這種人就是「能夠解決問題的人」，以我自己的經驗來說，這種人大概是最難找的，但同時也是對公司比較有價值的。

如果身為前端工程師，卻完全只懂網頁前端的東西，那或許成為前端不是選擇，而是侷限，是「除了這個我其他都做不了，所以只能做前端」。

如果能夠學會更多東西，讓前端成為選擇，那不是很棒嗎？就有了更多的職涯發展空間，也有了更多選擇權。

當然，如果真的只會前端但是做到超級深也是很有價值的，成為「能夠解決特定領域的艱深問題」的人，像是對瀏覽器運作超級熟，各種前端原理跟可能碰到問題的地方都暸若指掌之類的。

但問題就會變成以實際層面來看，有多少公司需要這種人呢？是需要「能夠解決各種技術整合問題」的需求多，還是「能夠解決特定領域的艱深問題」的多呢？另一方面，你想成為哪一種呢？

又或許是那句經典名言：「我全都要」。

最理想的情形大概是架構師（Architect）這種角色了，就像架構師 (Architect) 的角色這篇裡面提到的圖一樣，來源：http://www.codingthearchitecture.com/presentations/sa2009-broadening-the-t/

既能解決各種技術問題，同時也具有一定的深度。

不過這有點扯遠就是了，我一開始想聊的其實只有底下幾句。

想當個好的前端工程師，後端是必備技能，你不一定需要在工作上寫後端，但必須知道後端是怎麼運作的，不能完全沒有概念，否則永遠都掌握不到全貌。

讓前端成為你的選擇，而不是侷限。