關於大搜車「無線開發中心」團隊

大搜車無線開發中心發表於2019-04-17

更多文章,參見大搜車技術部落格:blog.souche.com/

大搜車無線開發中心持續招聘中,前端,Nodejs,android 均有 HC,簡歷直接發到:sunxinyu@souche.com

我們是誰

大家好,我們是無線開發中心,一個跨多棧、偏核心技術輸出賦能的團隊,包括 前端、客戶端、Nodejs 服務端 等技術領域,向大搜車整體集團提供工程保障和服務支撐。

大搜車是一家提供汽車行業數字解決方案的公司,業務範圍覆蓋二手車、新車、租賃、金融、新零售、拍賣等方向,員工現有 4500 多人,擁有多個事業部和子公司。

無線開發中心團隊是大搜車研發中心的一級部門,直接向 CTO 彙報,由芋頭帶隊,內部有 7 個面向各個領域的子團隊。

無線開發中心的使命:做集團業務的發動機,推動汽車產業數字文明的落地

無線開發中心的願景:形成高度標準化的無線工程體系和完備的(開放、溝通、觸達、體驗)服務場景支援

我們做什麼

總的來看,團隊主要在三個方向上做核心輸出:

  • 無線工程保障:包含 前端、客戶端 領域的所有基礎設施建設(研發基礎支撐,各技術棧開發體系,UI 體系等),所有建設都基本是多棧完備的,支撐公司內部所有事業部、子公司、業務線 端上開發的基礎設施,為開發提效。
  • 無線平臺服務:為集團業務輸出通用的、完備的基礎服務,這些基礎服務有帶有明顯”端“色彩的,也有純粹的服務端基礎服務,這個方向我們所有的輸出都是”完備“的,意思就是需要從產品、到架構、到前後端開發,整體輸出,很多核心繫統支撐著公司內所有相關場景的服務。
  • 無線業務支撐:研發中心內部產品的共同研發,技術型產品、共享型產品、資料產品等方向,同時也承擔一些業務產品的支撐。

接下來會分別再簡單介紹下各個方向。

方向一:工程保障

工程保障其實涵蓋的方面比較廣,所有面向開發提效的系統都可以成為工程保障,不過「無線開發中心」的重點是站在集團的角度去做這件事情,保障集團內部所有無線開發標準化流水線化,讓業務開發將精力更多投入到如何落地業務中去。核心輸出這裡簡單介紹下吧:

標準容器

未來所有 app 都會成為平臺,而業務則是寄生於平臺的應用,所有的應用都是一個抽象的實體(例如微信和小程式的關係),而所有的應用都會有一種標準的開發運維執行方式,這就是我們所講的容器,這不是一個純技術的概念,而是一個大的體系,承載著未來所有業務應用的開發、運維、執行等一整套開發體系。

目前大搜車內部還未形成完全一致的容器體系,而是存在 ReactNative 體系、Webview 體系等多套開發體系,每套體系會有自己的一套從開發到運維的解決方案,這也是我們投入非常多精力的部分,但是未來可能還會有更加標準化的體系形成。

UI 資產

UI 資產也分為很多個層面,但是 UI 資產最具價值的點不是做了元件庫或者怎麼滴,而是與設計師和業務產品真正聯動起來,設計上有一套標準規範,業務上落地標準規範,技術上實現成對應的產品,再與業務落地結合,最終形成閉環,這樣才能做到快速生產業務應用的效果。

這方面我們去年與設計團隊做了很多努力,真正形成設計和技術閉環落地。

具體的沉澱,包含各端的元件庫,都按照社群開源標準去產出和維護,包括:

  • SRN.UI ,RN 移動端元件庫
  • So.UI-React ,PC React 元件庫
  • So.UI-Vue ,PC Vue 元件庫
  • Som-B.UI ,移動端 C 端元件庫
  • Som.UI ,移動端 H5 元件庫
  • Som.UI-mini ,小程式元件庫
  • Aqua,區塊庫

