前端开发规范[项目工程篇]

项目工程篇]"/>

前端开发规范[项目工程篇]

项目工程规范

1. 文件命名规则

文件名称统一用小写的英文字母、数字和下划线的组合，其中不得包含汉字、空格和特殊字符；命名原则的指导思想一是使得你自己和工作组的每一个成员能够方便的理解每一个文件的意义，二是当我们在文件夹中使用“按名称排例”的命令时，同一种大类的文件能够排列在一起，以便我们查找、修改、替换、计算负载量等等操作。

• 命名规范：参考 Code Guide

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

• 模块化分组规范：参考 静态脱敏前端工程

• 文件大小约束

2. 文件注释

文件注释用于告诉不熟悉这段代码的读者这个文件中包含哪些东西。 应该提供文件的大体内容, 它的作者, 依赖关系和兼容性信息。如下:

    /***@功能说明*@作者*Copyright *******      */

3. 文件存放位置规范

以静态前端项目为例

|-- FE/                      # 应用主目录|-- dist                 # 前端发布打包生成的目录|-- logs                 # mock本地开发服务生成的日志目录|-- mock                 # mock本地开发目录|-- public               # 静态文件目录（打包时直接复制到dist目录下）|-- src/                 # 开发目录|-- assets/          # 主要存放一些静态图片资源的目录|-- ...|-- components/      # 这里存放的是开发需要的的各种组件，各个组件联系在一起组成一个完整的项目。|-- ...|-- filters/         # 项目过滤器目录|-- ...|-- lib/             # 项目公共类或函数目录|-- ...|-- plugins/         # 项目公共插件目录|-- ...|-- router/         # 项目路由目录|-- ...|-- styles/         # 项目样式目录|-- ...|-- views/          # 项目视图目录|-- ...|-- App.vue         # 是项目主组件，也是项目所有组件和路由的出口，之后它会被渲染到项目根目录的 index.html 中显示出来，我们可以在这里写一些适合全局的css样式。|-- main.js         # 入口文件，引入了vue模块和app.vue组件以及路由router，我们需要在全局使用的一些东西也可以定义在这里面。|-- babel.config        # ES6语法编译配置|-- .editorconfig       # 代码编写规格|-- .eslintignore       # 项目的根目录中创建文件来告诉ESLint忽略特定的文件和目录，该文件是纯文本文件|-- .eslintrc.js        # eslint的配置文件，eslint是用来管理和检测js代码风格的工具，可以和编辑器搭配使用，如vscode的eslint插件，当有不符合配置文件内容的代码出现就会报错或者警告|-- .gitignore          # 忽略的文件。|-- postcssrc.js        # 兼容选项（如果已经安装postcss，需要一大堆loader配置，这时项目根目录会生成“.postcssrc.js”文件）。|-- .browserslistrc     # 浏览器css兼容选项|-- package.json        # 项目及工具的依赖配置文件。|-- README.md           # 项目说明。|-- vue.config          # 项目构建的配置文件

本地开发完成后，把构建好的文件（dist）传到服务器相应的位置就好了。（构建的时候要处理好文件路径引用）。如果是集成到spring boot 中，请参考Vue项目部署到sping boot 方案

4 框架、工具规范

项目结构规范包括文件、目录命名规范，模块化分组规范，组件化规范等等，这些规范有些是构建工具要求的，有些是团队自己定的。
* 目录结构的统一化，可读性，分模块、组件构建，严禁构建杂乱无章，毫无可读性而言的项目目录。
* 了解开发当前项目所需的框架，工具、插件，功能，兼容性，分辨率等问题做好准备工作，做到心中有数。
* 目录结构整齐划一，方便日后的维护和其他同事的阅读。
* 在技术上，每个团队都有框架选型，都遵循一定的规范协作。基本上从团队搭建之初便需要定下今后团队的技术选型，并且最好不要更改选定好的框架和 UI 库，因为不同的框架、不同的 UI 库一般相互之间是不兼容的；同时用多个框架或 UI 库也是要尽量避免的。

框架

• jquery
• vue
• angularjs
• react
• …

UI 库

PC

• bootstrap
• element
• ant-design
• material-ui
• Semantic-ui
• …

Mobile

• mint-ui
• amazeui
• vux
• …

组合

• jquery + bootstrap
• vue + element
• angularjs + bootstrap
• …

构建工具

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

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

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

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

以 静态脱敏前端工程 构建工具为例，它的 工作空间 概念便很好的满足上述所有需求：

比如，demo 页的工作空间（/project/src/demo/），这个页面（或者组件）所有文件都在这个目录下等等。

• 开发的时候，都只在这个目录下工作，避免多级目录的不断切换（当工程很大的时候，这是个大问题）
• 当新添加一个页面或组件的时候，直接复制一个原有的页面或组件，这是极为方便的
• 解耦当然就不用说了，内部结构也是很清晰的
• 一目了然可以找到工程用到哪些公用的组件，样式，实例化数据等，防止多余的开发工作以及减少开发周期
• 方便后期的维护和其他成员使用

5. 后续

重要：每个项目根据产品的不同，选择该产品使用的项目框架或者搭建合适产品的框架，无论选择或者搭建框架，保证目录一目了然，哪个目录或者哪个文件做什么功能等，每个项目中都要有该项目的一些说明，发布流程，以及规范和约束（毕竟一个项目是多人参与，以便以后的拓展和维护）。

如果文档有更好的补充和好的建议，欢迎联系@博主

如有雷同，请联系@博主。

欢迎进入个人公众号 ，一起学习啊！