第二届搞基建|芋头 - 如何在大前端团队实现基建价值突破

前端早早聊大会，前端成长的新起点，与掘金联合举办。加微信 codingdreamer 进大会专属内推群，赢在新的起跑线。前端

第十四届|前端成长晋升专场，8-29 即将直播，9 位讲师(蚂蚁金服/税友等)，点我上车👉 (报名地址)：小程序

正文以下

本文是第四场讲师 - 芋头的讲稿文字版，来看看他是如何讲的，视频及 PPT 将来在公众号放出。后端

第一部分我的和团队介绍

我的介绍

大搜车资深技术专家
大无线相关架构、创新团队管理
从业 10 年，作过和带过前端、客户端、服务端
热爱分享，活跃于技术社区
没梦想，有活干就很开心了

团队介绍

300 左右无线相关开发人员
总体创新和沉淀意识在集团内也是很是突出的
综合型团队较多，上升空间大
从 17 年开始就成立几十人的无线基础设施团队
前端、客户端、Node.js 领域均有较为成熟的基础沉淀

我的和团队职责变化历程

公司 13 年开始组建开发团队不久以后我就加入了，最开始负责公司的前端开发相关事宜，由于我之前就是在天猫作前端的。不过虽然主业是前端，可是我当时一直以为本身应该是要走全栈道路的，首先由于开发完整的应用，确定不止是前端一个角色的事情，另外就是前端的生态当时已经开始显露出边界扩展的苗头，特别是 Node.js 的火热，因此在团队尚未引入过多技术栈和作过多沉淀的时候，我本身率先去作了这方面的沉淀，具体就是花了大量的时间去学习和实践 Node.js 开发，并且是奔着完成完整的产品的先后端开发去的，虽然最后没有说对 Node.js 的底层挖掘有多深刻，可是的确让团队具有了初步的使用 Node.js 作开发的条件。当时在公司刚启动的过程当中，分工不是特别明确，还自学并作过一段时间的 Java 开发，这个经历对我来讲也是很重要的，这些都是团队后来扩展价值边界的基础，因此探讨基础设施建设，为长远沉淀的思路是贯穿始终的，是一切的基础。微信

从这张路线图来看，其中最重要的几个拐点：markdown

开始有意识的沉淀
开始用 Node.js 作业务
开始作数据可视化业务
开始整合客户端开发
Node.js 下沉基础服务
架构常态化、体系化
集团业务多样性，团队分散
基础设施体系化、产品化、边界拓展
综合型团队

最终团队的沉淀和发展，一个是这个过程当中的契机决定的，一个是公司业务发展情况决定的，一个是自我沉淀的意识决定的，同时也是团队积累的方法论决定的。架构

这里咱们不展开其余话题了，主要是这些过程，你们能够参考，能够拿去映射本身的公司，本身的团队，用以说服老板，为老板提供思路等。框架

如今团队大致的状况

咱们团队的组织架构其实一直在演化，有时候可能半年两次的调整频率，背后也是有一些缘由在里面的，这个等会儿会有专门的探讨，这里是咱们过年以前大致的组织组成，其实可能 2 周后就不是这样了，最近我又有一些新的思路，可能变化会很大。异步

首先，我负责的团队是偏基础设施输出的，可是又不是那么绝对，为何会是这样的组织结构呢？是多种缘由形成的，一个是团队在作技术设施过程当中，尝试直接影响业务，最终作的一些创新的方向，演变成了创新平台（相似于创新实验室的定位，经过技术挖掘直接改变业务进程），另一部分是纯粹的架构是很难稳定的独立存在的，因此基础设施团队在到达必定阶段以后，须要和业务有一些交叉的边界，特别是前端领域，千万不能一条绳子上栓死，无论作什么最终衡量价值必定是对业务、商业的影响，在前期，团队和业务爆炸增长，不少架构上的问题须要专人解决，一旦解决能够大幅提效，可是当核心痛点获得解决以后，打磨和挖掘是须要的，可是若是大量人力仍是耗在一些须要作可是不紧急的事情上，价值会慢慢削弱，因此，做为布局的人，须要认清这方面的事实。oop

目前来看，咱们团队如今的总体组织架构是比较健康的：布局

