前言
随着移动互联网技术的发展, 前端在整个项目体系建设中扮演的角色, 所处的位置也越来越重要. 越来越多的项目和系统, 对前端开发人员的技能要求也越来越高, 同时团队中前端工程师的人数的日益壮大, 每个人代码风格也不一样, 在协同开发和后续维护过程中, 可能会带来一些问题. 假如由你是该团队负责人, 或这说由你来负责前端代码管理, 你会怎么做?
自建 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 http://alloyteam.github.io/CodeGuide/
- Airbnb JavaScript Style Guide
代码检查校验 ESlint
在上一步中, 我们谈到了参照规范来编写代码, 可能有时候多多少少还是会忽略或忘记某些规范, 比如空格, 缩进, 变量引用命名等. 因此, 这里要引入 ESlint, 客观层面依照配置文件来检查我们的代码是否按照规范开发.
JavaScript 是一个动态的弱类型语言, 在开发中比较容易出错. 因为没有编译程序, 为了寻找 JavaScript 代码错误通常需要在执行过程中不断调试. 像 ESLint 这样的可以让程序员在编码的过程中发现问题而不是在执行的过程中. ESLint 的初衷是为了让程序员可以创建自己的检测规则. ESLint 的所有规则都被设计成可插入的. ESLint 的默认规则与其他的插件并没有什么区别, 规则本身和测试可以依赖于同样的模式. 为了便于人们使用, ESLint 内置了一些规则, 当然, 你可以在使用过程中自定义规则. SLint 使用 Node.JS 编写, 这样既可以有一个快速的运行环境的同时也便于安装.
ESlint 优点总结如下:
降低低级 bug(例如拼写问题) 出现的概率;
增加代码的可维护性, 可阅读性;
硬性统一代码风格, 团队协作起来时更轻松;
ESlint 推荐直接配置到脚手架之中, 对我们提高代码的可维护性的帮助会很大.
ESlint 中文网链接 https://cn.eslint.org/
代码美化 Prettier
Prettier, 顾名思义, pretty 的比较级, 可以强硬的翻译为'更漂亮的'. 那到底什么是 Prettier 呢? 从 Prettier 官网首页 https://prettier.io/ 能看到它是什么:
- 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 官网首页 https://prettier.io/ 的介绍.
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 有合并的趋势. 我们需要保持时刻关注. 学不动也得学.
来源: https://www.cnblogs.com/ldld/p/11143895.html