我理解中的「大前端」/「大無線」

本文內容較長，大概須要15分鐘時間閱讀。

內容包含五部分：前言，NodeJS職能變化，ReactNative的大規模應用，專門的架構組職能，總結。主要是介紹我所在團隊最近的一些變化和思考。

更多信息能夠加入個人小密圈關注團隊每日動態：t.cn/Ri2cBT0

前言

最近，我所在的團隊作了一些結構調整，其實我一直想講講此次調整，但願可以帶給同行一些思考，但因調整後不少事情還未走上正軌，一直拖延着，如今終於有時間把一些想法寫下來記錄成文字。

今天早晨，還看到一篇文章，講「大前端」，文中展望了近年來「前端」影響的領域，從美工時代刀耕火種的時代到如今延伸到 NodeJS ，ReactNative甚至桌面端，以及傳統前端的時代，聽來的確讓人很是興奮和自豪，可是做爲一名理性的工程師，對於這種自High的論調必定要抱有謹慎的態度。

其實在技術選型上我是一個激進卻又保守的人，因此，我同你們夥同樣，對於JS語言冒出來的給人無限想象的能力很是的敏銳和興奮，可是在落地到真正的業務中的時候卻要仔細權衡好它的真正的「價值」。此處的價值更多針對的是「對公司總體業務的價值」，而不是對團隊或者我的的價值或是其餘，因此，引入一個技術棧，絕非看起來那樣簡單，「新技術」可能會給你的團隊或者業務帶來加持，可是更多時候，外界的人云亦云卻每每會誇大某個技術的價值，而後同時刻意避免談及這些技術帶來的問題，就是咱們一般所說的「脫離場景討論技術」，並且一般帶來的問題比解決的問題還要多得多，這時候若是抱着「擴大前端團隊的話語權」或者「作一步看一步畢竟業界都在這樣玩」的態度，那就和「技術創造價值」的本意相違背了。

其實，你們會發現我所在的團隊並非一個保守的團隊，從外面看，咱們始終走在最前沿，可是從內部看，其實咱們一直在關注「技術創造價值」這件事情的本質，因此咱們給前端團隊強化了不少職能，可是卻走了一些不一樣的道路，之因此會這樣，其實就是基於咱們針對每一個技術棧所作的思考，接下來我會舉幾個例子來說。

其實我今天原本想講的事情，並不僅是「前端」，而是此次團隊組織架構調整後的「大無線」，爲何要從「大前端」到「大無線」，也是基於最大化價值輸出的考慮，這是後話。

此次調整，最大的三個動做就是， NodeJS 的職能變化/ReactNative的引入/專門的架構組職能，而後包含其餘一些小動做。

NodeJS 職能變化

對於 NodeJS ，我其實有挺多的話題想分享，關於先後端分離，關於服務端渲染，關於純服務端開發。很長一段時間內，在咱們團隊， NodeJS 都是在作純服務端開發，而後咱們的核心關注點一直是致力於將 NodeJS 在服務端開發的整個工程能力提高到和Java生態至關甚至是超越，包括開發/部署/運維/服務化/線上保障 等。值得注意的一點是，當咱們的 NodeJS 運用很是成熟的時候，咱們卻一直沒有作業界你們在玩的服務端渲染，或者先後端分離中間層，其實不是咱們不瞭解或者沒有能力，而是咱們一直在思考「爲何」，而後會」帶來什麼問題？「。我以爲不少公司在作服務端渲染或者先後端分離的時候，可能都沒有很是全面的去思考過這個問題，是必需要作了並且帶來的價值遠遠超越了風險？仍是隻是爲了讓團隊佔領更大的勢力版圖？咱們前幾天在討論這個問題的時候還提到，包括在某些大公司內，作某些事情可能只是政治正確或者爲了業績好看，若是你去問一個服務端開發，他對這些事情的見解是什麼？難有好評？那這件事情可能就已經走偏了，它可能關注了前端團隊的自身價值，卻偏離了整個技術團隊的價值體現。

