如何管理好你团队的前端代码

前言

随着移动互联网技术的发展，前端在整个项目体系建设中扮演的角色，所处的位置也越来越重要。越来越多的项目和系统，对前端开发人员的技能要求也越来越高，同时团队中前端工程师的人数的日益壮大，每个人代码风格也不一样，在协同开发和后续维护过程中，可能会带来一些问题。假如由你是该团队负责人，或这说由你来负责前端代码管理，你会怎么做？

自建Gitlab

代码就是公司资产。如何管理这笔资产就显得尤为重要了。自建gitlab是一个很基础，很有必要的。强烈建议使用Gitlab进行版本管理，自建Gitlab难度并不大，方便管理，包括代码管理、权限管理、提交日志查询，以及联动一些第三方插件。

可能有的公司还在用svn，或者IBM 提供的一些版本管理工具（RTC）。但还是不如gitlab用起来流畅。因此强烈建议Gitlab来代码管理。

制定代码开发规范 Code Guide

为什么要有团队代码规范？

虽然这些细节是小事，不会有体验或者性能上的优化，但是却体现了一个coder和团队的专业程度 团队的愿景：成为业界卓越的Web团队！所以不管团队有多少人，代码风格都应该师出同门！

以web前端为例，我们看看代码规范大概会包含哪些方面：

命名规则

• 项目命名
• 目录/文件夹命名
• JavaScript文件命名
• css（scss，less）文件命名
• html文件命名

HTML文件代码规范

• 语法（缩进，dom属性命名规范，单引号双引号的运用）
• lang属性
• 字符串编码
• IE兼容模式
• css引入方式
• JavaScript文件引入顺序
• 避免dom标签嵌套的层级过多

css 文件代码规范

• 缩进
• 分号
• 空格
• 换行
• 注释方案
• 命名
• 媒体查询
• 等等。。。

JavaScript 文件代码规范

• 缩进、空格、换行、注释。。。
• 变量命名
• 函数引用
• 数组对象
• ......其他

根据相关方案，制定好如上开发规范即可。这里强烈推荐腾讯的AlloyTeam团队的以及airbnb团队的javascript开发规范

Code Guide by @AlloyTeam

Airbnb JavaScript Style Guide

代码检查校验 ESlint

在上一步中，我们谈到了参照规范来编写代码，可能有时候多多少少还是会忽略或忘记某些规范，比如空格，缩进，变量引用命名等。因此，这里要引入ESlint，客观层面依照配置文件来检查我们的代码是否按照规范开发。

ESlint优点总结如下：

• 降低低级bug（例如拼写问题）出现的概率；
• 增加代码的可维护性，可阅读性；
• 硬性统一代码风格，团队协作起来时更轻松；

ESlint推荐直接配置到脚手架之中，对我们提高代码的可维护性的帮助会很大。

ESlint中文网链接

代码美化 Prettier

Prettier，顾名思义，pretty的比较级，可以强硬的翻译为‘更漂亮的’。那到底什么是Prettier呢？从Prettier官网首页能看到它是什么：

• An opinionated code formatter（一个有态度的代码格式化工具）
• Supports many languages（支持多种语言）
• Integrates with most editors（集成到绝大多数编辑器）
• Has few options（仅需极少的配置选择（其他代码格式化的工具配置选项太多了））

Prettier的安装和使用都及其简单:

// with yarn
yarn add prettier --dev --exact
# or globally
yarn global add prettier

// with npm
npm install --save-dev --save-exact prettier
# or globally
npm install --global prettier

使用起来也简单

prettier [opts] [filename ...]

prettier --check "src/**/*.js"

具体可以看看Prettier官网首页的介绍。

Pre-commit Hook工具之Husky

整个是官方对Husky整个工具的解释。也就是说在你提交代码前的插入一个钩子操作，执行整个操作通过后才可以提交代码，避免一些差的代码的提交。 因为很多时候，规范摆在那，不一定每个团队成员每次提交代码都会执行，因此在提交代码前插入一个操作（npm run xxx），这样也是客观层面对代码的保护。

现在比较主流的做法就是结合上一步中的prettier一起使用， 假设你已经通过npm/yarn安装来，那么看看如何使用

