🔧 阿川の電商水電行
Shopify 顧問、維護與客製化
💡
小任務 / 單次支援方案
單次處理 Shopify 修正/微調
⭐️
維護方案
每月 Shopify 技術支援 + 小修改 + 諮詢
🚀
專案建置
Shopify 功能導入、培訓 + 分階段交付

在經濟下行的大背景下,越來越多的中小型企業開始放棄“前後端分離”的人員配置,開始採用“全棧式開發”的模式來進行研發費用的節省。

這方法真的那麼好嗎?

作為一名從“全棧開發”自我阉割成“前端開發”的逆行研發,我有很多話想說。

先從一個活生生的真實案例開始吧。

我認識一個非常優秀的全棧開發者,因為名字最後一個字是陽,所以被大家稱為“陽神”。

1. “陽神”的“神狗二相性”

陽神當然是厲害的。

他不僅精通後端開發,更是對前端了解得非常深。這樣來說吧:

當他作為後端開發時,他可以是那群後端同事裡庫表設計最清晰、代碼最規範、效率最高的後端。

當他作為前端開發時,他除了比幾位高級別前端稍遜一籌外,效率和UI還原性都非常高,還會主動封裝組件減少耦合。

但是非常奇怪的事情總是會發生,因為一旦陽神不是全職的“後端”或者“前端”時,一旦讓他同時操刀“後端+前端”開發任務,作為一名“全棧”來進行業務推進時,他的表現會讓人感到驚訝:

他會寫出設計糟糕、不規範、職責混亂的代碼。

這個現象我把它戲稱為“陽神”的“神狗二相性”,作為單一職責時他是“陽神”,同時兼任多職時,他就有很大的可能降格為“陽狗”。

image

為什麼呢?這是陽神主觀上讓自己寫更糟糕的代碼嗎?

不是的兄弟,不是的。

這是系統性的崩塌,幾乎不以人的意志為轉移。換我去也是一樣,換你去也是一樣。

2. 分工粗化必然導致技術細節的差異

從前,在軟體開發的古老行會裡,一個學徒需要花很多年才能出師,專門做一把椅子,或者專門雕一朵花。現在,你被要求從伐木到拋光,從結構力學到表面美學,全部一手包辦。

生產力在發展,對人的技能要求也在發展。

因此“分工細化”成為了工業革命之後完全不可逆的趨勢。

在IT產業上也是如此。

“軟體開發”經過多年被細化出了前端開發、後端開發、客戶端開發、大數據開發等等多種不同的細分職業。

但是現在有人想通過粗化職業分工來達到“提效”的目的,在我眼中這就是在和客觀規律對著幹。

人的精力是守恆的。當你需要同時關心useEffect的依賴數組會不會導致無限渲染,和kubectl的配置能不能正確拉起Pod時,你的注意力就被稀釋了。你不再有那種“針對一個領域,往深裡鑽,鑽到冒油”的奢侈。

當你腦袋裡冒出了一個關於前端工程化優化的問題時,身為全棧的你會本能地冒出另一個念頭:

在整個全棧體系內,前端工程化優化是多麼邊角料且無關痛痒的問題啊,我去深入研究和解決它的性價比實在太低了,算了不想了。

如此一來,無論是後端的性能問題還是前端的性能問題都會變得無關緊要。

image

結果是,只有業務問題是全棧開發要關心的問題。

3. “崗位對立”與“自我妥協”

在日常開發中,前端開發和後端開發之間互相吐槽爭論是再正常不過的話題,而且爭論的核心非常簡單易懂:

前端:這事兒不能在後端做嗎?

後端:這事兒前端不能做嗎?

可以的,兄弟,最後你會發現都是可以的,代碼裡大部分的事情無論是在瀏覽器端完成還是在伺服器里完成都是可行的。

但是,總有一個“哪方更適合做”吧?

  • 一個大屏頁面的幾萬十幾萬條的數據統計,是應該後端做還是前端做?
  • 業務數據到Echarts展示數據的格式轉換應該後端做還是前端做?
  • 使用者數據權限的過濾應該後端做還是前端做?
  • 一個列表到底要做真分頁還是假分頁?
  • 列表已經返回了全量實體信息,為什麼還要再增加一個詳情接口?

這都是日常開發時前端和後端都會去爭論思考的問題,身處不同的職位,就會引入不同的立場和思考。

  • 前端需要去思考頁面刷新後狀態的留存,JavaScript單線程下大量數據處理的卡頓,頁面DOM樹爆表的困境。
  • 後端也需要思考並發下伺服器資源和內存的分配,可能的死鎖問題,以及使用者的無狀態token如何處理等。

前後端的“爭吵”和觀點輸出是不可避免的。

真理總是越辯越清晰的,後續討論出的結果多半是最有利於當前現狀的。

但如果“前後端”都是同一個人呢?

全棧模式,完美地消滅了這種“有益的摩擦”。當你自己和自己聯調時,你不會給自己提挑戰靈魂的問題。你不會問:“這個API設計是否RESTful?”因為你趕時間。你也不會糾結:“這個組件的可訪問性夠好了嗎?”因為你還得去部署伺服器。

這兩種思想在你的大腦裡打架,最終往往不是最優解勝出,而是最省事的那個方案活了下來。

於是,你的代碼裡充滿了“差不多就行”的妥協。這種妥協,一兩個無所謂,當成百上千個“差不多”堆積起來時,品質的基礎就酥了。

內部摩擦的消失,使得代碼在誕生之初就缺少了一道品質校驗的工序。它順滑地流向生產環境,然後,在某個深夜,轟然引爆。

4. 工程的“不可能三角”

軟體開發領域有一個著名的“不可能三角”:

快、好、省,你只能選兩樣。

image

全棧模式,在管理者眼中,完美地實現了“省”(一個人幹兩個人的活)和“快”(省去溝通成本)。那麼,被犧牲掉的是誰?

雪崩時,沒有一片雪花是無辜的。但更重要的是,當結構性雪崩發生時,問責任何一片雪花,都意義不大。

至於“快、好、省”這三兄弟怎麼選?

那主要看老闆的認知和他的錢包了。


原文出處:https://juejin.cn/post/7555387521451606068


精選技術文章翻譯,幫助開發者持續吸收新知。

共有 0 則留言


精選技術文章翻譯,幫助開發者持續吸收新知。
🏆 本月排行榜
🥇
站長阿川
📝15   💬8   ❤️4
655
🥈
我愛JS
📝3   💬11   ❤️7
213
🥉
AppleLily
📝1   💬4   ❤️1
71
#4
御魂
💬1  
3
評分標準:發文×10 + 留言×3 + 獲讚×5 + 點讚×1 + 瀏覽數÷10
本數據每小時更新一次
🔧 阿川の電商水電行
Shopify 顧問、維護與客製化
💡
小任務 / 單次支援方案
單次處理 Shopify 修正/微調
⭐️
維護方案
每月 Shopify 技術支援 + 小修改 + 諮詢
🚀
專案建置
Shopify 功能導入、培訓 + 分階段交付