前端早早聊大会,前端成长新起点,帮你提前一星期,站在新的起跑线,目标成为用得上,听得懂,抄得走的前端大会,计划 2020 年办 12 期,由前端早早聊与掘金联合举办。
历届大会 PPT/录播视频/图文讲稿,可到公众号 「前端早早聊」 回复 "大会" 二字获取。
本文是第四场讲师 - 芋头的讲稿文字版,来看看他是如何讲的,视频及 PPT 未来在公众号放出。
公司 13 年开始组建开发团队不久之后我就加入了,最开始负责公司的前端开发相关事宜,因为我以前就是在天猫做前端的。不过虽然主业是前端,但是我当时一直觉得自己应该是要走全栈道路的,首先因为开发完整的应用,肯定不止是前端一个角色的事情,另外就是前端的生态当时已经开始显露出边界扩展的苗头,特别是 Node.js 的火热,所以在团队还没有引入过多技术栈和做过多沉淀的时候,我自己率先去做了这方面的沉淀,具体就是花了大量的时间去学习和实践 Node.js 开发,而且是奔着完成完整的产品的前后端开发去的,虽然最后没有说对 Node.js 的底层挖掘有多深入,但是的确让团队具备了初步的使用 Node.js 做开发的条件。当时在公司刚启动的过程中,分工不是特别明确,还自学并做过一段时间的 Java 开发,这个经历对我来说也是很重要的,这些都是团队后来扩展价值边界的基础,所以探讨基础设施建设,为长远沉淀的思路是贯穿始终的,是一切的基础。
从这张路线图来看,其中最重要的几个拐点:
最终团队的沉淀和发展,一个是这个过程中的契机决定的,一个是公司业务发展状况决定的,一个是自我沉淀的意识决定的,同时也是团队积累的方法论决定的。
这里我们不展开其他话题了,主要是这些过程,大家可以参考,可以拿去映射自己的公司,自己的团队,用以说服老板,为老板提供思路等。
我们团队的组织架构其实一直在演化,有时候可能半年两次的调整频率,背后也是有一些原因在里面的,这个等会儿会有专门的探讨,这里是我们过年之前大体的组织组成,其实可能 2 周后就不是这样了,最近我又有一些新的思路,可能变化会很大。
首先,我负责的团队是偏基础设施输出的,但是又不是那么绝对,为什么会是这样的组织结构呢?是多种原因造成的,一个是团队在做技术设施过程中,尝试直接影响业务,最终做的一些创新的方向,演变成了创新平台(类似于创新实验室的定位,通过技术挖掘直接改变业务进程),另外一部分是纯粹的架构是很难稳定的独立存在的,所以基础设施团队在到达一定阶段之后,需要和业务有一些交叉的边界,特别是前端领域,千万不能一条绳子上栓死,不管做什么最终衡量价值一定是对业务、商业的影响,在前期,团队和业务爆炸增加,很多架构上的问题需要专人解决,一旦解决可以大幅提效,但是当核心痛点得到解决之后,打磨和挖掘是需要的,但是如果大量人力还是耗在一些需要做但是不紧急的事情上,价值会慢慢削弱,所以,作为布局的人,需要认清这方面的事实。
目前来看,我们团队现在的整体组织架构是比较健康的:
本节,我会简单罗列一下我们的基建覆盖场景,因为内容太多,所以没有把内容展开,也没有讲某个领域我们具体做了什么,我会适当展开一下,大家感兴趣可以会后找我,或者只是把这个当做一个目录参考。
对于我们做过的基建,我也简单的做了一下分类:
具体内容,这里不展开了,这个章节还是希望能够提供一个索引目录,当大家没有思路的时候,可以从这里面寻找一下是否有可参考价值的内容。
另外,在这些目录之外,简单总结下经验:
除了提供以上的目录索引之外,虽然鉴于时间有限,不能针对某些内容展开详情,如果是这样,可能每个事情都可以讲 1 个小时,但是又想既然提到这些内容,还是应该简单展开几个内容,表面介绍一下,可能会给听的同学带来一点更具体的价值,所以这一章节,我想简单介绍下几个事情的大体解决思路或者方案,正好关注某一块事情的同学可以借鉴或者探讨。
现在很多互联网公司的业务都是基于移动端开展的,所以移动端的基础设施是很重要的,而移动端的发展趋势,整体又是在向跨端开发的方向演进,不管是 H5,还是 RN,还是现在流行的 Flutter,我们把这类业务运行的环境成为“容器”,容器和容器之间偏向于独立,每个容器是一个业务单元或者一个运行环境,之间通过路由调度,另外也通过路由可以和 Native 原有的生态互相调度,可以说“容器”是承载移动端业务最核心的部分,其他基础设施要么隐藏其后,要么直接和它关联,容器是业务和基础设施之间互通的唯一出口。
针对容器这块,初期我们做了大量的工作,把公司大部分移动端业务都从 Native 开发转移到 H5 和 RN 的技术栈上,其实使用 H5 和 RN 本身并没有太高的技术壁垒,只是把问题放到场景里就会变得复杂,团队的构成,业务的性质和量,组织架构,都会带来很多问题需要解决,而作为基础设施的开发,需要不断去平衡和解决这其中出现的问题,克服重重困难把方案落地,最终解决根本的痛点。
这个问题,在做 RN 落地的时候,体会最为明显,大概讲一下落地 RN 需要考虑的问题:
针对这些问题需要做的解决方案:
最终我们对 H5 和 RN 开发的诸多赋能慢慢演化成这些部分。
关于整个移动端开发,除了容器和业务开发比较紧密之外,其实我们的输出是更大的一个整体,这个整体的价值输出,可能不限于开发上的提效,还包含一些产品层面的沉淀,甚至是商业上的沉淀。
移动平台分几个阶段?
这几个阶段不一定是递进,有交合,也要有孵化沉淀的意识,有些事情从现在可能就要考虑未来的形态。
具体可以做哪些事情?我认为核心两个方面:
第一个方面,移动架构的基础沉淀,意义:集团所有业务线 基础复用、H5/RN 跨业务迁移复用、高效标准的工程能力。赋予这些意义的能力,包含:
第二个方面,快速低成本搭建或完善 APP 的能力,于内部、子公司、生态公司、行业公司。赋予这些意义的能力,包含:
接下去介绍下我们再持续集成方面做的尝试,严格来说,我们提供的不是持续集成的流程最佳实践(团队太多,整个流程不急着标准化),而是持续构建和部署的能力。
这里面的复杂度主要是:
最终,我们把所有无线的技术栈的集成流程做了抽象,每个技术栈的脚手架来适配,例如:
然后把所有这些抽象到一个集中的服务中,提供出 PaaS 服务,上层只需要告诉我项目是什么技术栈,需要做什么动作,其他就可以不关心了,当然我们也有默认的上层最佳实践实现,但是业务也可以自己构建上层的持续集成流程。针对集中打包部署的性能问题,引入 tekton 集群流水线处理任务。
这里,其实我们提供的不是一个持续集成的基础设施,而是持续集成更底层的抽象沉淀,未来它可以适应业务各个阶段不同的诉求,属于基建底层的基建。
每个前端团队都应该关注一下团队在 Node.js 方面的积累和沉淀,Node.js 在我们团队现在发挥着各种各样的作用,其中很多领域不是一天两天的沉淀可以做到的。
例如:
为了做到这些,我们在 Node.js 探索的过程中,一直在刻意沉淀:
正是有这些基建,保证了 Node.js 生态的发展,同时间接促进了团队承担更多的责任。
最后,分享下比较基础的组件库沉淀吧,这部分沉淀是比较基础的,也是早期做了之后发挥价值比较大的部分,主要分为两部分,UI 组件库和功能组件库。
UI 组件库,我们全部都是自建,当然我并不推荐硬造轮子,自建的主要原因还是配合公司自己的设计规范去做落地,过程中我们也会直接借鉴一些社区组件库的设计来实现,同时,在建设过程中,面向集团内跨业务的一些诉求,我们在所有组件库之上做了一个统一的主题色管理机制,配合 APP 还可以自动切换主题,另外就是做了一些业务组件管理的能力,抛开最基本的 UI 组件,一起共建有一些业务特点的业务组件。
在功能组件方面,更多是来自于业务的沉淀,例如 分享库,整合所有平台的分享能力,然后内置一些分享鉴权的实现等,最终暴露给业务,是一个简单配置即可拥有强大功能的库,基本可以解决公司所有业务的分享相关问题。类似的组件还有很多。
另外,针对组件库和功能库,早期可以投入专门的人力去开发,但是后续维护,需要慢慢向共建转变,这个也是我们的一个经验教训,之前有开发伙伴一直专门负责组件库的开发和维护,投入产出比随着时间推移,会慢慢降低。
从 18 年底开始,我就一直在想“端”这个词的另一层含义,前端、客户端、服务端,我们都趟过,但是这还不是全部,我当时就在想“端”可以有更多机会和价值,放眼到行业里,云端、设备端等概念都如雨后春笋般冒出,映射到公司内,技术上、业务上,都有可以匹配的点,所以后来就下定决心,团队边界一定要向设备端这个领域延伸,当然真正的延伸是需要业务上的突破口的,脱离开业务去做物联网去做设备控制意义不大。
后来随着公司业务发展,19 年初的时候,我们敏锐的发现不少新业务想要尝试新颖的销售和营销方式,其中涉及到很多设备的场景,于是我们顺着这些场景去挖掘(甚至比业务看的更超前),慢慢帮助业务实现目标,另外也在设计实现的时候刻意分层,思考未来底层的沉淀和更多场景的赋能。所以后来就有了 SoucheOS 和 Souche IoT 最最基本的基础设施,把设备能力和远程控制能力做了去业务场景的抽象,有了这些能力,我们可以快速在上层适配各种业务场景,并且顺便把集团内的办公设备在线化、测试机在线等支持了。另外这块还有对一些社交软件的控制能力,这个也是基于设备底层能力的挖掘,配合设备平台,可以轻松实现远程和群控。
分享完了一些具体的内容,接下去想和大家探讨下在基建过程中的其他演化和思考,首当其冲的是组织架构的变化,平常大家都会讲,技术不分优劣,更重要的是看场景。组织架构就是场景之一,不同的组织架构下可能需要不同的做事思路,也会产生对基建的不同诉求。不过同时,为了做好基建,也需要不断调整组织架构。这里的组织架构可能更多是一内一外,上层组织架构决定了要做什么事情要怎么做事情,而为了做好事情,需要不断调整优化内部组织架构。
内部组织架构调整重点的考量:
基建项目的管理,从来不是一件容易事,这有多方面影响:
所以,我们发现项目管理的几个重点:
在我们团队,做过很多尝试,这里只把一些可能有参考价值的方法介绍一下:
立项包含多个层面,例如方向的确立,项目的确立,迭代的确立。
举几个之前长远思考过的几个方向:
- 开放平台服务 -> 开放平台产品 -> 云平台工作窗口 -> PaaS ISV 工作窗口 -> 服务场景管理编排 -> 移动开放平台等,我们做的当然还远远不够,未来要做什么,可以参考的方向很多。
- 移动端基础设施->运营平台-> PaaS 开发平台,赋能内部、集团、行业,mPaaS 是可参考的标品。
- 等等,通常这些思考,会参考行业产品,考察业务、商业上的发展等
这里,其实最好能引入一些产品方法论,例如“用户故事”,需求分析文档,从不同类型的用户的角度,开始分析背景、问题、思路、方案、改进后的用户路径、感受等。我一直想跟大家强调,做技术设施,一定要锻炼自己的产品分析能力,因为没有人会帮你去分析整个事情的来龙去脉,需要靠自己去挖掘方向和需求,如果你还是一直等待需求的出现,那你是走不远的。
不过这些流程都不是绝对的,看项目类型可以适当调整,并不是绝对的所有项目都要经过最细致的流程,有时候,过于细致的流程,虽然可以保证事情的可控,但是也会拖慢进展,有些技术项目,反而是越快越好,需要快速试错,这其中平衡,还需不断调整。
基建项目,如果是一个人或者一带一,推进问题可能还不大,但是通常很多会涉及到跨技术栈角色的合作,甚至是跨团队的合作,要保证这样的项目更好地落地,还是需要较为规范的项目管理方式的,其实这里和普通的业务项目没有太大的差别,技术方案评审,排期,接口文档等。
这里提到架构设计,不过说实话,一个系统刚开始的时候,很难给出完整的 C4 架构设计,这里提到的 C4 架构设计,更多是在项目迭代过程中,逐渐梳理细化出来的,用以向外同步信息和内部参考迭代。
另外,一个比较重要的点,是里程碑的分解和制定,基建项目通常体量不可控,如果一开始就设计了一个庞大的完整的方案,交付时间几个月,这时候就要想想里面是不是充满了不可控的风险,这几个月任何事情都可能发生,业务诉求、组织架构、人员变动,所以一定要把目标分解里程碑,每个里程碑有个阶段的产出,注意这里的里程碑不是把一个长的任务直接切开几份变成短的任务,而是每个里程碑你交付的可能都是一个最小可用的整体,早期尽快成型,后期迭代优化增加新特性,要养成分解达成的习惯,而不是一蹴而就。
技术运营也是基建的一个逃不开的比较磨人的话题,特别是对于大一点的团队来说,基建的落地是需要自己去主动推动推广的,对基建的输出的要求不是做个库做个框架这么简单,而是输出一个产品,你需要准备资料,讲清楚来龙去脉,讲清楚你的理解,讲清楚你的优势,建清楚如何使用,形式可能各种各样,文档当然是必备的,白皮书也是需要的(文档更多是介绍如何使用,白皮书是告诉别人为啥要用),分享是基本的但不一定是有效的,工作坊是更有效但是成本较高的,需要自己平衡和探索。另外就是技术运营要是持续性的,而不是一次了事,事不关己高高挂起爱用不用。
下图里我们给团队的产品甚至都订做了文化衫,去强化大家对基建产品的了解
通过刚才讲的一些内容,我们简单总结一下。
要做好基建,较为核心的点:
另外,一些细节的注意点:
不要给自己和别人挖坑
但是也要适当造轮子
注重系统思维
切忌半途而废
克服孤独感
最后,大家有问题,可以加我微信探讨,或者在行上约我面聊,感谢大家。
第三期 2020.3.28 在线上直播,主题 「前端搞搭建」,扫码关注「前端早早聊」公众号参与报名: