本文內容較長，大概需要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等問題上都缺乏一個統一的規劃。
注意！這裡提到兩個核心問題：
- 開發人員輸出價值的人均效率，對於Native來說都需要至少乘以2，如果算上兩端之間的協調，將遠遠大於2這個最好預期。
- 難以統一規劃整個客戶端的統一發展，總是會受限於兩個完全不同的端各自不同的技術棧。
這時候，ReactNative站出來了，一個真正效能折中但是可以完美解決這兩個核心問題的技術方向，而且我們還是有技術積累的，至於我們如何在RN和Weex之間做選型，其實不想多說，Weex的場景並不適合我們的業務型別，而且作為創業公司，我們只會選擇整個業界非常成熟的方案而不是一個還在發展期只是看起來很美好的方案。
對於ReactNative，核心價值點，其實就是上面說的這兩點，聽起來只是兩個問題總結，但是對於整個技術團隊，甚至對於整個公司的業務發展，這都是非常核心的點，所以，我們毫不猶豫的執行，短時間內快速推進了整個RN的解決方案以及落地。
針對RN，我們做了幾個事情：
- 完全改變RN的開發流程，自己定製的腳手架以及開發流程/除錯流程/釋出流程/版本更新規則。（我司最擅長的點）
- 自己實現的整合流程/熱更新方案，這裡有一個核心點，我們制定了某個App依賴某個版本bundle的機制，RN程式碼不是每次熱更新，然後RN程式碼是直接內建到工程裡走發版，而不是線上訪問，因為我們的業務場景很特殊，業務耦合很強，所以制定了嚴格的版本依賴規則和維護方式，熱更新的能力只限於bugfix，不能用於釋出新功能。
- 封裝過客戶端SDK，主要提供幾個能力：Bundle依賴管理/Native元件以及提供更多元件SDK無縫接入的能力/RN和Native和H5之間通過協議互相呼叫的能力/效能和錯誤崩潰監測/其他底層優化（例如秒開，bundle分拆複用等）。
- 最終面向具體業務開發的一部分：開發框架/開發規範/基於設計規範的元件庫/Native元件封裝/工具庫/文件/模板專案/example專案列表 等，通過這些，我們給具體的業務開發暴露極少的概念，可以在短時間內完成一個RN專案，並且將可能平臺差異的部分都做了深度封裝。
所以，可以看到，其實我們的RN開發有自己的一些特色：
- 大部分RN業務開發是客戶端開發，而前端仍然專注於前端的領域，所以我們的方案做了大量概念封裝，具體開發過程中大量使用的是自己封裝的概念而不是原生的概念，也把React生態，RN本身的生態的概念做了最大化的封裝，讓不熟悉React的同學也可以做基礎的開發。
- 強版本依賴，RN業務釋出走發版而不是線上熱更新，RN和Native和H5之間深度耦合，一個流程中可以無縫在不同的容器間切換。然後RN和H5呼叫Native的能力其實也是一個統一的底層封裝。
這塊，不想在這裡展開來講，畢竟這篇文章只是講方向，而不是具體實現。
專門的架構組職能
到這裡，才講到，為什麼要整合“大無線”？基於前文的分析，無非是讓大家更關注大團隊的價值輸出，而不是某個業務或者某個技術工種的價值輸出，前文多有體現其中的各種弊端。
如此的組織架構，對於集中輸出價值的表意更為清楚：
- 各小組的價值，就體現在各自的職責定義上，其實這樣的組織架構各自的職責定義非常清楚，業務方負責將業務實現和落地，其價值體現在更高效的落地業務，而架構組則負責統一規劃技術方向，提供基礎設施，推進技術演化，來解決業務落地過程中的技術問題。
- 二者協作，價值最終還是集中於一個點上：業務價值。對於無線來說是無線端對業務的價值，而後端則是後端對業務的價值。二者其實略有不同，無線端更關注表現和體驗，後端則更關注邏輯和服務。
- 最終大家的價值其實都集中在公司層面，當然能不能考慮到這一層，能不能推動這一層，就是各大Leader的能力問題了。
在抽取出統一的無線端架構組之後，至少以下幾件事情可以體現出深刻的價值來：
- 專門的跨端體驗組，提供RN的整套解決方案和各種優化以及推進等，統一規劃RN的發展方向，效率提升，流程規範等，而業務方則致力於快速實施推進業務開發的效率。
- 專門的客戶端和前端架構組，統一規範“開發方式”，所謂的工程化體系，提供各種效率工具（例如我們內部的mock系統，已經和服務端自動化整合在一起，非常高效），提供基礎元件，基礎服務（例如前端的靜態資源管理等服務）基礎腳手架，提供一些底層manger的統一實現等。
- 專門的 NodeJS 中介軟體團隊，提供一切與無線端的後端服務能力，例如閘道器服務，服務端渲染服務，RN模組管理服務，靜態託管服務，訊息服務等，其中有些服務挑戰非常大（閘道器/訊息等），後續，還準備做另外一箇中介軟體的嘗試，不過還是要按照上面講的方法論進行評估。
雖然，整個無線端包含了這麼多角色，但是我深感欣慰的是，我們在各自領域都有了一定的基礎積累，所以在這樣大整合的趨勢下，能夠良好運轉，並快速發揮各自優勢為整個團隊的發展出一份力。如果我們是從開始按照這樣的職責孵化，其實我覺得很難走到今天這一步，所以，這是一個趨勢，但是不是一種與生俱來的合理結構。
另外，在架構組職責上，還有一點很重要就是，架構這個角色絕對不止是“研究新技術/熟悉底層/產出複雜技術方案”的角色，更多時候，架構師需要深入到業務中去發現問題，然後分析問題總結問題，思考解決方案，與其他成員腦暴，制定最終解決方案，並將其最終落地的過程。所以我們有一套自己的架構流程，大抵是這個過程：
提出問題 -> 調研 -> 初步方案 -> 討論 -> 完整方案 -> 架構組分析圖 -> 業務方評審 -> 制定計劃然後實現 -> 推進落地。
你會發現其中寫程式碼的時間可能不到20%，如果你每天不是在思考或者溝通而是一直在寫程式碼，那你肯定是個假架構師。
##其他
說了這麼說，總結下我的核心觀點：
- 不要一味追隨潮流，基於場景討論問題。
- 關注技術的核心價值，不要為了用而用。
- 不要因為自己是前端而妄自菲薄，每個領域都要深紮下去。
最終，無線和前端領域這麼多概念，個人其實很難完全掌控，但是團隊一定要有能力掌控，不同的人，對不同的技術棧，做好技術積累和預研，厚積薄發，這樣的團隊在合適的機會才能更好的發揮整體價值。
更多資訊歡迎關注團隊部落格： f2e.souche.com/blog
也可以加入我的小密圈關注團隊每日動態《全棧團隊成長記錄》：t.cn/Ri2cBT0
轉載請不要刪減並註明出處：zhuanlan.zhihu.com/p/25567060
本文對你有幫助？歡迎掃碼加入前端學習小組微信群：