基础设施，这部分已经比较成熟，更可能是标准化、打磨、产品化。
基础服务，Node.js 的练兵场，也是直接影响业务的前沿阵地，固然一些小的基础服务也很成熟了，大的基础服务，还须要服务公司云平台、PaaS 平台的建设输出，这是具备长远价值，并且很深入的事情。
创新实验室，高精尖，探索业务最前沿，利用基础沉淀大幅提高业务能力，也是团队边界探索的前沿阵地。
业务团队，先后端一体团队，一个是利用基础设施更快的孵化业务，一个是成为基础设施的试炼场，共赢，同时也是团队承担更多责任的突破口。

第二部分核心基建介绍

本节，我会简单罗列一下咱们的基建覆盖场景，由于内容太多，因此没有把内容展开，也没有讲某个领域咱们具体作了什么，我会适当展开一下，你们感兴趣能够会后找我，或者只是把这个当作一个目录参考。

对于咱们作过的基建，我也简单的作了一下分类：

应该有的：最基本的，必备的，行业常见的，完整的，专人负责的，到了某个阶段必需要有的基础设施。
平常沉淀：能够没有，可是有了能够在某个领域提效的，经过长时间有意识积累出来的，偏最佳实践的基础设施。
影响生存的：作很差，这个领域就混不下去的，例如 Node.js 基建。
创新探索的：端的领域拓展，全栈领域拓展，创新价值探索的，每每是一些看起来无关紧要，可是能够给业务带来巨大想象力的事情。
产品化探索：慢慢将基础设施产品化，而不是纯粹是技术方面的输出。

具体内容，这里不展开了，这个章节仍是但愿可以提供一个索引目录，当你们没有思路的时候，能够从这里面寻找一下是否有可参考价值的内容。

另外，在这些目录以外，简单总结下经验：

从平常痛点中挖掘基建内容
- 时刻抱有沉淀意识，无论是大到大型系统，仍是小到一个方法，时刻考虑提效、复用、可维护
- 培养有以上意识的人，给予足够空间和引导
主动挖掘业务痛点
- 不要等待别人指派任务，常常停下来看看业务上、商业上、产品上，有没有经过技术手段能够高效解决的问题，例如偏创新的沉淀，业务不敢想或者想不到，咱们站在他们的角度去想一想
适当时机打造正规军
- 正规军须要有正确的职责定义，须要自我挖掘和解决问题，强调产品思惟，团队价值可感知
边界试探
- 行政上，向上说服，或者是技术上，不断打破边界是很是必要的，最基本的，不要给本身设界

第三部分典型项目简介

除了提供以上的目录索引以外，虽然鉴于时间有限，不能针对某些内容展开详情，若是是这样，可能每一个事情均可以讲 1 个小时，可是又想既然提到这些内容，仍是应该简单展开几个内容，表面介绍一下，可能会给听的同窗带来一点更具体的价值，因此这一章节，我想简单介绍下几个事情的大致解决思路或者方案，正好关注某一块事情的同窗能够借鉴或者探讨。

移动标准容器和移动平台

如今不少互联网公司的业务都是基于移动端开展的，因此移动端的基础设施是很重要的，而移动端的发展趋势，总体又是在向跨端开发的方向演进，无论是 H5，仍是 RN，仍是如今流行的 Flutter，咱们把这类业务运行的环境成为“容器”，容器和容器之间偏向于独立，每一个容器是一个业务单元或者一个运行环境，之间经过路由调度，另外也经过路由能够和 Native 原有的生态互相调度，能够说“容器”是承载移动端业务最核心的部分，其余基础设施要么隐藏其后，要么直接和它关联，容器是业务和基础设施之间互通的惟一出口。

针对容器这块，初期咱们作了大量的工做，把公司大部分移动端业务都从 Native 开发转移到 H5 和 RN 的技术栈上，其实使用 H5 和 RN 自己并无过高的技术壁垒，只是把问题放到场景里就会变得复杂，团队的构成，业务的性质和量，组织架构，都会带来不少问题须要解决，而做为基础设施的开发，须要不断去平衡和解决这其中出现的问题，克服重重困难把方案落地，最终解决根本的痛点。

