本文內(nèi)容較長，大概需要15分鐘時間閱讀。

內(nèi)容包含五部分：前言，NodeJS職能變化，ReactNative的大規(guī)模應(yīng)用，專門的架構(gòu)組職能，總結(jié)。主要是介紹我所在團(tuán)隊最近的一些變化和思考。

更多信息可以加入我的小密圈關(guān)注團(tuán)隊每日動態(tài)：http://t.cn/Ri2cBT0

前言

最近，我所在的團(tuán)隊做了一些結(jié)構(gòu)調(diào)整，其實我一直想講講這次調(diào)整，希望能夠帶給同行一些思考，但因調(diào)整后很多事情還未走上正軌，一直拖延著，現(xiàn)在終于有時間把一些想法寫下來記錄成文字。

今天早晨，還看到一篇文章，講“大前端”，文中展望了近年來“前端”影響的領(lǐng)域，從美工時代刀耕火種的時代到現(xiàn)在延伸到 NodeJS ，ReactNative甚至桌面端，以及傳統(tǒng)前端的時代，聽來的確讓人非常興奮和自豪，但是作為一名理性的工程師，對于這種自High的論調(diào)一定要抱有謹(jǐn)慎的態(tài)度。

其實在技術(shù)選型上我是一個激進(jìn)卻又保守的人，所以，我同大家伙一樣，對于JS語言冒出來的給人無限想象的能力非常的敏銳和興奮，但是在落地到真正的業(yè)務(wù)中的時候卻要仔細(xì)權(quán)衡好它的真正的“價值”。此處的價值更多針對的是“對公司整體業(yè)務(wù)的價值”，而不是對團(tuán)隊或者個人的價值或是其他，所以，引入一個技術(shù)棧，絕非看起來那樣簡單，“新技術(shù)”可能會給你的團(tuán)隊或者業(yè)務(wù)帶來加持，但是更多時候，外界的人云亦云卻往往會夸大某個技術(shù)的價值，然后同時刻意避免談及這些技術(shù)帶來的問題，就是我們通常所說的“脫離場景討論技術(shù)”，而且通常帶來的問題比解決的問題還要多得多，這時候如果抱著“擴(kuò)大前端團(tuán)隊的話語權(quán)”或者“做一步看一步畢竟業(yè)界都在這樣玩”的態(tài)度，那就和“技術(shù)創(chuàng)造價值”的本意相違背了。

其實，大家會發(fā)現(xiàn)我所在的團(tuán)隊并不是一個保守的團(tuán)隊，從外面看，我們始終走在最前沿，但是從內(nèi)部看，其實我們一直在關(guān)注“技術(shù)創(chuàng)造價值”這件事情的本質(zhì)，所以我們給前端團(tuán)隊強(qiáng)化了很多職能，但是卻走了一些不同的道路，之所以會這樣，其實就是基于我們針對每個技術(shù)棧所做的思考，接下來我會舉幾個例子來講。

其實我今天本來想講的事情，并不只是“前端”，而是這次團(tuán)隊組織架構(gòu)調(diào)整后的“大無線”，為什么要從“大前端”到“大無線”，也是基于最大化價值輸出的考慮，這是后話。

這次調(diào)整，最大的三個動作就是， NodeJS 的職能變化/ReactNative的引入/專門的架構(gòu)組職能，然后包含其他一些小動作。

NodeJS 職能變化

對于 NodeJS ，我其實有挺多的話題想分享，關(guān)于前后端分離，關(guān)于服務(wù)端渲染，關(guān)于純服務(wù)端開發(fā)。很長一段時間內(nèi)，在我們團(tuán)隊， NodeJS 都是在做純服務(wù)端開發(fā)，然后我們的核心關(guān)注點一直是致力于將 NodeJS 在服務(wù)端開發(fā)的整個工程能力提升到和Java生態(tài)相當(dāng)甚至是超越，包括開發(fā)/部署/運維/服務(wù)化/線上保障 等。值得注意的一點是，當(dāng)我們的 NodeJS 運用非常成熟的時候，我們卻一直沒有做業(yè)界大家在玩的服務(wù)端渲染，或者前后端分離中間層，其實不是我們不了解或者沒有能力，而是我們一直在思考“為什么”，然后會”帶來什么問題？“。我覺得很多公司在做服務(wù)端渲染或者前后端分離的時候，可能都沒有非常全面的去思考過這個問題，是必須要做了而且?guī)淼膬r值遠(yuǎn)遠(yuǎn)超越了風(fēng)險？還是只是為了讓團(tuán)隊占領(lǐng)更大的勢力版圖？我們前幾天在討論這個問題的時候還提到，包括在某些大公司內(nèi)，做某些事情可能只是政治正確或者為了業(yè)績好看，如果你去問一個服務(wù)端開發(fā)，他對這些事情的看法是什么？難有好評？那這件事情可能就已經(jīng)走偏了，它可能關(guān)注了前端團(tuán)隊的自身價值，卻偏離了整個技術(shù)團(tuán)隊的價值體現(xiàn)。

