关于「无线开发中心」团队

我们是谁

我们是「无线开发中心」，一个跨多栈，并且在每个方向上都有专业输出的团队，包括 前端、客户端、Nodejs 服务端 等技术领域。

「无线开发中心」团队是大搜车研发中心的一级部门，直接向 CTO 汇报，由”芋头“带队，分为 7 个面向各个领域的团队。

「无线开发中心」的使命：做集团业务的发动机，推动汽车产业数字文明的落地

「无线开发中心」的愿景：形成高度标准化的无线工程体系和完备的（开放、沟通、触达、体验）服务场景支持

我们做什么

总的来看，团队主要在三个方向上做核心输出：

无线工程保障
无线平台服务
无线业务支撑

接下来会分别再简单介绍下各个方向。

方向一：工程保障

工程保障其实涵盖的方面比较广，所有面向开发提效的系统都可以成为工程保障，不过「无线开发中心」的重点是站在集团的角度去做这件事情，保障集团内部所有无线开发 标准化 、 流水线化 ，让业务开发将精力更多投入到如何落地业务中去。核心输出这里简单介绍下吧：

标准容器

未来所有 app 都会成为平台，而业务则是寄生于平台的应用，所有的应用都是一个抽象的实体（例如微信和小程序的关系），而所有的应用都会有一种标准的 开发 、 运维 、 运行 方式，这就是我们所讲的 容器 ，这不是一个纯技术的概念，而是一个大的体系，承载着未来所有业务应用的开发、运维、运行等一整套开发体系。

目前大搜车内部还未形成完全一致的容器体系，而是存在 ReactNative 体系、Webview 体系等多套开发体系，每套体系会有自己的一套从开发到运维的解决方案，这也是我们投入非常多精力的部分，但是未来可能还会有更加标准化的体系形成。

UI 资产

UI 资产也分为很多个层面，但是 UI 资产最具价值的点不是做了组件库或者怎么滴，而是与设计师和业务产品真正联动起来，设计上有一套标准规范，业务上落地标准规范，技术上实现成对应的产品，再与业务落地结合，最终形成闭环，这样才能做到快速生产业务应用的效果。

这方面我们去年与设计团队做了很多努力，真正形成设计和技术闭环落地。

具体的沉淀，包含各端的组件库，都按照社区开源标准去产出和维护，包括：

SRN.UI
So.UI-React
So.UI-Vue
Som-B.UI
Som.UI
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
easy-mock
Zoro
srn-hub
Cuckoo
Reiko

这些基本都是比较完备的系统，还有些新系统在开发中，不一一列举。

大概先分享这些，其他暂时不够系统化的事情以后再分享吧。

方向二：平台服务

这也是我们团队一块比较重、业务价值比较大的事情，可能在一般的前端团队不会太常见，所以一直当做我们的特色去打磨发展，通俗来讲，就是我们会承担基础服务的角色，这些服务有些是偏服务端的，有些是偏无线端的，但是大部分都是前后端都需要的，我们团队自己即完成从产品规划到前后端开发，这些事情对于打磨团队多个技术栈之间的磨合能力帮助很大，对公司的业务来说也都有非常直接的影响。

这里展开几个典型的服务和大家分享（所有服务端都基于 Node.js 开发，另外因为和业务相关涉密较多，可能不会细讲）：

开放平台

没错，就是大家理解中的开放平台，这是一个非常复杂的系统，承担了三个重要职责：

内部服务对外开放
外部服务对内聚合
公司内不同物理域之间的服务互通

系统内部的子系统大概就有七八个，具有完备的机制，包括： 开放 、 聚合 、 消息 、 文件 、 用户 、 计费 、 内部工作台 、 商户工作台 等等，具体因为保密问题，不展开。

开放平台主要能力是对开放和聚合做统一的管控，对商户做管控，对商户的调用做管控等，另外因为对接业务量非常大，还有很多针对开发接入商户接入的 工具 部分的开发。

消息触达

消息中心是一个比较模糊的概念，主要职责如下：

集团内所有 app 的推送
集团内所有业务的短信推送
集团内所有业务的 聊天、客服能力

因为业务量比较庞大，围绕如何管控业务，做了很多管控措施，例如业务分类、模板、审批、报表、历史查询等。 并且可以提供给业务自有切换后端服务商的能力

因为这个系统的数据量非常大，可能是公司最先开始考虑分库分表，并且定期做数据静态化的系统。

体验科技

刚才两个系统是纯服务端的系统（或者带有少量的前端 SDK），不过类似的系统因为和公司业务比较紧密，很多只能保密，不能拿出来和大家分享。另外我们也会有一些端上的服务的输出，直接去影响业务。

例如，业界流行的 ioT ，现在我们公司也有很多新媒体设备需要管控和触达等能力，例如：电视盒子、广告屏、pos 机、xxx 机（保密）、车载设备等，所以我们也在孵化自己的 ioT 平台，对所有类似的”终端“做管控和赋能。

例如， 多媒体赋能 ，因为团队很多同学能力都会偏底层，我们会利用这些优势向业务输出一些开发难度高，但是体验更好的组件，例如 360 拍照，拼图海报，视频编解码播放，AR 应用，端上智能识别等，在这方面我们也有不少已经落地的输出。

方向三：业务支撑

业务保障主要是对研发内部的产品的支撑，以及对部分总部的业务的支撑。

这些具体可能不太好表述，不过在业务支撑的同时，我们也在尝试一些技术上的沉淀，例如：

可视化组件库
大屏组件库
数据采集工具
活动搭建平台
审批流程配置工具

我们的工作方式

团队工作模式比较自由，除了 leader 之外，不会有太多管理上的约束，我们的初衷还是要打造工程师文化，因为我们是一个偏技术赋能型的团队，技术和创意很重要，而不是按时完成任务。

但是有一点是我们比较关注的，就是作为一个输出型团队，如何规范的管理自己的输出，才能和集团这么多业务方形成良好的联动效果，这对技术团队来说是个比较大的挑战，但是也是可以带来很好的成长的，例如我们通过 定方向 -> 同步所有业务 -> 同意后，出具体规划 -> 同步所有业务 -> 同意后，开始开发 -> 发布版本 -> 记录 changelog 和使用文档 -> 同步业务方 这样的方式做项目，可能大家会觉得这样的方式会不会对个人成长不利，恰恰相反，保持这样的节奏做事情，会让你更系统的去思考问题和解决方案，也会对你有更高的要求（要说清楚，还要睡服其他人），能做到这些的开发，能力绝对不会差。而在平常面试的时候，你会发现很多人无法表述清楚自己的想法和方案，就是因为缺乏这样的训练。

另外，团队里比较崇尚分享，形式比较多的是 codereview（面对面） 、 项目复盘 、 纯技术分享 等，团队内有记星星的模式，对各种不同类型的分享记录星星，每年两次复盘，对贡献突出者做奖励。

另外，这样的一个团队结构和方向，我们鼓励所有人在自己的专业领域能够不断深入和挖掘，同时也鼓励大家能够了解更多其他技术栈的开发，扩展自己的技术视野。

想加入我们

简历直接投递：sunxinyu@souche.com，注明：应聘