前端早早聊大会，前端成长的新起点，与掘金联合举办。 加微信 codingdreamer 进大会专属内推群，赢在新的起跑线。
第十四届|前端成长晋升专场，8-29 即将直播，9 位讲师(蚂蚁金服/税友等)，点我上车👉 (报名地址)：
正文如下
- 团队成立 3 年|小爝 - 如何推动基础架构项目落地
- 团队成立 4 年|堂主 - 如何推动前端团队的基础设施建设
- 团队成立 5 年|Scott - 如何在人单力薄时立项推动基建
- 团队成立 6 年|芋头 - 如何在大前端团队实现基建价值突破
- 团队成立 12 年|崇志 - 如何设计大型前端团队基建路线
本文是第四场讲师 - 芋头的讲稿文字版，来看看他是如何讲的，视频及 PPT 未来在公众号放出。
第一部分 个人和团队介绍
个人介绍
- 大搜车资深技术专家
- 大无线相关架构、创新团队管理
- 从业 10 年，做过和带过前端、客户端、服务端
- 热爱分享，活跃于技术社区
- 没梦想，有活干就很开心了
团队介绍
- 300 左右无线相关开发人员
- 整体创新和沉淀意识在集团内也是非常突出的
- 综合型团队较多，上升空间大
- 从 17 年开始就成立几十人的无线基础设施团队
- 前端、客户端、Node.js 领域均有较为成熟的基础沉淀
个人和团队职责变化历程
公司 13 年开始组建开发团队不久之后我就加入了，最开始负责公司的前端开发相关事宜，因为我以前就是在天猫做前端的。不过虽然主业是前端，但是我当时一直觉得自己应该是要走全栈道路的，首先因为开发完整的应用，肯定不止是前端一个角色的事情，另外就是前端的生态当时已经开始显露出边界扩展的苗头，特别是 Node.js 的火热，所以在团队还没有引入过多技术栈和做过多沉淀的时候，我自己率先去做了这方面的沉淀，具体就是花了大量的时间去学习和实践 Node.js 开发，而且是奔着完成完整的产品的前后端开发去的，虽然最后没有说对 Node.js 的底层挖掘有多深入，但是的确让团队具备了初步的使用 Node.js 做开发的条件。当时在公司刚启动的过程中，分工不是特别明确，还自学并做过一段时间的 Java 开发，这个经历对我来说也是很重要的，这些都是团队后来扩展价值边界的基础，所以探讨基础设施建设，为长远沉淀的思路是贯穿始终的，是一切的基础。
从这张路线图来看，其中最重要的几个拐点：
- 开始有意识的沉淀
- 开始用 Node.js 做业务
- 开始做数据可视化业务
- 开始整合客户端开发
- Node.js 下沉基础服务
- 架构常态化、体系化
- 集团业务多样性，团队分散
- 基础设施体系化、产品化、边界拓展
- 综合型团队
最终团队的沉淀和发展，一个是这个过程中的契机决定的，一个是公司业务发展状况决定的，一个是自我沉淀的意识决定的，同时也是团队积累的方法论决定的。
这里我们不展开其他话题了，主要是这些过程，大家可以参考，可以拿去映射自己的公司，自己的团队，用以说服老板，为老板提供思路等。
现在团队大体的情况
我们团队的组织架构其实一直在演化，有时候可能半年两次的调整频率，背后也是有一些原因在里面的，这个等会儿会有专门的探讨，这里是我们过年之前大体的组织组成，其实可能 2 周后就不是这样了，最近我又有一些新的思路，可能变化会很大。
首先，我负责的团队是偏基础设施输出的，但是又不是那么绝对，为什么会是这样的组织结构呢？是多种原因造成的，一个是团队在做技术设施过程中，尝试直接影响业务，最终做的一些创新的方向，演变成了创新平台（类似于创新实验室的定位，通过技术挖掘直接改变业务进程），另外一部分是纯粹的架构是很难稳定的独立存在的，所以基础设施团队在到达一定阶段之后，需要和业务有一些交叉的边界，特别是前端领域，千万不能一条绳子上栓死，不管做什么最终衡量价值一定是对业务、商业的影响，在前期，团队和业务爆炸增加，很多架构上的问题需要专人解决，一旦解决可以大幅提效，但是当核心痛点得到解决之后，打磨和挖掘是需要的，但是如果大量人力还是耗在一些需要做但是不紧急的事情上，价值会慢慢削弱，所以，作为布局的人，需要认清这方面的事实。
目前来看，我们团队现在的整体组织架构是比较健康的：
- 基础设施，这部分已经比较成熟，更多是标准化、打磨、产品化。
- 基础服务，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 在线上直播，主题 「前端搞搭建」，扫码关注「前端早早聊」公众号参与报名：