當(dāng)然我不是表達(dá)不應(yīng)該去做某些事情，而只是講所有技術(shù)棧的落地都要基于場景去考量權(quán)衡。其實我們團(tuán)隊后來也做了業(yè)界意義上基于”服務(wù)端渲染"的”前后端分離“項目，在某個特殊業(yè)務(wù)中，我們衡量必須要做，與多方共同討論，最終實施落地的一個和諧方案。做這個項目的目的足夠單純，但是我們并沒有打算推廣這個方案，因為在我看來，他只是解決某個特定場景的一個解決方案，而不是一種必須推開來的“開發(fā)方式”。而且對于服務(wù)端渲染引入的風(fēng)險一定要做好風(fēng)險評估，包含但不限于：運維/線上保障能力（前端的弱項）；前后端開發(fā)的復(fù)雜度；性能問題（真正做過服務(wù)端的同學(xué)對內(nèi)存和cpu占用都會很敏感，但是目前一些方案看來在這方面的損耗還是太夸張）； NodeJS 本身的開發(fā)能力熟悉程度。其實有些問題是很嚴(yán)重的問題，只是在業(yè)界大家討論的時候，大家會刻意去弱化某些話題，而是強(qiáng)調(diào)其革新之處，或者是未來的趨勢，而這些理由，在真實場景落地的時候的作用微乎其微，別人一個質(zhì)疑就足以讓你的方案變成一個”糟糕的方案“。

不過，我所在的團(tuán)隊的 NodeJS ，最近其實在做”去服務(wù)端邏輯“化，也就是慢慢退出純服務(wù)端開發(fā)的領(lǐng)域，倒不是被倒逼，我覺得一個團(tuán)隊?wèi)?yīng)該做什么事情從來不是因為技術(shù)之間的斗爭導(dǎo)致的，而是前面提到的整體價值，在公司飛速發(fā)展的業(yè)務(wù)背景下， NodeJS 的開發(fā)生態(tài)和團(tuán)隊擴(kuò)張速度，都是瓶頸。 NodeJS 開發(fā)者的開發(fā)能力其實都很強(qiáng)，但是卻缺乏傳統(tǒng)軟件工程大規(guī)模開發(fā)的經(jīng)驗，這些經(jīng)驗可能大部分都不是和技術(shù)相關(guān)的，所以越在技術(shù)上走的深入，與大規(guī)模工程化關(guān)注的方向越發(fā)背離。所以，我基本上是主動要求團(tuán)隊退出服務(wù)端開發(fā)，將整個公司的服務(wù)端統(tǒng)一到 Java 技術(shù)棧上，統(tǒng)一由 Java 架構(gòu)組規(guī)劃技術(shù)發(fā)展，由 Java 業(yè)務(wù)組統(tǒng)一發(fā)展業(yè)務(wù)的工程化，這樣對公司的爆炸式增長會更有益處，隨后Java開發(fā)在一個月內(nèi)擴(kuò)招20人，而 NodeJS 一年時間里基本一直維持在5個人的水平（人數(shù)也是影響工程化的重要一環(huán)），想想這五位同學(xué)曾經(jīng)在一年之內(nèi)建設(shè)的諸多系統(tǒng)，雖然真的很牛逼，但是卻略顯小氣，沒有一個統(tǒng)一的規(guī)劃和價值體現(xiàn)。

那我們現(xiàn)在在做什么？

