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

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

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

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

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

舉個最極端的例子,叫一個前端工程師去管財務算帳,怎麼想都不覺得這是合理的工作內容,那如果叫一個前端工程師去幫忙寫一些後端呢?似乎也有一些討論空間,再離前端更近一點,讓前端工程師寫前端專案部署的 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/

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

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

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

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