固然我不是表達不該該去作某些事情，而只是講全部技術棧的落地都要基於場景去考量權衡。其實咱們團隊後來也作了業界意義上基於」服務端渲染"的」先後端分離「項目，在某個特殊業務中，咱們衡量必需要作，與多方共同討論，最終實施落地的一個和諧方案。作這個項目的目的足夠單純，可是咱們並無打算推廣這個方案，由於在我看來，他只是解決某個特定場景的一個解決方案，而不是一種必須推開來的「開發方式」。並且對於服務端渲染引入的風險必定要作好風險評估，包含但不限於：運維/線上保障能力（前端的弱項）；先後端開發的複雜度；性能問題（真正作過服務端的同窗對內存和cpu佔用都會很敏感，可是目前一些方案看來在這方面的損耗仍是太誇張）； NodeJS 自己的開發能力熟悉程度。其實有些問題是很嚴重的問題，只是在業界你們討論的時候，你們會刻意去弱化某些話題，而是強調其革新之處，或者是將來的趨勢，而這些理由，在真實場景落地的時候的做用微乎其微，別人一個質疑就足以讓你的方案變成一個」糟糕的方案「。

不過，我所在的團隊的 NodeJS ，最近其實在作」去服務端邏輯「化，也就是慢慢退出純服務端開發的領域，倒不是被倒逼，我以爲一個團隊應該作什麼事情歷來不是由於技術之間的鬥爭致使的，而是前面提到的總體價值，在公司飛速發展的業務背景下， NodeJS 的開發生態和團隊擴張速度，都是瓶頸。 NodeJS 開發者的開發能力其實都很強，可是卻缺少傳統軟件工程大規模開發的經驗，這些經驗可能大部分都不是和技術相關的，因此越在技術上走的深刻，與大規模工程化關注的方向愈加背離。因此，我基本上是主動要求團隊退出服務端開發，將整個公司的服務端統一到 Java 技術棧上，統一由 Java 架構組規劃技術發展，由 Java 業務組統一發展業務的工程化，這樣對公司的爆炸式增加會更有益處，隨後Java開發在一個月內擴招20人，而 NodeJS 一年時間裏基本一直維持在5我的的水平（人數也是影響工程化的重要一環），想一想這五位同窗曾經在一年以內建設的諸多系統，雖然真的很牛逼，可是卻略顯小氣，沒有一個統一的規劃和價值體現。

那咱們如今在作什麼？

以前提到，咱們如今整個團隊成爲「大無線」，其中包含兩個大團隊，架構和業務，而 NodeJS 正是架構中的一員，對於 NodeJS 來講，它擅長的正是對社區和標準的追逐/開發效率/異步性能，而咱們則發揮這些長處，在整個「大無線」的範圍內解決相關的問題。例如正在作的一件事情，一個無線網關係統，具體網關係統是作什麼事情的可能沒法一句話描述清楚，核心兩點，1. 公司內全部api請求的入口和規則分發，2. 在網關層作服務分級。具體實現其實並非徹底的 NodeJS 技術棧，其中多個子系統，包括Nginx開發網絡層/lua開發的獨立的心跳檢查/ NodeJS 開發的規則管理等，對於 NodeJS 來講是個不小的挑戰，對於整個無線端，甚至服務端，都有深遠的意義，這種事情纔是真正「有意義」的，後續咱們也還有其餘規劃，不過一切都須要一步一步調整，而對於咱們 NodeJS 開發來講的調整，就是轉變思路，發揮長處，而不是一心想要去改變服務端開發的格局。

ReactNative的大規模應用

我所在團隊對於RN的技術積累其實從很早就開始了，大概接近1年前，可是一直處於調研的狀態，甚至組件庫都寫好了，基礎的集成SDK也寫好了，可是歷來沒被應用到業務中。爲何？不是由於不成熟，也不是由於hold不住，而是沒想明白，爲何必定要用RN？而不是H5或者Native？這實際上是個很嚴肅的問題，你想不清楚一個技術的價值的時候，不要說是說服別人，連說服本身都很難，這樣的事情註定沒法落地，因此咱們就一直在調研，在準備。就跟微信小程序同樣，咱們調研了好久，本身作了個小程序上線，可是後來仍是沒有作一個真正的業務相關的小程序，由於實在想不明白要作什麼，爲何必需要用小程序？

