背景

大部分中大型的互联网公司，会按照一个技术团队 + 多个业务团队的组织形式。技术团队负责技术基础建设，而业务部门更多的聚焦在业务迭代上。

这种组织形式有其优越性：

• 可以避免大量重复技术建设

• 减少上下文，降低沟通成本

在技术成长上，技术部门的同学拥有更多的时间进行技术钻研，往往能够得到快速的技术成长。

反观业务团队，快速的业务迭代已经占据了心力，对技术往往浅尝辄止，导致在技术成长上陷入瓶颈。

用一个同学的话来说就是：需求都做不完了，还有精力分析源码？😅

本文并非探讨部门孰优孰劣，仅以解决问题角度出发。业务部门同学能够更加深入地理解业务，拥有更广阔的业务视角。对技术部门的同学来说也是适用的：如果连业务都不了解，技术产出无法反哺业务，于公司有何用？

回到问题本身：业务同学忙于业务，如何获取技术成长？

理想的解决办法是：不加班，业务排期松，给予团队成员更充足的学习时间。但内卷时代，业务压力摆在那，为了个人成长而影响了业务的短期输出，老板的脸色可能也不太好看。（如果有哪个业务团队是这么做的，请联系 hhh 😁）

单纯给予个人更多学习时间不可行，那团队是否可以采取一些手段，来实现业务和技术双赢、个人和团队共同成长呢？本文将以团队视角，对这个话题进行探讨 🚀。

如何进行技术建设

笔者认为可以从以下几方面入手

• 维护团队知识库

• 建设业务架构虚拟团队

• 高效地造有用的轮子

维护团队知识库

建设团队知识库，是团队进行技术建设的第一步。

大到团队规范、业务介绍、新人指南，小到需求纬度的技术预研、问题排查、总结复盘等，都可以往上放。

知识库的组织格式上没有规定，每个团队或项目组根据自己的习惯编排即可。

这里分享一个示例：

- 新人专区
  - 新人指引
  - 业务介绍
- 团队分享 # 方向上可以包含业务分享和技术分享
  - 对内
  - 对外 # 数据脱敏，补充更多上下文
- 团队规范
  - 研发规范 # 包括代码规范、Git 协作规范等
  - 上线规范 # 包括灰度上线环节，发版流程等
- 技术沉淀
  - 事故复盘
  - 问题排查
  - 技术预研
  - 总结规划
- ... 

此外，团队知识库的重点不在于发起，而在于持续维护。

不断输出文档，于个人而言有助于提高思考总结能力，于团队而言有利于提高效率、培养技术氛围，实现共同成长。

谁能参与？

人人都能做，人人都应该做，但参与的顺序有所要求。

首先，应由 Leader 带头，按照团队自身的特点去组织文档库的结构，并邀请团队核心成员先输出范例文档。

正所谓人类的本质是模仿，在先有了一些优秀的文档沉淀之后，一些文档能力较差的成员也可以学习参考以至于更好的去输出文档。

何时进行？

伴随着业务迭代的生命周期，各个阶段都可进行文档沉淀。

• 前：技术预研、方案设计

• 中：问题排查

• 后：总结复盘、技术分享

大部分人往往是惰性的，最好有一定的奖励机制确保文档沉淀这件事。

打造业务架构虚拟团队

团队技术建设的第二步，即打造业务架构虚拟团队。

何为业务架构？每个人对业务架构的理解不同，笔者认为，将业务中所涉及的技术细节，基于效率和质量的目标进行组织和抽象，形成通用化场景和方案，即为业务架构。

那又为什么是虚拟团队？还是那个老问题，如果让单独一部分成员来负责业务架构，那么另一部分同学又会陷入技术成长的困境。

业务架构组织形式

业务架构的核心目标只有一个：帮助业务同学高效且高质量地完成需求开发。

基于这个目标，可以按场景和方案的形式组织业务架构：

• 方案：结合业务，针对效率和质量的具体解决方案，比如 SSR、CI/CD 等。

• 场景：针对特定场景，结合业务特点，整合解决方案，形成业务场景，比如中后台、跨端。

上图为一个示例，每个节点均为一个领域方向，由一至多个成员负责。具体拥有哪些领域，还是以各自团队的业务场景来定。

培养接口人

在有了业务架构的概念后，接下来就是培养各个领域的接口人。

培养标准：

• 根据团队成员兴趣偏好和技术深度来设置对应领域的接口人

• 尽量保证每个同学都能分配到一或多个领域（允许一个领域有多个接口人）

当团队同学遇到某个方向上的疑惑，找相关接口人了解即可，既减少了人力投入，又加强了团队交流。

举个例子 🌰 ：新同学要开发一个 h5 活动页，正常来说需要花一些时间做技术预研，比如离线化、动效选型、兼容性等等。而如果此时有「活动领域接口人」的话，那么直接寻求结论，再配合上一步说的「维护团队知识库」所输出的文档，直接省去了技术预研的人力。

工作开展

首先，笔者认为，每个业务团队都应该有自己的 Monorepo 技术仓库

Monorepo 和 Multirepo 的对比网上已有较多讨论，此处不过多介绍。