之前提到，我們現(xiàn)在整個團(tuán)隊成為“大無線”，其中包含兩個大團(tuán)隊，架構(gòu)和業(yè)務(wù)，而 NodeJS 正是架構(gòu)中的一員，對于 NodeJS 來說，它擅長的正是對社區(qū)和標(biāo)準(zhǔn)的追逐/開發(fā)效率/異步性能，而我們則發(fā)揮這些長處，在整個“大無線”的范圍內(nèi)解決相關(guān)的問題。例如正在做的一件事情，一個無線網(wǎng)關(guān)系統(tǒng)，具體網(wǎng)關(guān)系統(tǒng)是做什么事情的可能無法一句話描述清楚，核心兩點，1. 公司內(nèi)所有api請求的入口和規(guī)則分發(fā)，2. 在網(wǎng)關(guān)層做服務(wù)分級。具體實現(xiàn)其實并不是完全的 NodeJS 技術(shù)棧，其中多個子系統(tǒng)，包括Nginx開發(fā)網(wǎng)絡(luò)層/lua開發(fā)的獨立的心跳檢查/ NodeJS 開發(fā)的規(guī)則管理等，對于 NodeJS 來說是個不小的挑戰(zhàn)，對于整個無線端，甚至服務(wù)端，都有深遠(yuǎn)的意義，這種事情才是真正“有意義”的，后續(xù)我們也還有其他規(guī)劃，不過一切都需要一步一步調(diào)整，而對于我們 NodeJS 開發(fā)來說的調(diào)整，就是轉(zhuǎn)變思路，發(fā)揮長處，而不是一心想要去改變服務(wù)端開發(fā)的格局。

ReactNative的大規(guī)模應(yīng)用

我所在團(tuán)隊對于RN的技術(shù)積累其實從很早就開始了，大概接近1年前，但是一直處于調(diào)研的狀態(tài)，甚至組件庫都寫好了，基礎(chǔ)的集成SDK也寫好了，但是從來沒被應(yīng)用到業(yè)務(wù)中。為什么？不是因為不成熟，也不是因為hold不住，而是沒想明白，為什么一定要用RN？而不是H5或者Native？這其實是個很嚴(yán)肅的問題，你想不清楚一個技術(shù)的價值的時候，不要說是說服別人，連說服自己都很難，這樣的事情注定無法落地，所以我們就一直在調(diào)研，在準(zhǔn)備。就跟微信小程序一樣，我們調(diào)研了很久，自己做了個小程序上線，但是后來還是沒有做一個真正的業(yè)務(wù)相關(guān)的小程序，因為實在想不明白要做什么，為什么必須要用小程序？

后來，算是跟上了“大無線”整合的契機(jī)，也是公司業(yè)務(wù)飛速發(fā)展的契機(jī)。當(dāng)我們統(tǒng)一規(guī)劃一下公司內(nèi)所有的前端和無線端之后，發(fā)現(xiàn)數(shù)量竟然和所有服務(wù)端（包含架構(gòu)和數(shù)據(jù)等）的數(shù)量基本相當(dāng)，這很不正常，當(dāng)公司開始快速擴(kuò)張之后，這種比例是非常嚇人的，而核心問題就是我們公司無線端所有的開發(fā)工作量基本都是Native承擔(dān)的，這主要受制于公司業(yè)務(wù)類型限制，公司基本所有業(yè)務(wù)都是偏商家服務(wù)類型，重交互重操作重數(shù)據(jù)，在客戶端上開發(fā)，對H5來說的確難以滿足需求，不管是性能還是體驗還是開發(fā)成熟度上來說。所以除了公司的to C業(yè)務(wù)和PC端業(yè)務(wù)之外，大量投入客戶端開發(fā)，而因為之前客戶端分散在各個業(yè)務(wù)之間，每個業(yè)務(wù)的每個端都各自為政，在底層方案和組件SDK等問題上都缺乏一個統(tǒng)一的規(guī)劃。

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

開發(fā)人員輸出價值的人均效率，對于Native來說都需要至少乘以2，如果算上兩端之間的協(xié)調(diào)，將遠(yuǎn)遠(yuǎn)大于2這個最好預(yù)期。

難以統(tǒng)一規(guī)劃整個客戶端的統(tǒng)一發(fā)展，總是會受限于兩個完全不同的端各自不同的技術(shù)棧。

這時候，ReactNative站出來了，一個真正性能折中但是可以完美解決這兩個核心問題的技術(shù)方向，而且我們還是有技術(shù)積累的，至于我們?nèi)绾卧赗N和Weex之間做選型，其實不想多說，Weex的場景并不適合我們的業(yè)務(wù)類型，而且作為創(chuàng)業(yè)公司，我們只會選擇整個業(yè)界非常成熟的方案而不是一個還在發(fā)展期只是看起來很美好的方案。
對于ReactNative，核心價值點，其實就是上面說的這兩點，聽起來只是兩個問題總結(jié)，但是對于整個技術(shù)團(tuán)隊，甚至對于整個公司的業(yè)務(wù)發(fā)展，這都是非常核心的點，所以，我們毫不猶豫的執(zhí)行，短時間內(nèi)快速推進(jìn)了整個RN的解決方案以及落地。