// package.json
{
"lint-staged": {
"**/*.{js,ts,tsx,json,jsx,less}": [
"node ./scripts/lint-prettier.js",
"git add"
],
"**/*.{js,jsx}": "npm run lint-staged:js",
"**/*.less": "stylelint --syntax less"
},
"husky": {
"hooks": {
"pre-commit": "npm run lint-staged",
"...": "..."
}
}
}

也就是说，在pre-commit之前，我们先执行

npm run lint-staged

lint-staged

• node ./scripts/lint-prettier.js
• git add

很显然，lint-prettier.js主要是读取prettier配置文件，检查相关规则文件是否有做美化处理。如果没有，就会给出相关提示：

// lint-prettier.js 部分代码

const isPrettier = prettier.check(input, withParserOptions);
if (!isPrettier) {
console.log(files);
console.log(
`\x1b[31m ${file} is no prettier, please use npm run prettier and git add !\x1b[0m`
);
didWarn = true;
}

因此，prettier + Husky 也强烈推荐运用到项目中。

Typecript

这也是老生常谈的话题了，作为JavaScript的超级，typescript优点如下：

TypeScript 增加了代码的可读性和可维护性

• 类型系统实际上是最好的文档，大部分的函数看看类型的定义就可以知道如何使用了
• 在编译阶段就发现大部分错误，这总比在运行时候出错好
• 增强了编辑器和 IDE 的功能，包括代码补全、接口提示、跳转到定义、重构等

举个简单的例子，假如我们代码规范都遵守了，eslint 检查也通过了，prettier也执行了。肉眼能做的都做了。在计算 1 + 1的时候还是会出问题。 因为你根本不知道，或者说不确定程序运行的时候1 是字符串还是数字。如果是两者为number类型，那么1 + 1 = 2。如果有一个是字符串，那么1+1 = ‘11’。

如果项目条件允许，趁早使用typescript。 当然在安装typescript的时候，注意要安装相应的检查插件：

// package.json

"tslint": "^5.10.0",
"tslint-config-prettier": "^1.10.0",
"tslint-react": "^3.6.0", // 如果你是react项目

vue2.x对typescript的支持不太友好，3.0版本后会逐渐改善。 而react则一直对typescript有着完美的结合。

UI单元测试

可能有人觉得，UI单元测试跟代码规范看起来似乎没多大关系。 但我始终坚持一点： 好的代码逻辑一定是可以写UI单元测试。如果拿到某个组件，写其相关的单元测试发现没法进行，或者案例没法覆盖全，那么这个组件写的是有问题。

也就是说，可写UI单元测试，是高质量的代码的一个体现之一。 我们在开发组件的时候，都知道要遵循 高内聚，低耦合的理念。你怎么客观衡量这个理念呢？还是得通过单元测试。

以react 为例，推荐Jest + Enzyme 来写单元测试。

jest

Jest是 Facebook 的一套开源的 JavaScript 测试框架， 它自动集成了断言、JSDom、覆盖率报告等开发者所需要的所有测试工具，是一款几乎零配置的测试框架。并且它对同样是 Facebook 的开源前端框架 React 的测试十分友好。

Enzyme

enzyme 来自 airbnb 公司，是一个用于 React 的 JavaScript 测试工具，方便你判断、操纵和历遍 React Components 输出。Enzyme 的 API 通过模仿 jQuery 的 API ，使得 DOM 操作和历遍很灵活、直观。Enzyme 兼容所有的主要测试运行器和判断库。

同样，能写单元测试的代码，后续维护、重构起来也会更加得心应手。

代码评审code review

与其说是代码评审，倒不如说是代码交流。不同的人对不同的功能首先有着不同的理解。相互交流，取长补短，促进进步。

一般建议以一个迭代，或者一个版本周期为间隔，有组织的做代码评审（分享）。

结语

本文主要总结了管理好前端代码需要注意的几个点：

• 搭建代码仓库
• 制定基本代码编写规范
• ESlint
• prettier + husky
• typecript + tslint
• UI单元测试
• 代码评审 code review

这里也是描述只是一个大的方向，没有具体实施细节。当前各种社区博客也会有比较详细的实施细节，告诉我们怎么引入ESlint/typecript等等。

同时，结合到具体项目中 ESlint 、prettier、typecript、等选择几个适合你们团队的方案，能全选当然最好。具体情况具体分析。好的代码就是好的资产，赏心悦目，便于维护。前端的发展日新月异，ESlint 和tslint 有合并的趋势。我们需要保持时刻关注。学不动也得学。