前言

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

自建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，客观层面依照配置文件来检查我们的代码是否按照规范开发。

JavaScript 是一个动态的弱类型语言，在开发中比较容易出错。因为没有编译程序，为了寻找 JavaScript 代码错误通常需要在执行过程中不断调试。像 ESLint 这样的可以让程序员在编码的过程中发现问题而不是在执行的过程中。 ESLint 的初衷是为了让程序员可以创建自己的检测规则。ESLint 的所有规则都被设计成可插入的。ESLint 的默认规则与其他的插件并没有什么区别，规则本身和测试可以依赖于同样的模式。为了便于人们使用，ESLint 内置了一些规则，当然，你可以在使用过程中自定义规则。 SLint 使用 Node.js 编写，这样既可以有一个快速的运行环境的同时也便于安装。

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 can prevent bad git commit, git push and more 🐶 woof!

整个是官方对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 有合并的趋势。我们需要保持时刻关注。学不动也得学。