針對RN，我們做了幾個事情：

完全改變RN的開發(fā)流程，自己定制的腳手架以及開發(fā)流程/調(diào)試流程/發(fā)布流程/版本更新規(guī)則。（我司最擅長的點）

自己實現(xiàn)的集成流程/熱更新方案，這里有一個核心點，我們制定了某個App依賴某個版本bundle的機(jī)制，RN代碼不是每次熱更新，然后RN代碼是直接內(nèi)置到工程里走發(fā)版，而不是線上訪問，因為我們的業(yè)務(wù)場景很特殊，業(yè)務(wù)耦合很強(qiáng)，所以制定了嚴(yán)格的版本依賴規(guī)則和維護(hù)方式，熱更新的能力只限于bugfix，不能用于發(fā)布新功能。

封裝過客戶端SDK，主要提供幾個能力：Bundle依賴管理/Native組件以及提供更多組件SDK無縫接入的能力/RN和Native和H5之間通過協(xié)議互相調(diào)用的能力/性能和錯誤崩潰監(jiān)測/其他底層優(yōu)化（例如秒開，bundle分拆復(fù)用等）。

最終面向具體業(yè)務(wù)開發(fā)的一部分：開發(fā)框架/開發(fā)規(guī)范/基于設(shè)計規(guī)范的組件庫/Native組件封裝/工具庫/文檔/模板項目/example項目列表 等，通過這些，我們給具體的業(yè)務(wù)開發(fā)暴露極少的概念，可以在短時間內(nèi)完成一個RN項目，并且將可能平臺差異的部分都做了深度封裝。

所以，可以看到，其實我們的RN開發(fā)有自己的一些特色：

大部分RN業(yè)務(wù)開發(fā)是客戶端開發(fā)，而前端仍然專注于前端的領(lǐng)域，所以我們的方案做了大量概念封裝，具體開發(fā)過程中大量使用的是自己封裝的概念而不是原生的概念，也把React生態(tài)，RN本身的生態(tài)的概念做了最大化的封裝，讓不熟悉React的同學(xué)也可以做基礎(chǔ)的開發(fā)。

強(qiáng)版本依賴，RN業(yè)務(wù)發(fā)布走發(fā)版而不是在線熱更新，RN和Native和H5之間深度耦合，一個流程中可以無縫在不同的容器間切換。然后RN和H5調(diào)用Native的能力其實也是一個統(tǒng)一的底層封裝。

這塊，不想在這里展開來講，畢竟這篇文章只是講方向，而不是具體實現(xiàn)。

專門的架構(gòu)組職能

到這里，才講到，為什么要整合“大無線”？基于前文的分析，無非是讓大家更關(guān)注大團(tuán)隊的價值輸出，而不是某個業(yè)務(wù)或者某個技術(shù)工種的價值輸出，前文多有體現(xiàn)其中的各種弊端。

如此的組織架構(gòu)，對于集中輸出價值的表意更為清楚：

各小組的價值，就體現(xiàn)在各自的職責(zé)定義上，其實這樣的組織架構(gòu)各自的職責(zé)定義非常清楚，業(yè)務(wù)方負(fù)責(zé)將業(yè)務(wù)實現(xiàn)和落地，其價值體現(xiàn)在更高效的落地業(yè)務(wù)，而架構(gòu)組則負(fù)責(zé)統(tǒng)一規(guī)劃技術(shù)方向，提供基礎(chǔ)設(shè)施，推進(jìn)技術(shù)演化，來解決業(yè)務(wù)落地過程中的技術(shù)問題。

二者協(xié)作，價值最終還是集中于一個點上：業(yè)務(wù)價值。對于無線來說是無線端對業(yè)務(wù)的價值，而后端則是后端對業(yè)務(wù)的價值。二者其實略有不同，無線端更關(guān)注表現(xiàn)和體驗，后端則更關(guān)注邏輯和服務(wù)。

最終大家的價值其實都集中在公司層面，當(dāng)然能不能考慮到這一層，能不能推動這一層，就是各大Leader的能力問題了。

