阿里巴巴高階程式設計師告訴你，前端到底難不難
先說一下個人認為：整個Web層的純業務開發可以說都沒有難度，後端業務基本就是CURD，前端基本就是資料渲染到檢視。
1.邏輯部分 : 後端業務層的程式碼大多數時候只是在處理資料庫中的資料，即便是雙十一這種場景大部分難點也基本是在業務框架（HSF分散式服務框架）、資料庫（OceanBase）、閘道器（SLB負載均衡）、快取（分散式KV儲存Tair）、計算平臺（Blink）、排程平臺（Sigma）等等層面被解決了，而不需要過度侵入業務層。所以對比前端將資料稍加處理渲染到頁面上，後端的CURD也沒有凸顯出什麼難度。
2.效能優化 ：服務端的效能優化基本離不開負載均衡、快取、資源池，至於IO優化（非同步、非阻塞）一般也是在框架或者語言層面解決了。
我承認有在有執行緒與鎖的語言（例如Java）中，併發場景下做好多執行緒優化和鎖的優化不簡單，但是併發程式設計的正規化不僅限於執行緒與鎖啊，還有CSP和Actor等等，我作為一名前端過了一遍Go語法和框架文件後就能快速上手寫出效能不算太差的後端Go程式碼了，基本不用去考慮執行緒和鎖。
資料結構這個點，一方面是由前後端的執行場景不同而決定的，服務端資料結構的優化確實可以給記憶體佔用、執行耗時帶來使用者數量級的減少，使用者量越大效果越可觀。而前端是執行在客戶端上的，大多數時候即使是10倍的速度提升，也不過是從0.01s優化成了0.001s，使用者體驗上的改變不是很大，甚至不如優化動畫帶來的提升明顯。另一方面，則是由於JS本身比較弱，沒有很成熟的類似於Java集合框架、C++ STL的資料結構庫，而且前端會對打包大小比較敏感，一般生產環境直接引入第三方庫前會反覆review。至於網路優化，大多是在架構的層面去做的，業務層不會去考慮。
3.工程複雜度： 我沒有在淘寶和天貓工作過，但我在淘票票（淘寶電影）實習過大半年。淘票票作為典型的淘系業務，確實符合你說的後端人數遠超前端，但這個很大程度上是業務和領域模型導致的。
最典型的例子，淘票票後端需要對接很多第三方的院線，有萬達、大地、幸福藍海等等；還會和第三方售票系統例如滿天星對接，而這些對前端幾乎是沒有感知、不需要也不應該去關注的。
而我現在所在的團隊，同樣由於業務的原因，前端人數是大於後端人數的，前端團隊維護的業務產品線與程式碼量絕不亞於後端。
總結
說了這麼多，個人認為，如果是狹義上的前端業務開發，幾乎是沒有難點的，後端也是。邏輯、效能優化、工程三個方面的複雜度都是由業務決定的， 不能一概而論的認為前端比後端複雜或者後端比前端複雜。
感謝閱讀
喜歡看小編文章的點個訂閱或者喜歡！小編每天都會跟大家分享文章