本文主要是介紹作者所在團隊最近的一些變化和思考枚驻，包括前言濒旦、NodeJS職能變化、ReactNative的大規(guī)模應用测秸、專門的架構組職能疤估、總結五部分灾常。

前 ? 言

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

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

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

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

其實我今天本來想講的事情包吝，并不只是“前端”饼煞，而是這次團隊組織架構調整后的“大無線”，為什么要從“大前端”到“大無線”诗越，也是基于最大化價值輸出的考慮砖瞧，這是后話。

這次調整嚷狞，最大的三個動作就是芭届， NodeJS 的職能變化/ReactNative的引入/專門的架構組職能，然后包含其他一些小動作感耙。

NodeJS 職能變化

對于 NodeJS 褂乍，我其實有挺多的話題想分享，關于前后端分離即硼，關于服務端渲染逃片，關于純服務端開發(fā)。很長一段時間內只酥，在我們團隊褥实， NodeJS 都是在做純服務端開發(fā)，然后我們的核心關注點一直是致力于將 NodeJS 在服務端開發(fā)的整個工程能力提升到和Java生態(tài)相當甚至是超越裂允，包括開發(fā)/部署/運維/服務化/線上保障 等损离。值得注意的一點是，當我們的 NodeJS 運用非常成熟的時候绝编，我們卻一直沒有做業(yè)界大家在玩的服務端渲染僻澎，或者前后端分離中間層，其實不是我們不了解或者沒有能力十饥，而是我們一直在思考“為什么”窟勃，然后會”帶來什么問題？“逗堵。我覺得很多公司在做服務端渲染或者前后端分離的時候秉氧，可能都沒有非常全面的去思考過這個問題，是必須要做了而且?guī)淼膬r值遠遠超越了風險蜒秤？還是只是為了讓團隊占領更大的勢力版圖汁咏？我們前幾天在討論這個問題的時候還提到亚斋，包括在某些大公司內，做某些事情可能只是政治正確或者為了業(yè)績好看攘滩，如果你去問一個服務端開發(fā)帅刊，他對這些事情的看法是什么？難有好評轰驳？那這件事情可能就已經走偏了厚掷，它可能關注了前端團隊的自身價值，卻偏離了整個技術團隊的價值體現(xiàn)级解。

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

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

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

之前提到矮冬，我們現(xiàn)在整個團隊成為“大無線”，其中包含兩個大團隊次哈，架構和業(yè)務胎署，而 NodeJS 正是架構中的一員，對于 NodeJS 來說窑滞，它擅長的正是對社區(qū)和標準的追逐/開發(fā)效率/異步性能琼牧，而我們則發(fā)揮這些長處，在整個“大無線”的范圍內解決相關的問題哀卫。例如正在做的一件事情巨坊，一個無線網關系統(tǒng)，具體網關系統(tǒng)是做什么事情的可能無法一句話描述清楚此改，核心兩點趾撵，1. 公司內所有api請求的入口和規(guī)則分發(fā)，2. 在網關層做服務分級。具體實現(xiàn)其實并不是完全的 NodeJS 技術棧占调，其中多個子系統(tǒng)暂题，包括Nginx開發(fā)網絡層/lua開發(fā)的獨立的心跳檢查/ NodeJS 開發(fā)的規(guī)則管理等，對于 NodeJS 來說是個不小的挑戰(zhàn)究珊，對于整個無線端薪者，甚至服務端，都有深遠的意義剿涮，這種事情才是真正“有意義”的言津，后續(xù)我們也還有其他規(guī)劃，不過一切都需要一步一步調整取试，而對于我們 NodeJS 開發(fā)來說的調整悬槽，就是轉變思路，發(fā)揮長處想括，而不是一心想要去改變服務端開發(fā)的格局陷谱。

ReactNative的大規(guī)模應用

我所在團隊對于RN的技術積累其實從很早就開始了，大概接近一年前瑟蜈，但是一直處于調研的狀態(tài)烟逊，甚至組件庫都寫好了，基礎的集成SDK也寫好了铺根，但是從來沒被應用到業(yè)務中宪躯。為什么？不是因為不成熟位迂，也不是因為hold不住访雪，而是沒想明白，為什么一定要用RN掂林？而不是H5或者Native臣缀？這其實是個很嚴肅的問題，你想不清楚一個技術的價值的時候泻帮，不要說是說服別人精置，連說服自己都很難，這樣的事情注定無法落地锣杂，所以我們就一直在調研脂倦，在準備。就跟微信小程序一樣元莫，我們調研了很久赖阻，自己做了個小程序上線，但是后來還是沒有做一個真正的業(yè)務相關的小程序踱蠢，因為實在想不明白要做什么火欧，為什么必須要用小程序？

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

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