简单来说，Monorepo 的核心优势在于风格统一和开发提效。相比之下， Multirepo 每次都需要新建仓库、配置工程化、配置 CI/CD ，非常浪费人力，容易降低团队新人的建设积极性

另外，对于 Monorepo 的前期搭建，笔者认为，前面应该由团队中经验丰富的同学来做，避免新人在上手这块遇到太多问题而降低积极性，或者设计不规范导致维护成本高（🩸血泪教训）。

之后，将业务架构各个领域的技术产出和文档维护在仓库中，并通过 VuePress 等方案搭建文档站点方便阅读。

那么问题来了，技术产出是做什么？造轮子？接口人的主要工作又是什么？

笔者认为，接口人的工作主要分为两方面：

1. 关注发展趋势，梳理技术文档，完成技术分享

2. 高效地造有用的轮子

业务同学很难对所有方向都保持关注，而通过建立领域接口人的方式，有利于加强团队分享和交流，提升每个成员的技术广度。

高效地造有用的轮子，意思是说，不需要每个领域都造轮子，如果已有现成的比较好用的轮子，那就不要再造了；如果现成的轮子不好用，那也要考虑投入产出比，后面会细讲。

而如果评估下来无需造轮子，也得了解轮子的原理，知其然且知其所以然，方能成为领域专家。

高效地造有用的轮子

世界上本没有轮子，造的人多了，便处处是轮子

毫无疑问，造轮子是提升技术能力的最佳途径之一。其收益不仅仅在于轮子本身，更是能够让团队同学了解底层技术，体会工程化思想，提升技术积累。且当轮子足够知名时，还能提升个人和团队的影响力。

但随之而来的问题是，前端轮子已经非常多了，几乎开发中遇到的各个方向都有大量现成的轮子，那么是否还有必要继续造轮子？

先给出笔者的看法：

• 基于业务驱动的轮子可以造：有些轮子与业务紧密结合，比如 B 端的业务组件库等，没有可代替的轮子

• 基于技术驱动的轮子需要评估收益产出比：不能仅仅因为某个现成的轮子不好用，或者基于学习驱动，就去造轮子。

• 无论造什么轮子，都需要关注优先级

知乎上有个讨论可以看看：外界人总爱说程序员喜欢重复造轮子，对此你怎么看？https://www.zhihu.com/question/407370305

总的来说需要关注「高效」和「有用」

可以从哪些地方入手？

业务架构的每个领域都可以入手，并基于不同驱动，投入人力的优先级也不同。

基于业务驱动

深入分析业务，总有场景可以抽象成公共模块，为业务提效。比如：

• 业务组件库：可复用的 UI 组件

• 业务工具库：业务 hooks、数据格式化、请求库、bridge 等等

• …

基于技术驱动

相比业务驱动，技术驱动层面的轮子在公司内外基本有比较多的实现了。如果觉得现有的轮子不好用想再造一个，需要做好 ROI、优先级的评估。

依然以效率和质量领域入手，常见的轮子有：

• 效率

• 脚手架

• 联调工具

• CI/CD

• …

• 质量

• 自动化测试

• 安全检测

• 监控报警

• …

如何平衡造轮子的人力浪费

造轮子无可避免的会造成人力浪费，如何平衡才是关键。笔者认为可以从以下几点考虑

1 | 评估造轮子的 ROI

• 人力成本评估：造轮子所需的人力，是否可以在后续同学的使用中节约回来

• 易用性和性能收益评估：已有轮子无法完全满足需求，自建轮子能够提高多少易用性，对项目带来多少性能收益

举一个笔者业务上遇到的造轮子例子：业务 PC 站点的服务端渲染方案是自建的，而不用社区的 SSR 轮子。主要是考虑到几方面：

1. 易用性：项目长期维护，可以定制各种逻辑
2. 维护性：自己写的 SSR 代码遇到问题更容易排查，而使用社区轮子的话，对于上层不够透明
3. 团队成长：团队中的每个成员都可以接触这项技术的核心原理，有利于团队成员技术提升

2 | 评估优先级

评估通过，并非立即进行，应该和日常业务需求一样放入技术需求池，之后按照「紧急、重要」四象限来决定何时进行资源投入

做好团队技术建设，有什么用？

技术成长

回到最开始业务同学的技术焦虑问题。

笔者认为，在技术氛围较好的团队中个人的进步会更快，另一方面团队的技术积累也是由一个个成员们贡献出来的。

通过推动团队成员参与技术建设，可以解决焦虑问题。

团队影响力

简单来说，有利于招聘

现在招人难，招到合适的人更难。

一般来说，转岗或者应聘者很难了解业务部门的技术状态。而通过本文提到几个方向，可以增加业务部门曝光度，提升技术品牌认知，更容易招到志同道合的伙伴。

总结

本文简单探讨了前端业务团队如何进行技术建设的问题。以维护团队知识库为起点，打造业务架构虚拟团队，并高效地造有用的轮子。通过这些方向，推动团队成员进行技术产出，解决技术焦虑问题。

由于笔者经验不足，本文仅仅作为抛砖引玉，还望有所帮助，或探讨指正。