後來，算是跟上了「大無線」整合的契機，也是公司業務飛速發展的契機。當咱們統一規劃一下公司內全部的前端和無線端以後，發現數量居然和全部服務端（包含架構和數據等）的數量基本至關，這很不正常，當公司開始快速擴張以後，這種比例是很是嚇人的，而核心問題就是咱們公司無線端全部的開發工做量基本都是Native承擔的，這主要受制於公司業務類型限制，公司基本全部業務都是偏商家服務類型，重交互重操做重數據，在客戶端上開發，對H5來講的確難以知足需求，無論是性能仍是體驗仍是開發成熟度上來講。因此除了公司的to C業務和PC端業務以外，大量投入客戶端開發，而由於以前客戶端分散在各個業務之間，每一個業務的每一個端都各自爲政，在底層方案和組件SDK等問題上都缺少一個統一的規劃。

注意！這裏提到兩個核心問題：

1. 開發人員輸出價值的人均效率，對於Native來講都須要至少乘以2，若是算上兩端之間的協調，將遠遠大於2這個最好預期。
2. 難以統一規劃整個客戶端的統一發展，老是會受限於兩個徹底不一樣的端各自不一樣的技術棧。

這時候，ReactNative站出來了，一個真正性能折中可是能夠完美解決這兩個核心問題的技術方向，並且咱們仍是有技術積累的，至於咱們如何在RN和Weex之間作選型，其實不想多說，Weex的場景並不適合咱們的業務類型，並且做爲創業公司，咱們只會選擇整個業界很是成熟的方案而不是一個還在發展期只是看起來很美好的方案。
對於ReactNative，核心價值點，其實就是上面說的這兩點，聽起來只是兩個問題總結，可是對於整個技術團隊，甚至對於整個公司的業務發展，這都是很是核心的點，因此，咱們絕不猶豫的執行，短期內快速推動了整個RN的解決方案以及落地。

針對RN，咱們作了幾個事情：

1. 徹底改變RN的開發流程，本身定製的腳手架以及開發流程/調試流程/發佈流程/版本更新規則。（我司最擅長的點）
2. 本身實現的集成流程/熱更新方案，這裏有一個核心點，咱們制定了某個App依賴某個版本bundle的機制，RN代碼不是每次熱更新，而後RN代碼是直接內置到工程裏走發版，而不是線上訪問，由於咱們的業務場景很特殊，業務耦合很強，因此制定了嚴格的版本依賴規則和維護方式，熱更新的能力只限於bugfix，不能用於發佈新功能。
3. 封裝過客戶端SDK，主要提供幾個能力：Bundle依賴管理/Native組件以及提供更多組件SDK無縫接入的能力/RN和Native和H5之間經過協議互相調用的能力/性能和錯誤崩潰監測/其餘底層優化（例如秒開，bundle分拆複用等）。
4. 最終面向具體業務開發的一部分：開發框架/開發規範/基於設計規範的組件庫/Native組件封裝/工具庫/文檔/模板項目/example項目列表 等，經過這些，咱們給具體的業務開發暴露極少的概念，能夠在短期內完成一個RN項目，而且將可能平臺差別的部分都作了深度封裝。

因此，能夠看到，其實咱們的RN開發有本身的一些特點：

1. 大部分RN業務開發是客戶端開發，而前端仍然專一於前端的領域，因此咱們的方案作了大量概念封裝，具體開發過程當中大量使用的是本身封裝的概念而不是原生的概念，也把React生態，RN自己的生態的概念作了最大化的封裝，讓不熟悉React的同窗也能夠作基礎的開發。
2. 強版本依賴，RN業務發佈走發版而不是在線熱更新，RN和Native和H5之間深度耦合，一個流程中能夠無縫在不一樣的容器間切換。而後RN和H5調用Native的能力其實也是一個統一的底層封裝。

這塊，不想在這裏展開來說，畢竟這篇文章只是講方向，而不是具體實現。

