Unitimes

前言

本文更接近于探讨而非结论！！

临近年关，工作的第三年。去年随着身份的变换，不再思考于代码层，也开始思考如何提升团队的产出效率及产出质量、如何提升团队的开发水平、如何督促组员一起成长等。在这个过程不知不觉学习成长了许多，特记录下来一起探讨学习，也算是一个年终总结吧。

前端工作台

如图，为了提升产出效率，在前端我们进行了一些封装工具。为了统一管理这些工具的文档以及线上功能，我们基于AntDesignPro做了一个工具台（如下图）。

npm私有仓库

一开始，我们的组件库跟工具函数库我们是放在了公共社区，但其实随着工具函数跟组件库更多的跟业务逻辑挂钩，出于安全考虑，开源发布在公共社区不是很合适，于是就诞生了搭建私人npm的想法。基于社区活跃度，我们选择了verdaccio搭建私有库。

verdaccio

verdaccio的使用较为简单，在服务器上通过npm即可安装。

npm install –g verdaccio  // 安装verdaccio
复制代码

安装完成后如果没有特殊的配置需要设置，输入命令verdaccio即可运行，运行端口默认为4873：

服务器上运行完成后在本地修改npm源即可在私有仓库里执行包的发布以及下载。

npm set registry http://********:4873
复制代码

部署工具

部署工具在早期我也专门写过文章如何用node打造一款适合自己的部署工具，附上链接： juejin.cn/post/689895… 文章几乎将要写一款部署工具需要的插件包括在内。大家有兴趣可以自行查阅。

这里附加一些个人思考：部署工具越简单就越危险。特别是对于线上环境。我们需要时刻对线上环境怀有敬畏之心，所以部署工具个人更建议使用在测试环境当中。

团队脚手架

就目前而言，我们的技术选型主要集中于React+Ts生态。脚手架方面，我们分为了H5端以及Web端。对于这个脚手架除去一些必须的功能项（如：按需打包等），我们更多的希望这个脚手架能快速的组合我们需要的业务功能，例如：监控模块，菜单权限模块等等：

组件库

市面的组件库其实不少，我们也并不打算重复造轮子的工作。这个库更多的是基于我们业务功能封装的可复用组件。和工具函数库一样，组件库也会放在私有仓库。同时，将业务封装成组件更多的是为后面尝试页面定制化做准备。

工具函数库

工具库的内容会一直迭代变化，如何统一管理工具函数也曾困扰我们。我们最终决定采用node包一样的管理方式发布在搭配私有npm上，在工作台展示使用文档。

Request二次封装

我们对request的封装功能主要集中于：

加密封装
中间件添加token
请求错误抛出

加密

加密对于前端一直都是很有争议的点，但本着聊胜于无以及甲方巴巴强硬的要求。我们还是实现了一层加密。加密的方法主要还是混合加密，既：对称加密+非对称加密。

这里附上一篇非常不错的文章： mp.weixin.qq.com/s/i_Clg5kmT…

自动化测试

自动化测试是一直想尝试落地的东西，但作为小型团队，实在不可能会为一些简单的测试写测试脚本。但自动化测试在重构功能页面或开发复杂的页面时却又能达到奇效。

puppeteer

Puppeteer 是 Chrome 开发团队在 2017 年发布的一个 Node.js 包，用来模拟 Chrome 浏览器的运行。 Puppeteer的用途：

网页截图或者生成 PDF
爬取 SPA 或 SSR 网站
UI 自动化测试
创建一个最新的自动化测试环境，使用最新的 js 和最新的 Chrome 浏览器运行测试用例
测试 Chrome 扩展程序

总的来说，puppeteer通过启动Headless Chrome可以做到所有浏览器能做到的事。以下是一个测试Login登陆页面错误提示的脚本：

import puppeteer from 'puppeteer';

describe('Login', () => {
it('should login with failure', async () => {
  const browser = await puppeteer.launch();
  const page = await browser.newPage('');
  await page.goto('http://localhost:8000/user/login');
  await page.type('#userName', 'mockuser');
  await page.type('#password', 'wrong_password');
  await page.click('#subtmitBtn');
  await page.waitForSelector('.ant-alert-error'); // should display error
  await page.close();
  browser.close();
});
});

复制代码

以上脚本为测试当输入错误的账号信息时能正常响应错误提示。

其他

为了提高团队代码的可读性，我们还做了以下规范：

使用统一的eslint
统一文件结构以及命名规范
规定文件大小，函数大小，注释规范等。

小结

去年陆陆续续完成产出了些许提高团队效率的工具，但更多的都是基于开源社区的资源进行的二次封装。希望在往后能产出带有个人或团队标签的工具吧。

小型前端团队如何提高产出效率？

前言