前端开发规范

1. 为什么需要 “前端开发规范”

规范不是强制性的，对代码的编写和程序的运行不会有致命的问题，但是没有规范会有一系列的问题，比如：

• 缺乏规范，第一个问题就是团队编码风格不一，增加了成员之间代码的阅读成本，加大了团队协作成本和维护成本；
• 随着团队人员的变化（多人开发一个应用，或者应用更换开发人员），如果缺乏规范，项目可能会变得一团糟，甚至失控；
• 即便是个人开发，规范也是需要的，当把项目转给其他人的时候，如果有规范的话，会大大降低阅读成本。
• ...

所以，建立一套适合团队的开发规范是很受用的。

2. 开发规范分类

这里不涉及工作流程规范，因为每个团队的工作流程都不一样，这是跟公司相关的，与开发没有太大关系。一般来说，有以下几类规范：

• 编码规范
• 项目结构规范
• 框架、工具规范
• 其他约定

2.1 编码规范

• html: 主要有缩进，标签，加载顺序等等。可以参考：

  • Code Guide

• css：主要有缩进，换行，引号，注释等等。可以参考：

  • idiomatic-css

• js：主要有缩进，换行，变量名称，括号，文档注释等等。可以参考：

  • airbnb js style
  • google js style
  • idiomatic js style
  • standard js style

其实，我一般参考的是 Code Guide

2.2 项目结构规范

项目结构规范包括文件、目录命名规范，模块化分组规范，组件化规范等等，这些规范有些是构建工具要求的，有些是团队自己定的。

以下是一些示例：

• 命名规范：参考 Code Guide

  • 全部采用小写方式， 以下划线分隔。例：my_project_name
  • 完整英文命名的用复数形式，缩写用单数形式。例：scripts, js, styles, css, images, img

• 模块化分组规范：以 lila 构建工具为例

  • /project/src/home/: home 页的工作空间（以下所有文件或目录都在这个目录下）
  • index.html: html 入口文件
  • index.js: js 入口文件
  • index.(css|less|scss): 样式入口文件
  • js/: js 文件目录
    • js/ajax/: 对 ajax 封装的目录
    • js/util/: 工具类函数的目录
    • js/pages/: spa 应用页面目录
    • js/data/: 静态数据目录
    • js/tpl/: 模板目录
    • js/(event|view)/: 事件监听文件目录
    • ...
  • data/: 本地 json 数据模拟
  • (css|less|scss)/: 样式文件目录
  • images/: 图片文件目录
  • components/: 组件目录（如果基于 react, vue 等组件化框架）
  • ...

• 组件化规范：这里的组件化并不是指在代码、框架层面的组件化，而是在架构和规范层面的组件化

  • /project/src/component/hello/: hello 组件的工作空间（以下所有文件或目录都在这个目录下）
  • README.md: 组件的说明，包括功能介绍、api 文档、一些用例等等
  • index.js: 组件的入口文件，调用组件将使用如下的方式（如果有样式文件，则要在 js 中加载）
    • commonjs: const hello = require('component/hello')
    • es6: import hello from 'component/hello'
  • demo/：用例目录
  • ...

2.3 框架、工具规范

框架和 UI 库

• 在技术上，每个团队都有框架选型，都遵循一定的规范协作。基本上从团队搭建之初便需要定下今后团队的技术选型，并且最好不要更改选定好的框架和 UI 库，因为不同的框架、不同的 UI 库一般相互之间是不兼容的；同时用多个框架或 UI 库也是要尽量避免的；
• 框架选型：经典的 jquery + bootstrap，比较现代化的 react + ant-design|material-ui|Semantic-UI （因为我主要是以 react 为组件库做开发，所以对 vue 的技术选型不是很了解，>_<）

构建工具

构建工具的使用使开发变得极为便利和高效，工具在提升工作效率的同时，也同时提供了约束团队编码规范、项目结构规范等的可能性。

• eslint：一个语法规则和代码风格的检查工具，可以用来保证写出语法正确、风格统一的代码。
• stylelint：一个强大和现代的 CSS 审查工具，有助于开发者推行统一的代码规范，避免样式错误。
• csslint：与 stylelint 类似

约束项目结构规范需要团队讨论来定，但基本上需要满足以下几个需求：

• 便利性：能够快速的定位文件位置，对编辑器友好
• 解耦性：不同页面之间，不同组件之间是相互解耦的，不会更改一个组件或页面而影响到其他组件或页面
• 扩展性：能够很方便的扩展组件和页面，而不会带来副作用
• 阅读性：具有很好的阅读性，对组件、页面以及内部结构能够一目了然

以 lila 构建工具为例，它的 工作空间 概念便很好的满足上述所有需求：

比如，home 页的工作空间（/project/src/home/），这个页面（或者组件）所有文件都在这个目录下，包括 js、css、html片段、图片、json模拟数据等等。

• 开发的时候，都只在这个目录下工作，避免多级目录的不断切换（当工程很大的时候，这是个大问题）
• 当新添加一个页面或组件的时候，直接复制一个原有的页面或组件，这是极为方便的
• 解耦当然就不用说了，内部结构也是很清晰的

2.4 其他约定

如：

• 每个 js 文件不应该超过 400 行，超过就应该分块
• 每个 css 文件不应该超过 200 行，超过就应该分块
• ...

3. 后续

上一篇：本地化接口模拟、前后端并行开发

下一篇：前端开发文档

更多博客，查看 https://github.com/senntyou/blogs

作者：深予之 (@senntyou)

版权声明：自由转载-非商用-非衍生-保持署名（创意共享3.0许可证）