開發(fā)人員輸出價值的人均效率饥悴，對于Native來說都需要至少乘以2坦喘，如果算上兩端之間的協(xié)調，將遠遠大于2這個最好預期西设。

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

這時候贷揽，ReactNative站出來了棠笑，一個真正性能折中但是可以完美解決這兩個核心問題的技術方向，而且我們還是有技術積累的擒滑，至于我們如何在RN和Weex之間做選型腐晾，其實不想多說，Weex的場景并不適合我們的業(yè)務類型丐一，而且作為創(chuàng)業(yè)公司镐捧，我們只會選擇整個業(yè)界非常成熟的方案而不是一個還在發(fā)展期只是看起來很美好的方案。 對于ReactNative购啄，核心價值點缰贝，其實就是上面說的這兩點，聽起來只是兩個問題總結，但是對于整個技術團隊洋满，甚至對于整個公司的業(yè)務發(fā)展晶乔，這都是非常核心的點，所以牺勾，我們毫不猶豫的執(zhí)行正罢，短時間內快速推進了整個RN的解決方案以及落地。

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

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

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

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

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

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

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

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

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

專門的架構組職能

到這里丙曙，才講到爸业，為什么要整合“大無線”？基于前文的分析亏镰，無非是讓大家更關注大團隊的價值輸出，而不是某個業(yè)務或者某個技術工種的價值輸出拯爽，前文多有體現(xiàn)其中的各種弊端索抓。

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

各小組的價值毯炮，就體現(xiàn)在各自的職責定義上逼肯，其實這樣的組織架構各自的職責定義非常清楚，業(yè)務方負責將業(yè)務實現(xiàn)和落地桃煎，其價值體現(xiàn)在更高效的落地業(yè)務篮幢，而架構組則負責統(tǒng)一規(guī)劃技術方向，提供基礎設施为迈，推進技術演化三椿，來解決業(yè)務落地過程中的技術問題。

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

最終大家的價值其實都集中在公司層面狈涮，當然能不能考慮到這一層，能不能推動這一層鸭栖，就是各大Leader的能力問題了歌馍。

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

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

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

專門的 NodeJS 中間件團隊，提供一切與無線端的后端服務能力匣吊，例如網關服務儒拂，服務端渲染服務，RN模塊管理服務色鸳，靜態(tài)托管服務社痛，消息服務等，其中有些服務挑戰(zhàn)非常大（網關/消息等）命雀，后續(xù)蒜哀，還準備做另外一個中間件的嘗試，不過還是要按照上面講的方法論進行評估吏砂。

雖然撵儿，整個無線端包含了這么多角色，但是我深感欣慰的是赊抖，我們在各自領域都有了一定的基礎積累统倒，所以在這樣大整合的趨勢下，能夠良好運轉氛雪，并快速發(fā)揮各自優(yōu)勢為整個團隊的發(fā)展出一份力房匆。如果我們是從開始按照這樣的職責孵化，其實我覺得很難走到今天這一步报亩，所以浴鸿，這是一個趨勢，但是不是一種與生俱來的合理結構弦追。

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

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

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

其 ?他

說了這么說投剥，總結下我的核心觀點：

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

關注技術的核心價值薇缅，不要為了用而用。

不要因為自己是前端而妄自菲薄攒磨，每個領域都要深扎下去。

最終汤徽，無線和前端領域這么多概念娩缰，個人其實很難完全掌控，但是團隊一定要有能力掌控谒府，不同的人拼坎，對不同的技術棧，做好技術積累和預研完疫，厚積薄發(fā)泰鸡，這樣的團隊在合適的機會才能更好的發(fā)揮整體價值。

京程一燈壳鹤，夢起的地方盛龄，我們始終相信通過努力，可以改變自己的命運芳誓。

我們始終相信余舶，通過堅持不懈，可以為大家解決更多的前端技術問題锹淌。

我們始終相信匿值，時間可以證明，我們可以為廣大IT從業(yè)者解決前端學習路線赂摆。

HTML5挟憔，CSS3钟些，Web前端，jquery绊谭，javascript政恍，前端學習路線，各類問題龙誊，我們都可以為你解決抚垃。

更多技術好文，前端問題趟大，面試技巧鹤树，請關注京程一燈（原一燈學堂）