小公司-小前端团队，如何一步步走向成熟？
现状
去年下半年，加入了一家小公司，前端团队也是刚刚成立没多久，虽然自己心里上已经提前预设了团队可能存在的种种问题，但是，进入以后，还是发现了一系列比较明显的问题，这里列举其中一些典型问题：
- 前后端代码没有分离，发布上线等没有分离
- 前端技术栈单一，所有项目都是直接采用vue3-vben-admin
- 代码规范，commit规范等等没有统一，CI/CD流程不规范。
- 没有设计，产品等，导致整体开发流程不规范。
- ...其他
之所以，列举以上这些问题，并不是对我司有任何的不满啊，哈哈哈，更多的是希望能够给遇到类似问题的小伙伴儿一些方案或者方向，同时，也能够帮助大家的前端团队逐渐走向规范与成熟。
写作不易，如果这篇文章对您有所帮助，欢迎 关注♥️ + 点赞👍 鼓励一下作者，感恩～
成熟的前端团队是什么样子？
前端团队刚刚成立不久，如何一步步走向规范与成熟呢？很显然，我们需要知道一个成熟的前端团队是什么样子的（当然一般谈论这种话题，很有可能被喷），其实呢？没有一个明确的标准，而且公司业务不同，前端的技术栈，基建等都会不同，这里只是列举出了建设前端团队比较常见的一些方向供大家参考：
前端规范
这里，总结出了一些常见的规范，直接上图：
如果大家所在团队中，对这些规范没有进行统一，可以参考上面这些方向在团队中进行推广。
前端项目模版
大家肯定都知道vue，react的官方脚手架工具：vue-cli, create-react-app,通过这些基础脚手架，就可以帮助我们创建最基础的前端项目代码，但是随着业务的迭代，各个公司的业务场景不同，技术栈不同，往往需要在vue-cli, create-react-app创建的项目模版基础上，逐渐沉淀出符合公司的自定义项目模版代码，具体可以参考下图：
前端脚手架
上面，我们讲了前端项目模版，那如何更好的去管理模版呢？答案就是脚手架，加入没有脚手架，我们很可能是直接将模版代码放在一个单独的仓库中，每次开启一个新项目，就clone到本地，然后在copy一份出来，这样虽然也可以做，但是脚手架可以通过命令更好更快捷的帮助我们去管理项目模版，以及进行项目初始化等等操作。
当然，脚手架的技术栈和传统的前端项目的技术栈有所不同，上面图中也有说到，底层依赖Node，Lerna,Yargs等，感兴趣的可以学习一些，是否要维护公司自己的脚手架，就要评估人力成本，收益等，结合团队的实际情况进行考量了。
前端自动化构建部署（CI/CD）
这部分就是大家常说的CI/CD，即前端项目如何持续集成与部署，这里就不额外展开说啦，具体可以参考我自己写的一篇文章：基于Docker + Nginx + Gitlab-runner 构建前端CI/CD
有一点说明一下：可能早期，工作经验不多的前端小伙伴儿，会遇到这种情况，每次项目发布上线，可能都是直接使用公司现成的发布系统，直接在页面点点就可以成功，但是往往遇到问题的时候，就不太知道怎么去排查问题，还得请教运维等相关同学，遇到好交流的同事可能还帮你解决一下，遇到一些不友好的同事，你自己内心也会一万个....
因此，随着前端的不断发展，对于前端的要求也会越来越高，我们也有必要知道前端项目底层到底是如何进行CI/CD，如何去发布上线，这里就会涉及到Docker,K8s,Nginx,CI工具等技术栈，感兴趣的同学也可以去写一些demo，了解了解。
前端全链路监控体系
其实就是随着项目的迭代，功能越来越复杂，尤其是一些C端的项目，我们需要去掌握用户的行为，从而，根据用户的行为，去进一步更好的迭代我们的项目， 那么，这就需要我们对这些行为进行监控，也就是大家常说的埋点，
一个完整的监控体系，通常包含如下内容：
如果有的小伙伴儿所在团队有这样的需求，那么就要考虑如何去做啦，目前市场上也有一些开源的方案可以参考，例如：Sentry，当然，也要结合团队实际情况，看是否需要自己去实现一套完整的监控体系，因为实现成本也不低，尤其小公司，我们就需要调研调研，是否可以使用一些开源的方案去实现啦。
前端物料库
什么是前端物料？其实就是大家常说的组件库，工具库等可以复用的代码，具体可以参考下图：
一般大厂都会有类似的物料平台，那么，我们小公司呢？就要考虑其实现成本和收益啦，也不一定非要建立物料平台，因为小公司能够沉淀的物料也不会有那么多，比如：一般有沉淀一些组件库，工具库，我们也可以发布到npm上，这样团队内部也可以使用。
怎么做？
那具体怎么做呢？主要从以下几方面考虑：
- 明确要解决的问题：结合公司团队当前情况，按照优先级明确现有问题
- 明确要解决的问题的具体实现方案：通过调研，团队讨论等方式明确各个方案利弊，选择最优方案
- 明确具体的执行步骤：从团队实际情况出发，最好是渐进式开启，在对现有业务不影响的前提下做增量式基建工作
于是，我进一步结合我司的情况，明确了以下几点是要优先去实现的：
- 确定前端技术栈
- 明确前端规范
- 前后端代码分离，打造独立的前端CI/CD
确定前端技术栈
由于我司目前主要中后台项目居多，这里确认的技术栈也主要基于此方向展开的。
首先，传统的中后台项目，前端一般会包含以下这些内容：
那以上这些内容，如何实现呢？可以从三个方向展开：
- 自己团队手动封装，形成团队自己的一套最佳实践（其实就是结合公司业务场景，逐渐沉淀出一套初始化项目的项目模版）
- 借助社区开源方案：这里推荐：蚂蚁开源的UmiJS
简单来说，该框架就是以插件的形式集成了传统中后台解决方案常见的内容，例如常见的路由管理，权限管理等等，我们只需要引入相应的插件即可。 - 使用现成的开箱即用的中台前端解决方案框架，这里推荐以下几个框架：
- react的Ant Design Pro，
- Vue3的Vue3 Vben Admin，
- Vue2的vue-element-admin
那我司是如何选择的呢？历史项目使用了一部分Vue3 Vben Admin，新项目统一采用Ant Design Pro，
这里重点对比一下Vue-vben-admin和Ant design pro：
- Vue3 Vben Admin
- 优势
- 当前使用技术栈，且用了两到三年，积累了一定的经验，趟过了一些坑。
- 整体功能相对比较齐全，不需要从零开发。
- 劣势
- 本地版本迭代更新机制不太友好，需要开发者每次手动clone最新版本的模版仓库，然后还需要将原来的业务代码进行copy，而且如果对源码代码有更新的话，会更加麻烦，例如：一个组件，我们可能在项目中进行了二次修改，然后，我们更新vben版本的时候，作者很有可能也对该组件进行了代码更新，这个时候，就需要比对新旧组件代码，容易出现问题。
- 底层原因一：项目架构整体相对比较简单，没有采用monorepo架构，模版项目代码中封装的hook，组件等内容没有单独发npm包，没有版本管理。
- 底层原因二：封装的组件，自定义render能力有限，需要我们手动修改组件源码。
- 部分源码嵌套层级较深，新手上手成本较大，随着业务的迭代，源码和业务代码容易混淆，导致后期版本升级较难。
- 目前我们项目首屏渲染过慢（后期可能会成为一个比较明显的问题）
- Ant Design Pro
- 优势
- 整体社区生态更加完善，基于 umi + ant-design pro component，二次封装的组件等内容都有版本管理，作为开源项目，更利于开发者去通过npm包的形式去按需引入，同时提供了一下自定义入口，可以帮助我们二次开发。
- 劣势
- 新技术栈，初期需要一些学习成本，需要淌一些坑。
综合考虑了几点，团队计划采用 React + Umijs + And-design-pro 来作为目前复杂项目的核心技术栈，同时，一些简单项目，我们也可以直接使用creat-react-app脚手架去初始化项目，同时，一些官网，也采用了WordPress去快速建站（国外使用的较多）这样可以节省前端的开发成本。
前端中台解决方案 之 umijs + ant-design-pro 调研踩坑全记录
如果小伙伴对上面这些技术栈，尤其是React + Umijs + And-design-pro这一套有经验，也欢迎评论区分享，看有没有哪些问题或者坑可以避免。
明确前端规范
确认技术栈以后，接下来，就是要明确前端规范，保证团队开发统一，再次贴出之前总结的图：
这里，再把其中一些关键点说明一下：
- 编码规范：除了确认规范标准之后，在项目中还需要借助工具化：
Eslint + Prettier + Stylelint要确保项目中引入这些工具，并且进行有效检测。 - Git规范：常见两点就是：
Commit Message 规范以及Branch命名规范，这些也都可以借助工具：husky + lingstaged来进行约束。 - UI规范：对于一部分中后台项目，可能没有专门设计参与，这个时候就需要前端对于整个页面的设计交互有一个更好的认识和把握，推荐大家可以参考：Ant Design设计规范，里面列出了常见页面场景的交互规范，可以帮助我们更好的提升项目的用户体验。
前后端代码分离，打造独立的前端CI/CD
CI/CD这部分，通常也需要前端整体有一个认识和把握，这样可以帮助我们了解前端项目在整个集成部署过程中，内部的实现流程，也可以帮助我们更快的去定位问题，解决问题。
这里就不额外展开了，有类似需求的同学可以参考我之前总结的：# 基于Docker + Nginx + Gitlab-runner 构建前端CI/CD
文档建设
文档建设，其实也是必不可少的一个环节，包括我们上提到的这些前端规范，项目等内容，都可以逐步去沉淀到我们团队的文档中，随着内容的积累，沉淀的文档也会成为团队必不可缺的财富。
如果想推动团队进行文档建设的小伙伴儿，可以从以下几方面展开：
- 新人报到（VPN配置、项目启动）
- 规范类
- 流程规范：git分支、commit规范
- 编码规范：eslint、文件名、代码复杂度
- 项目类
- 需求文档
- 研发方案
- 项目总结
- 技术类
- 常见的技术分享
- 项目中的典型的技术点总结
总结
以上内容虽然相对基础，也很简单，但其实都是前端团队必不可少的，相信做完以上这些，我们的前端团队会变得更加规范和专业，当然，距离一个成熟的前端团队，大厂前端团队来说，我司的前端团队才刚刚起步，同时不同的团队，不同的业务，也会有不同的基建工作，这篇文档也会伴随着我司前端团队的成长去逐步的更新，相信会越来越好，前端不易，尤其这两年，前端已死，裁员，降薪等等负面消息在不断冲击着每一个程序猿，相信大家都可以熬过去的，祝大家越来越好。
写作不易，欢迎小伙伴儿们点赞收藏+关注，感恩。
参考文档
来源：juejin.cn/post/7221359467618517052