另外還有多端統一的主題切換能力等,大家對這方面瞭解應該比較多,就不細講了。

開發框架

開發框架的意義一個是規範不同團隊的一些基本開發方式以保持不同業務開發的一致性,另外將部分繁瑣的開發事項簡化,最後就是提供一些開發最佳實踐的指導。我們在每個端都會適當的抽象自己的開發最佳實踐,簡化大家的開發過程,同時又要考慮保持開發靈活度,不過多的限制開發方式。

目前主要是以下幾個框架:

  • srn-framework ,RN 開發框架,所有 RN 業務都基於此框架開發,並在內部整合與 native 互通,協議,配置,環境管理等能力。
  • muji,React 開發框架,”使用 TypeScript 編寫企業級 React 應用“,為解決前端應用開發中的路由狀態儲存兩大問題而生,同時解決一些企業內的特殊場景問題,在公司的 管理系統中有廣泛的使用。
  • Trojans ,一套基於 React 的,在後端 Java 專案中融合前端程式碼的解決方案,基於此方案公司內部的管理系統基本完全無需前端參與,這套方案比較神奇,利用 React 實現類似於傳統 jsp 的開發模式,不過現在部分 java 開發在向 muji 切換,大家對 React 的瞭解程度在提高。
  • 藍風 blue-windy,一套企業級 Nodejs 開發框架,基於 egg.js 封裝。簡化了企業內部 node 應用開發的難度,很多前端可以自己開發穩定易用的線上服務。

研發支撐

或者說是工程效能,開發過程等,主要是提供開發時或者執行時的一些系統性支援或者環境支援。

例如 前端和客戶端的測試環境如何統一管理,線上環境如何管理。

例如 前端\客戶端\RN 等專案如何生成、託管、聯調、測試、釋出等一條龍(持續整合)

例如 專案上線後,如何熱更新,如何快速排查問題,如何報警等

在這方面我們也有一些系統產出:

  • SoBox,一個環境管理&代理抓包的PC軟體
  • easy-mock,開源了的介面模擬應用
  • Zoro,sketch外掛,設計素材管理,與設計師聯動 UI 管理
  • srn-hub,RN 開發服務(熱更,應用註冊,依賴檢查等服務)
  • Cuckoo,線上保障平臺(搖一搖反饋,崩潰管理,報警等)
  • Reiko,app 應用託管平臺,公司內所有 app 都託管於此
  • 釋出單系統,專案管理系統等

這些基本都是比較完備的系統,還有些新系統在開發中,不一一列舉。

大概先分享這些,其他暫時不夠系統化的事情以後再分享吧。

方向二:平臺服務

這也是我們團隊一塊比較重、業務價值比較大的事情,可能在一般的前端團隊不會太常見,所以一直當做我們的特色去打磨發展,通俗來講,就是我們會承擔基礎服務的角色,這些服務有些是偏服務端的,有些是偏無線端的,但是大部分都是前後端都需要的,我們團隊自己即完成從產品規劃到前後端開發,這些事情對於打磨團隊多個技術棧之間的磨合能力幫助很大,對公司的業務來說也都有非常直接的影響。

這裡展開幾個典型的服務和大家分享(所有服務端都基於 Node.js 開發,另外因為和業務相關涉密較多,可能不會細講):

開放平臺

沒錯,就是大家理解中的開放平臺,這是一個非常複雜的系統,承擔了三個重要職責:

  • 內部服務對外開放
  • 外部服務對內聚合
  • 公司內不同物理域之間的服務互通

系統內部的子系統大概就有七八個,具有完備的機制,包括:開放聚合訊息檔案使用者計費內部工作臺商戶工作臺等等,具體因為保密問題,不展開。

開放平臺主要能力是對開放和聚合做統一的管控,對商戶做管控,對商戶的呼叫做管控等,另外因為對接業務量非常大,還有很多針對開發接入商戶接入的工具部分的開發。