这个问题，在作 RN 落地的时候，体会最为明显，大概讲一下落地 RN 须要考虑的问题：

团队构成，移动端相关业务，客户端居多
业务性质，偏 B 端，业务线多，短时间内指数级增加
组织架构，业务线之间关系比较独立
技术问题，平台差别仍然存在，性能和体积等

针对这些问题须要作的解决方案：

面向 Native 开发友好，不须要花大量时间学习 React，甚至 JS，不须要花时间了解 RN 固有的一些机制和问题
面向传统流程友好，开发、部署、联调、提测、发布、更新，原有 APP 的流程习惯尽可能不破坏，不然须要改变一大批人的工做习惯
业务粒度控制，业务单元隔离
平台差别抹平，业务变薄，基础变厚，牺牲灵活性，带来标准化等

最终咱们对 H5 和 RN 开发的诸多赋能慢慢演化成这些部分。

关于整个移动端开发，除了容器和业务开发比较紧密以外，其实咱们的输出是更大的一个总体，这个总体的价值输出，可能不限于开发上的提效，还包含一些产品层面的沉淀，甚至是商业上的沉淀。

移动平台分几个阶段？

第一阶段，偏工程层面，开发标准化，运行环境标准化，平台基础能力标准化
第二阶段，偏产品层面，与业务无关的能力标准化平台化，赋能快速搭建（不止是开发层面）新的业务 APP
第三阶段，偏业务层面，赋能内部 APP 业务层面平台化，应用互通
第四阶段，偏行业层面，平台化 APP 的能力对行业开放，另外助力生态公司快速搭建本身的 APP

这几个阶段不必定是递进，有交合，也要有孵化沉淀的意识，有些事情从如今可能就要考虑将来的形态。

具体能够作哪些事情？我认为核心两个方面：

第一个方面，移动架构的基础沉淀，意义：集团全部业务线基础复用、H5/RN 跨业务迁移复用、高效标准的工程能力。赋予这些意义的能力，包含：
- 基础的运行环境（容器/路由/公共组件等）
- 业务开发提效设施（开发脚手架/持续集成/发布更新）
- 配套的基本的开发系统（托管/日志/报警）
第二个方面，快速低成本搭建或完善 APP 的能力，于内部、子公司、生态公司、行业公司。赋予这些意义的能力，包含：
- 开发基础设施层面的快速搭建（包含第一个方面的全部能力）
- 产品层面的快速搭建（消息中心、闪屏、更新、客服、IM、扫一扫、摇一摇，数据等）
- 业务层面的快速搭建（业务单元化后在 APP 间无缝迁移，外部业务快速集成等能力）

持续构建和持续部署

接下去介绍下咱们再持续集成方面作的尝试，严格来讲，咱们提供的不是持续集成的流程最佳实践（团队太多，整个流程不急着标准化），而是持续构建和部署的能力。

这里面的复杂度主要是：

技术栈不少，Vue、React、React Native、iOS、Android、小程序、Node.js。
- 上层抹平技术栈
业务线和项目不少，前端项目接近 1000 个，RN 项目接近 300 个
- 打包资源要保证
- 构建部署方式须要标准化、集中化

最终，咱们把全部无线的技术栈的集成流程作了抽象，每一个技术栈的脚手架来适配，例如：

环境抽象（测试/稳定/预发等）
动做抽象（建立/打包/部署等）

而后把全部这些抽象到一个集中的服务中，提供出 PaaS 服务，上层只须要告诉我项目是什么技术栈，须要作什么动做，其余就能够不关心了，固然咱们也有默认的上层最佳实践实现，可是业务也能够本身构建上层的持续集成流程。针对集中打包部署的性能问题，引入 tekton 集群流水线处理任务。

这里，其实咱们提供的不是一个持续集成的基础设施，而是持续集成更底层的抽象沉淀，将来它能够适应业务各个阶段不一样的诉求，属于基建底层的基建。

Node.js 框架生态

每一个前端团队都应该关注一下团队在 Node.js 方面的积累和沉淀，Node.js 在咱们团队如今发挥着各类各样的做用，其中不少领域不是一天两天的沉淀能够作到的。

