前端架构之路(3) - 前端开发规范

前端开发规范

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许可证)

你可能感兴趣的:(前端架构之路(3) - 前端开发规范)