訊息觸達

訊息中心是一個比較模糊的概念,主要職責如下:

  • 集團內所有 app 的推送
  • 集團內所有業務的簡訊推送
  • 集團內所有業務的 聊天、客服能力

因為業務量比較龐大,圍繞如何管控業務,做了很多管控措施,例如業務分類、模板、審批、報表、歷史查詢等。 並且可以提供給業務自有切換後端服務商的能力

因為這個系統的資料量非常大,可能是公司最先開始考慮分庫分表,並且定期做資料靜態化的系統。

體驗科技

剛才兩個系統是純服務端的系統(或者帶有少量的前端 SDK),不過類似的系統因為和公司業務比較緊密,很多隻能保密,不能拿出來和大家分享。另外我們也會有一些端上的服務的輸出,直接去影響業務。

例如,業界流行的 ioT,現在我們公司也有很多新媒體裝置需要管控和觸達等能力,例如:電視盒子、廣告屏、pos 機、xxx 機(保密)、車載裝置等,所以我們也在孵化自己的 ioT 平臺,對所有類似的”終端“做管控和賦能。

例如,多媒體賦能,因為團隊很多同學能力都會偏底層,我們會利用這些優勢向業務輸出一些開發難度高,但是體驗更好的元件,例如 360 拍照,拼圖海報,視訊編解碼播放,AR 應用,端上智慧識別等,在這方面我們也有不少已經落地的輸出。

方向三:業務支撐

業務保障主要是對研發內部的產品的支撐,以及對部分總部的業務的支撐。

這些具體可能不太好表述,不過在業務支撐的同時,我們也在嘗試一些技術上的沉澱,例如:

  • 視覺化元件庫,在資料視覺化業務中,下沉的標準元件庫,同樣是和設計師聯動
  • 大屏元件庫,在資料大屏業務中下沉,賦能快速搭建資料大屏
  • 資料採集工具,在營銷業務中,一種統一的資料採集工具及配套設施
  • 活動搭建平臺,將營銷活動元件化,快速搭建各種營銷活動,並且自動迴流資料
  • 審批流程配置工具,快速配置一個自己的審批流程表單
  • 諸如此類

我們的工作方式

團隊工作模式比較自由,除了 leader 之外,不會有太多管理上的約束,我們的初衷還是要打造工程師文化,因為我們是一個偏技術賦能型的團隊,技術和創意很重要,而不是按時完成任務。

但是有一點是我們比較關注的,就是作為一個輸出型團隊,如何規範的管理自己的輸出,才能和集團這麼多業務方形成良好的聯動效果,這對技術團隊來說是個比較大的挑戰,但是也是可以帶來很好的成長的,例如我們通過 定方向 -> 同步所有業務 -> 同意後,出具體規劃 -> 同步所有業務 -> 同意後,開始開發 -> 釋出版本 -> 記錄 changelog 和使用文件 -> 同步業務方 這樣的方式做專案,可能大家會覺得這樣的方式會不會對個人成長不利,恰恰相反,保持這樣的節奏做事情,會讓你更系統的去思考問題和解決方案,也會對你有更高的要求(要說清楚,還要睡服其他人),能做到這些的開發,能力絕對不會差。而在平常面試的時候,你會發現很多人無法表述清楚自己的想法和方案,就是因為缺乏這樣的訓練。

另外,團隊裡比較崇尚分享,形式比較多的是 codereview(面對面)專案覆盤純技術分享等,團隊內有記星星的模式,對各種不同型別的分享記錄星星,每年兩次覆盤,對貢獻突出者做獎勵。

另外,這樣的一個團隊結構和方向,我們鼓勵所有人在自己的專業領域能夠不斷深入和挖掘,同時也鼓勵大家能夠了解更多其他技術棧的開發,擴充套件自己的技術視野。

想加入我們

簡歷直接投遞:sunxinyu@souche.com,註明:應聘

相關文章