分析前端业务团队如何进行技术建设
概述：业务同学忙于业务迭代，缺少时间进行技术钻研，往往有技术成长的诉求。本文将以团队视角，探讨业务团队如何进行技术建设。
# 背景
大部分中大型的互联网公司，会按照一个技术团队 + 多个业务团队的组织形式。技术团队负责技术基础建设，而业务部门更多的聚焦在业务迭代上。
这种组织形式有其优越性：
- 可以避免大量重复技术建设
- 减少上下文，降低沟通成本
在技术成长上，技术部门的同学拥有更多的时间进行技术钻研，往往能够得到快速的技术成长。
反观业务团队，快速的业务迭代已经占据了心力，对技术往往浅尝辄止，导致在技术成长上陷入瓶颈。
用一个同学的话来说就是：需求都做不完了，还有精力分析源码？😅
本文并非探讨部门孰优孰劣，仅以解决问题角度出发。业务部门同学能够更加深入地理解业务，拥有更广阔的业务视角。对技术部门的同学来说也是适用的：如果连业务都不了解，技术产出无法反哺业务，于公司有何用？
回到问题本身：业务同学忙于业务，如何获取技术成长？
理想的解决办法是：不加班，业务排期松，给予团队成员更充足的学习时间。但内卷时代，业务压力摆在那，为了个人成长而影响了业务的短期输出，老板的脸色可能也不太好看。（如果有哪个业务团队是这么做的，请联系hhh 😁）
单纯给予个人更多学习时间不可行，那团队是否可以采取一些手段，来实现业务和技术双赢、个人和团队共同成长呢？本文将以团队视角，对这个话题进行探讨 🚀。
# 如何进行技术建设
笔者认为可以从以下几方面入手
- 维护团队知识库
- 建设业务架构虚拟团队
- 高效地造有用的轮子
# 维护团队知识库
建设团队知识库，是团队进行技术建设的第一步。
大到团队规范、业务介绍、新人指南，小到需求纬度的技术预研、问题排查、总结复盘等，都可以往上放。
知识库的组织格式上没有规定，每个团队或项目组根据自己的习惯编排即可。
这里分享一个示例：
- 新人专区
- 新人指引
- 业务介绍
- 团队分享 # 方向上可以包含业务分享和技术分享
- 对内
- 对外 # 数据脱敏，补充更多上下文
- 团队规范
- 研发规范 # 包括代码规范、Git 协作规范等
- 上线规范 # 包括灰度上线环节，发版流程等
- 技术沉淀
- 事故复盘
- 问题排查
- 技术预研
- 总结规划
- ...
2
3
4
5
6
7
8
9
10
11
12
13
14
15
此外，团队知识库的重点不在于发起，而在于持续维护。
不断输出文档，于个人而言有助于提高思考总结能力，于团队而言有利于提高效率、培养技术氛围，实现共同成长。
# 谁能参与？
人人都能做，人人都应该做，但参与的顺序有所要求。
首先，应由 Leader 带头，按照团队自身的特点去组织文档库的结构，并邀请团队核心成员先输出范例文档。
正所谓人类的本质是模仿，在先有了一些优秀的文档沉淀之后，一些文档能力较差的成员也可以学习参考以至于更好的去输出文档。
# 何时进行？
伴随着业务迭代的生命周期，各个阶段都可进行文档沉淀。
- 前：技术预研、方案设计
- 中：问题排查
- 后：总结复盘、技术分享
大部分人往往是惰性的，最好有一定的奖励机制确保文档沉淀这件事。
# 打造业务架构虚拟团队
团队技术建设的第二步，即打造业务架构虚拟团队。
何为业务架构？每个人对业务架构的理解不同，笔者认为，将业务中所涉及的技术细节，基于效率和质量的目标进行组织和抽象，形成通用化场景和方案，即为业务架构。
那又为什么是虚拟团队？还是那个老问题，如果让单独一部分成员来负责业务架构，那么另一部分同学又会陷入技术成长的困境。
# 业务架构组织形式
业务架构的核心目标只有一个：帮助业务同学高效且高质量地完成需求开发。
基于这个目标，可以按场景和方案的形式组织业务架构：
- 方案：结合业务，针对效率和质量的具体解决方案，比如 SSR、CI/CD 等。
- 场景：针对特定场景，结合业务特点，整合解决方案，形成业务场景，比如中后台、跨端。
上图为一个示例，每个节点均为一个领域方向，由一至多个成员负责。具体拥有哪些领域，还是以各自团队的业务场景来定。
# 培养接口人
在有了业务架构的概念后，接下来就是培养各个领域的接口人。
培养标准：
- 根据团队成员兴趣偏好和技术深度来设置对应领域的接口人
- 尽量保证每个同学都能分配到一或多个领域（允许一个领域有多个接口人）
当团队同学遇到某个方向上的疑惑，找相关接口人了解即可，既减少了人力投入，又加强了团队交流。
举个例子 🌰 ：新同学要开发一个 h5 活动页，正常来说需要花一些时间做技术预研，比如离线化、动效选型、兼容性等等。而如果此时有「活动领域接口人」的话，那么直接寻求结论，再配合上一步说的「维护团队知识库」所输出的文档，直接省去了技术预研的人力。
# 工作开展
首先，笔者认为，每个业务团队都应该有自己的 Monorepo 技术仓库
Monorepo 和 Multirepo 的对比网上已有较多讨论，此处不过多介绍。
简单来说，Monorepo 的核心优势在于风格统一和开发提效。相比之下， Multirepo 每次都需要新建仓库、配置工程化、配置 CI/CD ，非常浪费人力，容易降低团队新人的建设积极性
另外，对于 Monorepo 的前期搭建，笔者认为，前面应该由团队中经验丰富的同学来做，避免新人在上手这块遇到太多问题而降低积极性，或者设计不规范导致维护成本高（🩸血泪教训）。
之后，将业务架构各个领域的技术产出和文档维护在仓库中，并通过 VuePress 等方案搭建文档站点方便阅读。
那么问题来了，技术产出是做什么？造轮子？接口人的主要工作又是什么？
笔者认为，接口人的工作主要分为两方面：
- 关注发展趋势，梳理技术文档，完成技术分享
- 高效地造有用的轮子
业务同学很难对所有方向都保持关注，而通过建立领域接口人的方式，有利于加强团队分享和交流，提升每个成员的技术广度。
高效地造有用的轮子，意思是说，不需要每个领域都造轮子，如果已有现成的比较好用的轮子，那就不要再造了；如果现成的轮子不好用，那也要考虑投入产出比，后面会细讲。
而如果评估下来无需造轮子，也得了解轮子的原理，知其然且知其所以然，方能成为领域专家。
# 高效地造有用的轮子
世界上本没有轮子，造的人多了，便处处是轮子
毫无疑问，造轮子是提升技术能力的最佳途径之一。其收益不仅仅在于轮子本身，更是能够让团队同学了解底层技术，体会工程化思想，提升技术积累。且当轮子足够知名时，还能提升个人和团队的影响力。
但随之而来的问题是，前端轮子已经非常多了，几乎开发中遇到的各个方向都有大量现成的轮子，那么是否还有必要继续造轮子？
先给出笔者的看法：
- 基于业务驱动的轮子可以造：有些轮子与业务紧密结合，比如 B 端的业务组件库等，没有可代替的轮子
- 基于技术驱动的轮子需要评估收益产出比：不能仅仅因为某个现成的轮子不好用，或者基于学习驱动，就去造轮子。
- 无论造什么轮子，都需要关注优先级
知乎上有个讨论可以看看：外界人总爱说程序员喜欢重复造轮子，对此你怎么看？ (opens new window)
总的来说需要关注「高效」和「有用」
# 可以从哪些地方入手？
业务架构的每个领域都可以入手，并基于不同驱动，投入人力的优先级也不同。
# 基于业务驱动
深入分析业务，总有场景可以抽象成公共模块，为业务提效。比如：
- 业务组件库：可复用的 UI 组件
- 业务工具库：业务 hooks、数据格式化、请求库、bridge 等等
- ...
# 基于技术驱动
相比业务驱动，技术驱动层面的轮子在公司内外基本有比较多的实现了。如果觉得现有的轮子不好用想再造一个，需要做好 ROI、优先级的评估。
依然以效率和质量领域入手，常见的轮子有：
- 效率
- 脚手架
- 联调工具
- CI/CD
- ...
- 质量
- 自动化测试
- 安全检测
- 监控报警
- ...
# 如何平衡造轮子的人力浪费
造轮子无可避免的会造成人力浪费，如何平衡才是关键。笔者认为可以从以下几点考虑
# 1 | 评估造轮子的 ROI
- 人力成本评估：造轮子所需的人力，是否可以在后续同学的使用中节约回来
- 易用性和性能收益评估：已有轮子无法完全满足需求，自建轮子能够提高多少易用性，对项目带来多少性能收益
举一个笔者业务上遇到的造轮子例子：业务 PC 站点的服务端渲染方案是自建的，而不用社区的 SSR 轮子。主要是考虑到几方面：
1. 易用性：项目长期维护，可以定制各种逻辑
2. 维护性：自己写的 SSR 代码遇到问题更容易排查，而使用社区轮子的话，对于上层不够透明
3. 团队成长：团队中的每个成员都可以接触这项技术的核心原理，有利于团队成员技术提升
2
3
# 2 | 评估优先级
评估通过，并非立即进行，应该和日常业务需求一样放入技术需求池，之后按照「紧急、重要」四象限来决定何时进行资源投入
# 做好团队技术建设，有什么用？
# 技术成长
回到最开始业务同学的技术焦虑问题。
笔者认为，在技术氛围较好的团队中个人的进步会更快，另一方面团队的技术积累也是由一个个成员们贡献出来的。
通过推动团队成员参与技术建设，可以解决焦虑问题。
# 团队影响力
简单来说，有利于招聘
现在招人难，招到合适的人更难。
一般来说，转岗或者应聘者很难了解业务部门的技术状态。而通过本文提到几个方向，可以增加业务部门曝光度，提升技术品牌认知，更容易招到志同道合的伙伴。
# 总结
本文简单探讨了前端业务团队如何进行技术建设的问题。以维护团队知识库为起点，打造业务架构虚拟团队，并高效地造有用的轮子。通过这些方向，推动团队成员进行技术产出，解决技术焦虑问题。
由于笔者经验不足，本文仅仅作为抛砖引玉，还望有所帮助，或探讨指正。