在抽取出統(tǒng)一的無線端架構(gòu)組之后，至少以下幾件事情可以體現(xiàn)出深刻的價值來：

專門的跨端體驗組，提供RN的整套解決方案和各種優(yōu)化以及推進(jìn)等，統(tǒng)一規(guī)劃RN的發(fā)展方向，效率提升，流程規(guī)范等，而業(yè)務(wù)方則致力于快速實施推進(jìn)業(yè)務(wù)開發(fā)的效率。

專門的客戶端和前端架構(gòu)組，統(tǒng)一規(guī)范“開發(fā)方式”，所謂的工程化體系，提供各種效率工具（例如我們內(nèi)部的mock系統(tǒng)，已經(jīng)和服務(wù)端自動化集成在一起，非常高效），提供基礎(chǔ)組件，基礎(chǔ)服務(wù)（例如前端的靜態(tài)資源管理等服務(wù)）基礎(chǔ)腳手架，提供一些底層manger的統(tǒng)一實現(xiàn)等。

專門的 NodeJS 中間件團(tuán)隊，提供一切與無線端的后端服務(wù)能力，例如網(wǎng)關(guān)服務(wù)，服務(wù)端渲染服務(wù)，RN模塊管理服務(wù)，靜態(tài)托管服務(wù)，消息服務(wù)等，其中有些服務(wù)挑戰(zhàn)非常大（網(wǎng)關(guān)/消息等），后續(xù)，還準(zhǔn)備做另外一個中間件的嘗試，不過還是要按照上面講的方法論進(jìn)行評估。

雖然，整個無線端包含了這么多角色，但是我深感欣慰的是，我們在各自領(lǐng)域都有了一定的基礎(chǔ)積累，所以在這樣大整合的趨勢下，能夠良好運轉(zhuǎn)，并快速發(fā)揮各自優(yōu)勢為整個團(tuán)隊的發(fā)展出一份力。如果我們是從開始按照這樣的職責(zé)孵化，其實我覺得很難走到今天這一步，所以，這是一個趨勢，但是不是一種與生俱來的合理結(jié)構(gòu)。

另外，在架構(gòu)組職責(zé)上，還有一點很重要就是，架構(gòu)這個角色絕對不止是“研究新技術(shù)/熟悉底層/產(chǎn)出復(fù)雜技術(shù)方案”的角色，更多時候，架構(gòu)師需要深入到業(yè)務(wù)中去發(fā)現(xiàn)問題，然后分析問題總結(jié)問題，思考解決方案，與其他成員腦暴，制定最終解決方案，并將其最終落地的過程。所以我們有一套自己的架構(gòu)流程，大抵是這個過程：

提出問題 -> 調(diào)研 -> 初步方案 -> 討論 -> 完整方案 -> 架構(gòu)組分析圖 -> 業(yè)務(wù)方評審 -> 制定計劃然后實現(xiàn) -> 推進(jìn)落地。

你會發(fā)現(xiàn)其中寫代碼的時間可能不到20%，如果你每天不是在思考或者溝通而是一直在寫代碼，那你肯定是個假架構(gòu)師。

##其他

說了這么說，總結(jié)下我的核心觀點：

不要一味追隨潮流，基于場景討論問題。

關(guān)注技術(shù)的核心價值，不要為了用而用。

不要因為自己是前端而妄自菲薄，每個領(lǐng)域都要深扎下去。

最終，無線和前端領(lǐng)域這么多概念，個人其實很難完全掌控，但是團(tuán)隊一定要有能力掌控，不同的人，對不同的技術(shù)棧，做好技術(shù)積累和預(yù)研，厚積薄發(fā)，這樣的團(tuán)隊在合適的機(jī)會才能更好的發(fā)揮整體價值。

更多信息歡迎關(guān)注團(tuán)隊博客： http://f2e.souche.com/blog

也可以加入我的小密圈關(guān)注團(tuán)隊每日動態(tài)《全棧團(tuán)隊成長記錄》：http://t.cn/Ri2cBT0

轉(zhuǎn)載請不要刪減并注明出處：https://zhuanlan.zhihu.com/p/25567060

---

本文對你有幫助？歡迎掃碼加入前端學(xué)習(xí)小組微信群：

更多專業(yè)前端知識，請上 【猿2048】www.mk2048.com

總結(jié)

以上是生活随笔為你收集整理的我理解中的“大前端”/“大无线”的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。