前端规范
版本规范
- 主版本号：当你做了不兼容的 API 修改，
- 次版本号：当你做了向下兼容的功能性新增，
- 修订号：当你做了向下兼容的问题修正。
代码规范
变量
- 声明变量必须加上 let 关键字.不要再使用 var
- 优先使用箭头函数
- 使用模板字符串取代连接字符串
- 变量名，参数名，函数名方法使用camel（驼峰命名，首字母大写），常量使用全部大写加下划线的方式。
注释规范
- 如无必要，勿增注释 ( As short as possible )
- 如有必要，尽量详尽 ( As long as necessary )
目录结构
目录结构保持一致，使得多人合作容易理解与管理，提高工作效率 我就以我的个人习惯作为样例来说明。
简要说明
- main.js主入口，router.js路由划分
- plugins 自己或第三方插件,包括但不限于components、directives、filters、third lib
- pages 所有路由页面。原则：轻page，重component
- components 所有组件。包括原子组件、业务公用组件、页面独有组件
- server api引入入口
- static sass、图片资源入口，不常修改数据
- utils 工具文件夹
- store 标准vuex格式，非必须
-详细说明
└───src
│ │ app.vue // 主页面
│ │ main.js // 主入口
| | router.js // 所有路由
│ │
│ |____static // css、image、svg等资源
│ | |____css // 所有sass资源
| | | | reset.scss // 兼容各浏览器
| | | | global.scss // 全局css
| | | | variable.scss // sass变量和function等
│ | |____img // image图标库
| | |____svg // svg图标库
| |
| |____components // 组件
│ | |____common // common自注册组件
│ | |____base // 原子组件(如果是引入第三方，该文件夹可省略)
│ | | ... // 业务公用组件
│ | |____entity // entity页面组件
│ | |____about // about页面组件
| |
| |____pages // UI层(原则：轻page，重component)
| | |____entity
| | | | list.vue // 列表页
| | | | create.vue // 新增页
| | | | edit.vue // 修改页
| | | main.vue
| |
| |____plugins // 自己或第三方插件
| | | index.js // 插件入口文件
| | | directives.js // 所有Vue指令
| | | filters.js // 所有Vue过滤
| |
| |____api // 接口层
| | | index.js // 所有接口
| | | http.js // axios二次封装
| |
| |____store // vuex数据
| | | index.js
| |
| |____utils // 工具层
| | | config.js// 配置文件，包括常量配置
|
└───public // 公用文件，不经过webpack处理
│ │ favicon.ico
│ │ index.html
│ vue.config.js // vue-cli3主配置
│ babel.config.js// babel配置
│ .eslintrc.js // eslint配置
│ .prettierrc.js // perttier配置
│ package.json // npm配置
│ README.md // 项目说明
后端对接规范
返回约定
- 表格导出返回文件Url还是返回二制制文件流
- Boolean类型
- 关于Boolean类型，JSON数据传输中一律使用1/0来标示，1为是/True，0为否/False
- 日期格式 视业务情况而定（yyyy-mm-dd、时间戳）
- 货币金额
- 关于货币格式化，JSON数据传输中一律使用浮点数类型（后端不需要做格式转换） 前端统一处理，保留位数根据业务
- 数据为空约束，当某字段无状态，应明确默认值
联调前应该干的事
- 需求分析。参与者一般有前后端、测试、以及产品. 由产品主持，对需求进行宣贯，接受开发和测试的反馈，确保大家对需求有一致的认知
- 前后端开发讨论。讨论应用的一些开发设计，沟通技术点、难点、以及分工问题.
- 设计接口文档。可以由前后端一起设计；或者由后端设计、前端确认是否符合要求
- 并行开发。前后端并行开发，在这个阶段，前端可以先实现静态页面; 或者根据接口文档对接口进行Mock, 来模拟对接后端接口
- 在联调之前，要求后端做好接口测试
- 真实环境联调。前端将接口请求代理到后端服务，进行真实环境联调。
追加拓展
- 接口设计需要注意的点:
- 明确区分是正常还是异常, 严格遵循接口的异常原语. 上述接口形式都有明确的异常原语，比如JSONRPC，当出现异常时应该返回错误对象响应，而不是在正常的响应体中返回错误代码. 另外要规范化的错误码, HTTP响应码就是一个不错的学习对象
- 明确数据类型。很多后端写的接口都是string和number不分的，如果妥协的话、前端就需要针对这个属性做特殊处理，这也可能是潜在的bug
- 明确空值的意义。比如在做更新操作是，空值是表示重置，还是忽略更新？
- 响应避免冗余的嵌套。
- 接口版本化，保持向下兼容。就像我们上文的‘语义化版本规范’说的，对于后端来说，API就是公共的接口. 公共暴露的接口应该有一个版本号，来说明当前描述的接口做了什么变动，是否向下兼容。
- 现在前端代码可能会在客户端被缓存，例如小程序。如果后端做了break change，就会影响这部分用户。
