尽管写了多年的代码,但是始终有一件事不敢确定,就是自己的代码究竟写得好不好?这个问题很难有确切的答案,因为这个跟风格、规范有很大关系,而风格、规范很难说好还是不好。
但我觉得好的代码,一定是能让别人阅读起来有一种爽心悦目的感觉。
1. 开发规范
不管是团队协作还是个人独立开发,遵循一定的开发规范都是很有必要的。就团队协作来说,可能每个人的风格迥然不同,如果没有规范的约束的话,团队之间的协作会大打折扣的。而就个人独立开发来说,很难说一年后的你回头看今天自己写的代码是满意的。
js
开发规范
一般前端开发的主要工作都要 js
部分,所以一般前端开发规范都是对 js
而言的。
认可度比较高的有:
css
开发规范
认可度比较高的有:
2. 使用工具检查、自动矫正与优化
尽管有规范可循,但其实开发的时候并不知道自己的代码是否是符合规范的,所以就需要工具来检查与矫正代码。
2.1 检查与自动矫正
认可度比较高的有:
- eslint:检查 js 语法(包括 jsx 语法),然后最大程度的矫正不符合规范的代码;
- stylelint:检查 css 语法(包括 less, scss 语法),然后最大程度的矫正不符合规范的代码。
安装
目录文件
1 | |-- root/ // 项目根目录 |
package.json
1 | "scripts": { |
.eslintrc
1 | { |
.stylelintrc
1 | { |
运行命令
1 | npm run eslint // 检查项目中的 js(jsx) 语法 |
2.2 代码优化
eslint 与 stylelint 在对代码做检查和自动矫正时,只保证代码的语法是符合一定的规范,并不对代码的格式做任何优化,所以,自动矫正后的代码可能格式会不太好,阅读性不太高。
所以,一般会在对代码检查与自动矫正之后做代码格式优化。
使用比较多的:prettier.
安装
目录文件
1 | |-- root/ // 项目根目录 |
package.json
1 | "scripts": { |
.prettierrc
1 | { |
运行命令
1 | npm run prettier |
2.3 强制对代码进行检查、自动矫正与优化
尽管定好了规范与工具命令,但开发人员完全可以跳过这些步骤,这尤其是在团队开发中很难强制其他组员会去做代码检查、自动矫正与优化。
所以,使用工具强制开发人员对代码进行检查、自动矫正与优化,就显得很有必要了。
使用比较多的:
- husky:对 git 进行 hook,可以在 git 操作之前做一些操作;
- lint-staged:对当前 git 提交的代码进行一些操作。
package.json
1 | "scripts": { |
这样,在每次 git commit
之前,都会对将要提交的文件进行检查、自动矫正与优化,如果其中有一项发生错误,本次提交都会失败。然后开发人员调整代码之后再进行提交,只有每项任务都是没问题的,才能提交成功。
这样,便可使每个开发人员都是按照一定的规范与风格写代码的。
3. 编辑器配置:.editorconfig
有了规范,也加上了工具做自动化代码检查、矫正与优化,但还有一点需要提及一下,就是在团队协作中,每个开发人员可能使用的编辑器不一样,编辑器的配置也不一样,这就导致工具在做格式优化的时候,不同的开发人员中输出的代码不一样。
这就需要配置文件 .editorconfig
去统一每个开发人员的编辑器配置。
目录文件
1 | |-- root/ // 项目根目录 |
.editorconfig
1 | # http://editorconfig.org |
更多的编辑器配置规则,可以查看 http://editorconfig.org.
4. 业务逻辑优化
上面提到的这些只是风格、规范、语法上的优化,但对编码质量的评估更多的是在业务逻辑具体实现这一块。
一般来说,业务逻辑实现的优化离不开下面几个方向:
- 模块化:
- js 的模块化已经很成熟了,目前使用最多的是
commonjs
模块化规范和es6
模块; - css 的模块化也一直在探索中,之前也专门写了一篇 CSS 模块化,可以参考下;
- html 没有模块化,但是可以将一个很长的 html 文件进行分块,参考 html-loader。
- js 的模块化已经很成熟了,目前使用最多的是
- 组件化:当项目变大、变多,很多公共的代码需要复用或者跨项目使用的时候,组件化就变得很必要了,之前也专门写了一篇 组件化,可以参考下;
- 逻辑解耦:把一个复杂的逻辑,分割成多个子逻辑,然后将子逻辑串起来,或者把多个交叉逻辑的公共部分拆出来,然后再挨个串起来;
- 功能分块:细化一个一个的功能为单独的模块。
5. 逻辑解耦
逻辑解耦就是把一个复杂的逻辑,分割成多个子逻辑,或者把多个交叉逻辑的公共部分拆成单个逻辑。这样做的目的是降低应用的复杂度,更据阅读性。
比如,3 个串行的 ajax 请求,可以分割成多个子逻辑:
1 | $.getJSON(url1, data1, res1 => { |
逻辑解耦之后:
1 | const request1 = () => { |
再比如,在不同文件中需要依赖同一个 ajax 请求,可以把交叉逻辑的部分拆成单个逻辑:
1 | # file1.js |
逻辑解耦之后:
1 | # request.js |
6. 功能分块
细化功能为单独的模块也是提升代码质量的一个方式。
比如,将一个文件拆成多个文件(颗粒化):
1 | # util.js |
将功能分块之后:
1 | # util/func1.js |
再比如,将一个大功能块分割成多个小功能块:
1 | $.getJSON(url, data, res => { |
一般这种情况下,一个功能代码块就可能会很长,200 行都有可能,这个时候就需要将其分割成多个小代码块:
1 | const renderPages = res => { ... }; |
7. 多阅读
最后,也是最重要的,就是多阅读别人优秀的代码,阅读永远是获取知识最重要的途径,没有之一。