專門的架構組職能

到這裏，纔講到，爲何要整合「大無線」？基於前文的分析，無非是讓你們更關注大團隊的價值輸出，而不是某個業務或者某個技術工種的價值輸出，前文多有體現其中的各類弊端。

如此的組織架構，對於集中輸出價值的表意更爲清楚：

1. 各小組的價值，就體如今各自的職責定義上，其實這樣的組織架構各自的職責定義很是清楚，業務方負責將業務實現和落地，其價值體如今更高效的落地業務，而架構組則負責統一規劃技術方向，提供基礎設施，推動技術演化，來解決業務落地過程當中的技術問題。
2. 兩者協做，價值最終仍是集中於一個點上：業務價值。對於無線來講是無線端對業務的價值，然後端則是後端對業務的價值。兩者其實略有不一樣，無線端更關注表現和體驗，後端則更關注邏輯和服務。
3. 最終你們的價值其實都集中在公司層面，固然能不能考慮到這一層，能不能推進這一層，就是各大Leader的能力問題了。

在抽取出統一的無線端架構組以後，至少如下幾件事情能夠體現出深入的價值來：

1. 專門的跨端體驗組，提供RN的整套解決方案和各類優化以及推動等，統一規劃RN的發展方向，效率提高，流程規範等，而業務方則致力於快速實施推動業務開發的效率。
2. 專門的客戶端和前端架構組，統一規範「開發方式」，所謂的工程化體系，提供各類效率工具（例如咱們內部的mock系統，已經和服務端自動化集成在一塊兒，很是高效），提供基礎組件，基礎服務（例如前端的靜態資源管理等服務）基礎腳手架，提供一些底層manger的統一實現等。
3. 專門的 NodeJS 中間件團隊，提供一切與無線端的後端服務能力，例如網關服務，服務端渲染服務，RN模塊管理服務，靜態託管服務，消息服務等，其中有些服務挑戰很是大（網關/消息等），後續，還準備作另一箇中間件的嘗試，不過仍是要按照上面講的方法論進行評估。

雖然，整個無線端包含了這麼多角色，可是我深感欣慰的是，咱們在各自領域都有了必定的基礎積累，因此在這樣大整合的趨勢下，可以良好運轉，並快速發揮各自優點爲整個團隊的發展出一份力。若是咱們是從開始按照這樣的職責孵化，其實我以爲很難走到今天這一步，因此，這是一個趨勢，可是不是一種與生俱來的合理結構。

另外，在架構組職責上，還有一點很重要就是，架構這個角色絕對不止是「研究新技術/熟悉底層/產出複雜技術方案」的角色，更多時候，架構師須要深刻到業務中去發現問題，而後分析問題總結問題，思考解決方案，與其餘成員腦暴，制定最終解決方案，並將其最終落地的過程。因此咱們有一套本身的架構流程，大抵是這個過程：

提出問題 -> 調研 -> 初步方案 -> 討論 -> 完整方案 -> 架構組分析圖 -> 業務方評審 -> 制定計劃而後實現 -> 推動落地。

你會發現其中寫代碼的時間可能不到20%，若是你天天不是在思考或者溝通而是一直在寫代碼，那你確定是個假架構師。

##其餘

說了這麼說，總結下個人核心觀點：

1. 不要一味追隨潮流，基於場景討論問題。
2. 關注技術的核心價值，不要爲了用而用。
3. 不要由於本身是前端而妄自菲薄，每一個領域都要深紮下去。

最終，無線和前端領域這麼多概念，我的其實很難徹底掌控，可是團隊必定要有能力掌控，不一樣的人，對不一樣的技術棧，作好技術積累和預研，厚積薄發，這樣的團隊在合適的機會才能更好的發揮總體價值。

更多信息歡迎關注團隊博客： f2e.souche.com/blog

也能夠加入個人小密圈關注團隊每日動態《全棧團隊成長記錄》：t.cn/Ri2cBT0

轉載請不要刪減並註明出處：zhuanlan.zhihu.com/p/25567060

---

本文對你有幫助？歡迎掃碼加入前端學習小組微信羣：