前端開發的難點到底在什麼地方?
這兩年由於單身時間很多,絕大部分時間都投入到學習中,基本上Java跟前端雙修,前一陣子由於部門前端實在是招不上人(現在前端這麼缺?)我被拉過去就火了三個月。
標題現在我有幾個疑問,前端的技術難點到底在什麼地方?
為了不引起不必要的爭論,我們假定前端指的是web前端業務開發的那部分前端,也就是狹義上的前端,之於什麼可視化、遊戲、前端工具框架設計這種是不算的,同樣,後端你也不能算上寫編譯器、大數據、人工智慧、資料庫這種，我們說的是後端Web業務開發。
邏輯部分: 除了『文字編輯器類別、Nwjs的客戶端應用』這些特殊應用,前端的邏輯複雜度基本上是遠遠不如後端的,後端需要處理大量的資料、服務,就比如雙十一的技術困難幾乎就是後端Web開發的技術困難。
性能優化:性能優化是軟體工程永恆的話題,可是前端的性能優化大頭基本上在網絡這個層面,除了已經過時的雅虎軍規,基本上離不開緩存、懶加載、組件or路由級別的代碼分割，還有一些節流、防抖、競態請求等比較難一點的,現在比較時髦的pwa和http2也是工具本身對前端的優化，我承認以上這些都做好也是很不容易的,但是這些難度比後端的優化如何?我認為相比於後端難度還是低很多的,因為在數據層面前端這層太薄了,比如很多時候後端用對一個數據結構性能就能大幅優化,因為數據多、請求頻繁，這是前端只要數組就能通吃，就算可能雙向鍊錶更適合,但是你用了效果幾乎為零(因為計算量不夠,體現不出來)，同樣後端的網絡層的優化一點不比前端少。
工程複雜度:還是以天貓、淘寶為例，這兩個部門的後端人數遠超前端，後端系統紛繁複雜，後端的工程量極大,還有面對雙十一的巨大壓力,我猜後端的程式碼量是前端十倍不止(雖然程式碼量不能直接衡量,但是至少能側面反映),我們知道工程的大小與工程複雜度息息相關。
所以,前端工程的難點到底在哪裡?為什麼前端這麼缺?即使很多人說前端關注用戶體驗,我也沒看出來,更多的也是關注編碼本身,可能比後端好那麼一點點而已。
業務邏輯很複雜而且多變
『前端的邏輯複雜度基本上不如後端』這個只是但從資料處理的角度來看的，前端對於資料處理的確是模板+ 變數一套一展示就好了，這個是挺簡單的。
前端邏輯複雜度主要在於資料+ UI + 互動的實現，就例如一個簡單的多tab 頁的功能，可以用CSS 實現、用JS 實現，JS 可以透過切換DOM 或添加隱藏，雖然效果上都可以實現， DOM 無法原有結構的狀態，新增的CSS 方式很難實現初始化狀態。除此之外還可能需要對瀏覽器進行相容性處理+ 響應式。然後突然來個業務需求說要加個嵌入別人的頁面，或者改什麼效果，如果之前開發的不合理，基本上要重做了。
相較於後端，只輸出資料模型給前端，如果業務不需要什麼欄位了，甚至讓前端不讀取好了，改都不用改。我們幾次大的業務平台重構，前端基本上要重新開發一次（效果、互動完全不同），後端模型和資料庫則可以遞進式的複用、擴充、升級。這也是導致前端需要堆人大力出奇蹟的問題。
垂直領域解決方案很難
切頁面是沒什麼難度的，但是在淘寶一到雙十一、雙十二大促根據經常多變的運營需求切幾百個頁面就很難了。這已經不是堆人堆外包可以解決的了，所以我們有TMS 等各種營運系統，前端切模組，經營自己設定圖片、文案、組裝成營運頁面，想改自己在後台改不用麻煩前端。這套系統是個比較龐大的工程，從模組規格、模組開發工具鏈、模組發布和版本管理、線上管理、線上視覺化搭建、資料填寫和資料來源匯入、頁面產生和CDN 同步等等，都需要前端架構師設計然後開發。設計這個系統是很難的。
再例如富文本內容發佈業務需求，光是一個富文本編輯器就很複雜，要實現各種功能和相容性，更複雜的是要適應業務發展。當時剛開始交接淘寶內容業務的時候，需要重新開發編輯器等，跟後端大神們進行討論推測未來業務可能會有大量表單而且需要完全的數據驅動，所以我們前端設計開發了動態表單技術產品然後後端有對應的SDK 進行解析和資料儲存、表單產生服務，前端只需要開發元件，然後後端依照業務需求進行設定即可產出內容發佈表單。
此外，富文本我們選用了JSON base 的存儲，對比HTML base 的編輯器，因為淘寶內容詳情頁充滿了各種商品、優惠券、店舖等信息，而且這些信息是需要被理解、識別而且在詳情頁輸出前即時補全最新價格、優惠券可用狀態、店舖名等資訊的。用傳統輸出HTML 的編輯器輸出，讓後端解析的話複雜度太高了，每一種素材你都需要設計、約束特定的HTML 標記讓後端解析。所以我們基於/draft-js 封裝了一套JSON base 的富文本編輯器，設計了完全資料驅動的插件機制，可以透過配置任意控制要提供的功能等。
雖然知乎的編輯器也是基於draft-js 開發的，但遇到的業務挑戰完全不同。它不需要功能動態變化，因為所有人都一樣。然後不知道是後端的資料處理邏輯的問題，它在提交和回填的時候是透過HTML 作為媒介進行傳播，將draft-js 的JSON 資料協定轉成HTML 提交給後端儲存。所以不同業務場景、特點，需要完全不同的前端解決方案，在開發這些垂直解決方案的時候，業務分析、技術選用、架構設計、開發落地是非常困難的。
之後內容發布又有了新的問題，傳統的富文本發佈器，本身可以認為輸出了一堆字符串，是一種非結構化信息，從中十分難解析數據，然而淘寶內容的展現形態有了新的要求，例如商品榜單這種內容類型（ ），希望創作者可以依序填寫排行榜順序、商品、介紹以顯示成下面效果：
這種內容結構性很強，JSON base 富文本編輯器基本上無法發出（HTML 的可以實現樣式，但是不好數據分析和更新看前面），就像排序下面的這個標題，富文本創作者要用什麼字串符號表示才可以讓後端解析出來它是標題標記為是特定的元素並讓詳情頁前端知道要這樣展示？所以我們在去年雙十一之前重新研發了新的發佈器，結構化發佈器：
仍然是附屬於動態表單，完全數據驅動的發佈器。左側可以新增模組，中間是預覽畫布，點擊模組可以在右邊填寫內容，之後會在中間畫布即時預覽。中間畫布模組可以配置是否可以拖曳排序、是否必須要有某幾個模組等。
實現這套垂直業務解決方案可是遇到了許多問題的：
預覽的模組為了確保效果和低開發成本，我們選擇跟詳情頁的無線模組保持一致
制定模組規範，接取淘寶無線模組開發工程，資料接取淘寶統一模組管理平台
後端介面基於模組資訊進行依賴分析計算輸出CDN combo 然後提升詳情頁效能
發佈器React、詳情頁模組用了Rax，我們基於另一套可視化拖曳系統的技術沉澱做了這個畫布，支援內部渲染其他技術框架程式碼，並支援拖曳等操作
屬性面板，為了保持無線開發習慣，我們使用描述左側表單，基於-/react--form 社群的過來，fork 過來改造支援我們特定元件（例如新增寶貝），然後設計了擴充機制
全鏈路的系統、功能串聯和聯調
模組開發鏈路到資料同步以及後端系統分工（多支團隊）
發佈器配置和輸出資料模型識別、校驗、儲存、底層流轉
特定業務需求
基礎校驗與必填
特殊校驗邏輯（例如：在店鋪發佈器中，所有寶貝模組的寶貝必須屬於被選擇的店鋪）
資料補全（例如：店鋪實際填寫，但需顯示店舖名等數據，需提供自訂資料取得邏輯）
模組自動排序，以及模組位置和順序（例如：榜單，必填六個，最多十個，只能用榜單模組）
這些都是要支援數據驅動配置出來
等等等等。
當時涉及許多人，光前端就多個團隊投入一共4個人（包括模組系統、視覺化拖曳等），後端也非常多。而且時間要求特別緊，雙十一需要用。我作為整個專案PM 簡直要累死，前期討論可能性並設計功能、分工，然後要一遍遍的跟不同的人解釋概念、流程，然後糅合在一起開發、處理新出現的問題。天天加班，每天一罐紅牛，終於在雙十一既定時間前糊弄出來一套可以用的了。這個我也覺得很難，已經超出了前端的範圍了，除了前端之外還要了解後端系統的限制對方案進行調整、專案管理等。
不過這套也有新的問題，例如互動操作多，體驗比不上HTML base 的新榜微信編輯器-讓你的圖文編輯生動有趣這種，然後模組擴展依賴開發，成本高，等等。這些新問題就像挖坑挖出來的，越挖越難越複雜。 。 。
總結下來我覺得前端比較難的幾個點：
前端本身業務邏輯、實現方式比較多元、複雜，技術選型、方案設計很難，這要求你對多種技術架構、工具都有一定的了解
面對不同業務需求進行抽象、設計、研發以及關聯繫統的自主研發（跨技術堆疊）比較難
將業務需求、互動設計、數據等糅合在一起開發出來展現給用戶，跟多方溝通打交道比較難，良好的溝通需要多種領域的知識
其實還有很多，上面只是我個人覺得比較難的。