我所理解的 Code Review

关于Code Review，之前也做过很多次了，但是总觉得做的不是很到位，最主要的体现就是大家并没能在实际应用中去改善或优化自己的代码。可能需求比较多，业务代码本身就繁琐，很容易随心所欲的去写代码，而如果花时间去看看自己的代码，并优化之前的代码，想必也是会有很大收货的！

当然，也不能说一步做到代码完美无瑕，这是不可能的，但是如果长期的积累一些经验，以后写的时候就会养成良好的习惯，代码质量自然也就上来了。

Code Review，我认为也是个慢慢积累经验的过程，一开始可以先从代码规范性入手，然后可能会从设计原则或设计模式的角度去深入，最后再以一个大局观的架构意识考虑代码的可维护性等问题，这样可能才会对没跟有更高的提升！

说到底，做这些代码规范或优化，不光是为了项目未来的可维护性等问题，更是为了个人能力的提升，团队协作能力的成长！

代码规范

‘’代码千万行，注释第一行。编程不规范，同事两行泪‘’，这句话虽然说得像是段子，但是事实确实是这样，每个人都有每个人的编程习惯，规范这种东西本来就很虚，也没有什么标准去衡量，那么我们究竟怎么去写好代码呢？

代码检测工具

随着前端近年来社区的蓬勃发展，这样的轮子也越来越多，而且配合这些工具编程基本上是业界的共同认可了。2017年时，很多开发人员就发现，一个好的代码编辑器，`eslint以及prettier`的组合能使写代码这件事更快，更轻松愉快，那么现在还不使用是不是显得落伍了？

先来一一介绍下这几个工具吧！

ESLint：检查代码语法规范性

这个工具相信每个开发者都不会陌生，使用ESLint能极大地帮助我们检测一些不必要的错误，合理地利用规则去制约代码的正确性，这是相当有必要的！

它的使用，主要有两中方式，一种是CLI命令去检查或修复代码错误，另一种则是根据配置文件去检测代码错误，下面主要讲一下配置文件的用法：

一般会在根目录下创建名叫.eslintrc的文件，这个文件中则主要是ESLint检查时依据的规则，介绍下主要的几个属性：

extends：字面意思上也知道它就是用来继承某些规则的

"extends": [
"eslint:recommended", // ESLint 推荐的一些规则（http://eslint.cn/docs/rules/）
"plugin:react/recommended", // `eslint-plugin-react`插件推荐的规则（https://github.com/yannickcr/eslint-plugin-react）
"airbnb" // 爱彼迎的`JS`代码风格（https://github.com/airbnb/javascript）
]

plugins：使用插件规则，可适当的使用eslint-plugin-import，eslint-plugin-jsx-a11y，eslint-plugin-react

rules：自定义的规则，rules中可以编写合适的规则，这里的规则也可以覆盖插件或继承的一些规则

"no-console": 0, // 0 或 off 是关闭规则
"no-unused-vars": "warn", // 1 或 warn 是开启警告
"newline-after-var": [2, "always"], // 2 或 error 是开启错误

以上只是对ESLint的简单介绍，其他相关配置或规则，自行查阅了解，最后就是使用中的一些问题解决：

使用中没有ESLint检查代码错误，在安装了VSCode插件前提下，一般都是没有安装项目依赖引起的，下载完项目代码后记得安装本地依赖，ESLint才能正常工作

出现ESLint错误该怎么解决，查找错误的规则名，然后在 ESLInt 规则中查找该规则的意图及解决方法，有的错误可能是插件引起的，则在相应的插件github官网中查找解决方法。

Prettier：代码美化工具

不得不说，这个代码美化工具能极大地格式化我们的不规范代码，使用时则配合VSCode插件利用快捷键Alt+Shift+F来格式化，当然它也有CLI命令和配置文件的使用方式，下面介绍下配置文件的部分属性：

{
  "printWidth": 120, // 每行最多120字符
  "tabWidth": 2, // 缩进为2个空格
  "useTabs": false, // 不使用 tab 缩进
  "semi": true, // 保留语句末尾分号
  "singleQuote": true, // 使用单引号 
  "trailingComma": "none", // 没有尾随逗号，比如对象或数组最后一项
  "bracketSpacing": true, // 对象中的括号之间打印空格，比如：{ a: 1 }
  "jsxBracketSameLine": false, // JSX标签闭合位置
  "arrowParens": "avoid", // 箭头函数参数括号， 尽可能不添加圆括号
  "requirePragma": false,
  "proseWrap": "preserve"
}

使用中的一些问题解决：

格式化不生效，如果正常安装了VSCode插件，很大原因上就是没有安装项目依赖，所以一定要记得安装项目的本地依赖

husky：代码提交预检查工具

有了这个工具，可以帮助我们在提交代码前做一些预检查，比如检查ESLint语法错误，格式化代码等，这样就避免了将错误或不规范的代码提交到代码线上。

"husky": {
    "hooks": {
    "pre-commit": "lint-staged"
  }
},
"lint-staged": {
    "*.@(js|jsx)": [
    "prettier --write", // 自动格式化修改过的代码
    "eslint --fix --quiet", // 修复`ESLint`错误，如有错误，将不能提交通过
    "git add"
  ]
}

这些自动化工具，是作为规范制约的一个首要前提，首先通过工具的检查，代码才有进一步优化可言！

命名规范

关于文件命名的规范前面也讨论过很多了，也基本上有了大致的统一，但是这里主要是想讲一下变量命名等规范，因为起名字是个很头疼的事，有时候想个合适的变量名真的挺不容易的！

我认为变量命名，最重要的就是见名知意，看到名字就能知道这变量的用途，这样也就不用写多余的注释去解释该变量含义。其次是简介性，有时候起的名字好多个单词拼接起来看起来真的很不雅观，所以在见名知意的基础上做到命名简介也是相当有必要的，文件夹或文件名也是同理。

注释规范

程序员最讨厌的四件事：写注释、写文档、别人不写注释、别人不写文档，相信每个人都深有体会。写注释也是有一些规范的，好的注释也能极大地提升代码阅读效率。

函数注释

对一些重要的函数写注释说明，不仅能帮助我们快速了解该函数的作用，在编辑器上还会有相应的代码提示和参数说明等。

/**
 * Adds two numbers.
 *
 * @since 3.4.0
 * @category Math
 * @param {number} augend The first number in an addition.
 * @param {number} addend The second number in an addition.
 * @returns {number} Returns the total.
 * @example
 *
 * add(6, 4)
 * // => 10
 */

一些特殊的注释技术

这些注释在有的编辑器或IDE上会有高亮提醒，看到这几个标识也能知道此注释的用途

// TODO：等待实现的功能
// FIXME：需要修正的功能
// XXX：需要改进的功能

shuangmianxiaoQ / study-note