例如：

前端生态自己，脚手架、持续集成中的各类服务、资源管理、开发用的服务等，脱不开 Node.js 。
创新应用的探索，无论是偏技术的，仍是偏产品的，要完成一个完整价值的输出，服务端老是脱不开的，有了 Node.js 沉淀，任何应用均可以大家本身团队内部孵化，而不须要依赖外部共建。
业务开发或者服务开发，模糊大前端团队边界，公司大了，职位高了，职责会愈来愈要求综合，你的职责就是解决问题，而不是解决前端问题。

为了作到这些，咱们在 Node.js 探索的过程当中，一直在刻意沉淀：

早期，在团队内探索，前端生态的，甚至是一些小功能尝试 Node.js 实现。
后来，Node.js 尝试作独立业务，过程沉淀一些最最基础的 SDK 和最佳实践，例如配置管理，异步任务、一些常见库的选型固定等。
后来，Node.js 尝试作底层服务，稳定性和性能要求等加深，慢慢在社区框架上固定选型，上层封装脚手架、配置管理、接口管理、文档管理等。
后来，更进一步模糊和 Java 生态相比的弱势和差别，Dubbo 接入，全链路接入，消息队列，异步任务等彻底和 Java 打通（而不是从新造轮子），这个阶段结束时，作技术选型，技术栈的差别已经不成理由。

正是有这些基建，保证了 Node.js 生态的发展，同时间接促进了团队承担更多的责任。

组件库和功能库

最后，分享下比较基础的组件库沉淀吧，这部分沉淀是比较基础的，也是早期作了以后发挥价值比较大的部分，主要分为两部分，UI 组件库和功能组件库。

UI 组件库，咱们所有都是自建，固然我并不推荐硬造轮子，自建的主要缘由仍是配合公司本身的设计规范去作落地，过程当中咱们也会直接借鉴一些社区组件库的设计来实现，同时，在建设过程当中，面向集团内跨业务的一些诉求，咱们在全部组件库之上作了一个统一的主题色管理机制，配合 APP 还能够自动切换主题，另外就是作了一些业务组件管理的能力，抛开最基本的 UI 组件，一块儿共建有一些业务特色的业务组件。

在功能组件方面，更可能是来自于业务的沉淀，例如分享库，整合全部平台的分享能力，而后内置一些分享鉴权的实现等，最终暴露给业务，是一个简单配置便可拥有强大功能的库，基本能够解决公司全部业务的分享相关问题。相似的组件还有不少。

另外，针对组件库和功能库，早期能够投入专门的人力去开发，可是后续维护，须要慢慢向共建转变，这个也是咱们的一个经验教训，以前有开发伙伴一直专门负责组件库的开发和维护，投入产出比随着时间推移，会慢慢下降。

创新平台

从 18 年末开始，我就一直在想“端”这个词的另外一层含义，前端、客户端、服务端，咱们都趟过，可是这还不是所有，我当时就在想“端”能够有更多机会和价值，放眼到行业里，云端、设备端等概念都如雨后春笋般冒出，映射到公司内，技术上、业务上，都有能够匹配的点，因此后来就下定决心，团队边界必定要向设备端这个领域延伸，固然真正的延伸是须要业务上的突破口的，脱离开业务去作物联网去作设备控制意义不大。

后来随着公司业务发展，19 年初的时候，咱们敏锐的发现很多新业务想要尝试新颖的销售和营销方式，其中涉及到不少设备的场景，因而咱们顺着这些场景去挖掘（甚至比业务看的更超前），慢慢帮助业务实现目标，另外也在设计实现的时候刻意分层，思考将来底层的沉淀和更多场景的赋能。因此后来就有了 SoucheOS 和 Souche IoT 最最基本的基础设施，把设备能力和远程控制能力作了去业务场景的抽象，有了这些能力，咱们能够快速在上层适配各类业务场景，而且顺便把集团内的办公设备在线化、测试机在线等支持了。另外这块还有对一些社交软件的控制能力，这个也是基于设备底层能力的挖掘，配合设备平台，能够轻松实现远程和群控。

第四部分组织架构的探索

