前端开发规范@H_777_2@

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

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

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

1. 开发规范分类

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

编码规范
项目结构规范
框架、工具规范
其他约定
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 行，超过就应该分块
...