前端：开发规范

前端开发规范

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 行，超过就应该分块...