分享完了一些具体的内容，接下去想和你们探讨下在基建过程当中的其余演化和思考，首当其冲的是组织架构的变化，日常你们都会讲，技术不分优劣，更重要的是看场景。组织架构就是场景之一，不一样的组织架构下可能须要不一样的作事思路，也会产生对基建的不一样诉求。不过同时，为了作好基建，也须要不断调整组织架构。这里的组织架构可能更可能是一内一外，上层组织架构决定了要作什么事情要怎么作事情，而为了作好事情，须要不断调整优化内部组织架构。

内部组织架构调整重点的考量：

基建重点是不断转移的，伴随组织架构的调整
基于技术栈组织，仍是基于项目输出组织，看阶段，看团队
纯粹的驱动力人才培养
业务和基建，创新和基础，相辅相成

第五部分项目管理的探索

基建项目的管理，历来不是一件容易事，这有多方面影响：

角色单一，不像正常项目同样有作规划的、作项管的、作质量的、作销售的，在基建项目里，可能都是一我的
开发人员容易纠结于技术自己，忽略沟通、管理、可控等环节的重要性
技术项目复杂度较高，如何群策群力，同时又能正确一致地决策

因此，咱们发现项目管理的几个重点：

如何立项一个有价值的项目
如何推进项目最终实现交付
如何将项目推向你的目标场景和用户，产生最终的价值

在咱们团队，作过不少尝试，这里只把一些可能有参考价值的方法介绍一下：

立项

立项包含多个层面，例如方向的确立，项目的确立，迭代的确立。

长远规划
- 对于方向的确立，例如在作设备平台以前，咱们是有对这个事情的想象和探讨的，对我我的来讲，偶尔会停下来，排除干扰，思考一下一些大方向的可能性，这些思考会站在一些假设之上，例如咱们将来业务会向什么方向倾斜，因此咱们将来可能会有个什么平台，最完美状态是什么样的，如何在业务中发挥极大价值，不过这些想象可能永远都达不到，可是价值是能够不断分层和降级的，想的足够远，可是也要分解成阶段回到当下。在我思路比较活跃的时候，我会把这些想法写成“长远规划”，而后讲给团队里的骨干听，探讨一下，或者同步下站在比较高的角度对这些事情的想象，若是你认同，能够参考，把事情一步一步作成，若是不认同，能够发表你的想法

举几个以前长远思考过的几个方向：

开放平台服务 -> 开放平台产品 -> 云平台工做窗口 -> PaaS ISV 工做窗口 -> 服务场景管理编排 -> 移动开放平台等，咱们作的固然还远远不够，将来要作什么，能够参考的方向不少。

移动端基础设施->运营平台-> PaaS 开发平台，赋能内部、集团、行业，mPaaS 是可参考的标品。

等等，一般这些思考，会参考行业产品，考察业务、商业上的发展等

调研报告
- 长远规划可能更偏向理想状况，真正要开始一个项目，须要作更为细致的分析，确保接下去投入的资源是有价值、可持续的
- 这些事情，其实有点相似于产品经理须要作的事情，作用户调研，需求调研，或者是本身分析出来的痛点，可是在整理想法后，也是须要和对应的业务方勾兑交流，修正思路

这里，其实最好能引入一些产品方法论，例如“用户故事”，需求分析文档，从不一样类型的用户的角度，开始分析背景、问题、思路、方案、改进后的用户路径、感觉等。我一直想跟你们强调，作技术设施，必定要锻炼本身的产品分析能力，由于没有人会帮你去分析整个事情的前因后果，须要靠本身去挖掘方向和需求，若是你仍是一直等待需求的出现，那你是走不远的。

可行性方案
- 最终，在肯定一个项目以前，须要有书面可行性方案，而且组织参与者和相关者对可行性方案进行评审，并作修正

不过这些流程都不是绝对的，看项目类型能够适当调整，并非绝对的全部项目都要通过最细致的流程，有时候，过于细致的流程，虽然能够保证事情的可控，可是也会拖慢进展，有些技术项目，反而是越快越好，须要快速试错，这其中平衡，还需不断调整。

推动

基建项目，若是是一我的或者一带一，推动问题可能还不大，可是一般不少会涉及到跨技术栈角色的合做，甚至是跨团队的合做，要保证这样的项目更好地落地，仍是须要较为规范的项目管理方式的，其实这里和普通的业务项目没有太大的差异，技术方案评审，排期，接口文档等。

这里提到架构设计，不过说实话，一个系统刚开始的时候，很难给出完整的 C4 架构设计，这里提到的 C4 架构设计，更可能是在项目迭代过程当中，逐渐梳理细化出来的，用以向外同步信息和内部参考迭代。

另外，一个比较重要的点，是里程碑的分解和制定，基建项目一般体量不可控，若是一开始就设计了一个庞大的完整的方案，交付时间几个月，这时候就要想一想里面是否是充满了不可控的风险，这几个月任何事情均可能发生，业务诉求、组织架构、人员变更，因此必定要把目标分解里程碑，每一个里程碑有个阶段的产出，注意这里的里程碑不是把一个长的任务直接切开几份变成短的任务，而是每一个里程碑你交付的可能都是一个最小可用的总体，早期尽快成型，后期迭代优化增长新特性，要养成分解达成的习惯，而不是一蹴而就。

运营

技术运营也是基建的一个逃不开的比较磨人的话题，特别是对于大一点的团队来讲，基建的落地是须要本身去主动推进推广的，对基建的输出的要求不是作个库作个框架这么简单，而是输出一个产品，你须要准备资料，讲清楚前因后果，讲清楚你的理解，讲清楚你的优点，建清楚如何使用，形式可能各类各样，文档固然是必备的，白皮书也是须要的（文档更可能是介绍如何使用，白皮书是告诉别人为啥要用），分享是基本的但不必定是有效的，工做坊是更有效可是成本较高的，须要本身平衡和探索。另外就是技术运营要是持续性的，而不是一次了事，事不关己高高挂起爱用不用。

下图里咱们给团队的产品甚至都订作了文化衫，去强化你们对基建产品的了解

第六部分其余经验总结

经过刚才讲的一些内容，咱们简单总结一下。

要作好基建，较为核心的点：

组织架构保障。无论是最初的先行小组，仍是后来专门的基建团队培养，Leader 要作好组织上的保障，为基建争取空间
项目管理推动保障。架构项目的特殊性，须要有方式解决推动管理，确保结果落地
沉淀意识。Leader 本身要很是敏感，同时挖掘培养有沉淀意识的同窗，沉淀都是来自于平常工做
贴近业务价值。不要脱离场景造轮子，没法发挥价值，也得不到上下级的承认。

另外，一些细节的注意点：

不要给本身和别人挖坑
- 不要盲目扩展团队技术栈
- 完整的开发过程和使用文档
- 切忌假大空，上来就规划一个平台，最终只有一个烂摊子
- 适当尝试，适当投入，但也要对风险合理评估，并有规避方案
- 想的能够尽可能远，可是要回到当下根据实际状况分解节奏
可是也要适当造轮子
- 适合本身的实现，按照本身的路径迭代
- 磨炼团队技术能力，增长对技术细节的深刻，为将来作沉淀
- 系统思惟其实很难养成，须要场景
- 须要平衡，资源、风险、投入产出比、可持续性，对本身的团队要有一个正确的认知
注重系统思惟
- 学会本身作决策和负责任，而不是执行任务，或者完成交代
- 更透彻的理解一个问题
  - 不断追问本身为何要作一个事情
  - 理解的原由是否也是基于某个结论
  - 例如：我要作 xx，由于 xx 业务说他们须要 xxx
  - 为何要这样作
- 层次感，规划、系统架构、价值体现方面，随时解耦重组
切忌半途而废
- 逼本身挖掘深度价值
- 固然也不要盲目挖掘，确保大方向是对的
- 慢慢系统化、产品化、尝试打通任督二脉
- 切忌浮于表面，走马观花
克服孤独感
- 热爱、相信、投入、开放
- 主人翁意识，为输出及其价值负责和决策

第七部分今日分享总结

最后，你们有问题，能够加我微信探讨，或者在行上约我面聊，感谢你们。

第三期 2020.3.28 在线上直播，主题「前端搞搭建」，扫码关注「前端早早聊」公众号参与报名：