vue项目重构概述
- 框架结构vue-cli2改为vue-cli3
- 抽离cli service层
- 插件化
- 快速原型开发
- 现代模式兼容性更强
- 机场版代码重构
- 重新封装axios请求方式,调用接口代码缩减。
- 通用组件标准化(上传组件统一、表单宽高、按钮、字体、字号、弹框宽高等等)
- 组件化(组件的命名、变量的释义、引用方法等)
- Mqtt重新弄一下(连接逻辑、跟proto相关底层逻辑重构等)
- 公共css样式库(颜色、边距、行内等等相关)
- 统一命名方式 弃用驼峰(参考标准)
- 输出
- 流程图文档
- 代码结构说明文档、机场版代码说明文档(包含命名释义、组件释义、方法释义等)
- 快速入手、迭代开发手册
- 机场飞行一整套开放第三方(尝试)
为什么要写文档(引用)?
- 你将会在 6 个月后使用你的代码
我发现一开始从利己的角度来解释这个问题会比较有吸引力。写文档最好的理由就是你将会在 6 个月后使用你的代码。你 6 个月前写的代码跟别人写的代码对你来说通常没有什么区别。你将会带着一种熟悉的感觉读你的代码。然后一种不良的预兆悄悄逼近,你发现写代码的人毫无经验,毫无智慧。
当你读完几个月前很简单易懂或者取巧的代码之后,你就会开始同情你的用户。只要我写下为什么我要这么做,生活就会变得如此简单。文档能让你记录代码为什么这样写的原因。同样地,代码注释解释了为什么,而不是怎么做,文档也是这样。
- 你想要别人使用你的代码
你已经写了一段代码,并且发布了它。你这样做是因为你认为别人可能觉得它有用。但是,人们需要先知道为什么你的代码对他们可能有用,才会决定使用它。文档可以告诉人们这个项目对他们有用。
如果人们不知道你项目存在的意义,他们不会使用它。
- 最终目的:
- 性能提升
- 代码规范化
- 结构清晰化
- 组件化、模块化
- 易读性、复用性、更强悍
- 快速迭代、快速开发、快速入门
- 文档命名格式标准:
- Css命名
- 全小写中横线方式 弃用驼峰
- 函数命名、变量命名
- 驼峰
- 组件命名
- 驼峰格式 MyComponent.vue 注意:首字母大写
- 基础组件例如:Icon.vue 改写成BaseIcon.vue 加特定前缀
- 单一父组件中子组件, 在父组件文件夹中新建子组件文件夹,并子组件命名前缀以父组件名称作为前缀。
- 公共组件命名 采用首字母大写驼峰
- Css命名
-
- Js文件命名 首字母大写驼峰
- v-on事件监听器命名
- 中横线
- Css公共样式库命名
- Scss
- Css文件名必须使用小写字母
- 选择器必须用全部小写类名 多个单词用中横线
- 图片命名
- 全部采用 组件名(对应组件的命名)-图片名称-数量(多个);例如 组件test.vue中顶部背景图png格式,即 test-name.png 若多个即 test-topbg-1.png
- 文件目录存放标准:
- 图片存放地址 src/assets/images,禁止额外建立文件夹。
- 公共js统一存放 src/assets/js文件夹中。
- 公共css文件 统一存放src/assets/css 文件夹中。
- 静态资源,不被打包所影响统一放在public文件夹下面,和vue-cli2中static一样
- utils文件夹存放工具类js
- 待定
- 琐碎重要细项
- 缩进Tab设置两空格标准
- Axios封装(多种请求方式)
- 自动切换环境(开发、测试、正式)
- Vuex封装
- SessionStorage 存储
- 防止重复点击 节流防抖
- 定时器创建和销毁(查查)
- 权限系统
- 打包更新代码避免缓存配置(时间戳形式)
- 等
- 注释标准
- 组件顶部的描述
- 接口参数的释义
- 函数方法的用途
- 文档内容模块标准
- 组件名目录
- 组件内部变量释义、解释、用途等
- 子组件引用方法、参数等
- 组件快速生成markdown文档
- 函数引用方法
- 业务逻辑的判定条件简化(详细)
- 标准规范(markdown)
- 目录:项目结构名作为目录
- 顶部:组件中包含的功能
- 中部:点击顶部包含功能的具体解释,例如用到的代码、组件,根据代码中参数的释义、判定的条件、引用的组件或控件解释(内部控件加链接跳转)、难以理解的部分代码直接copy代码块加解释
- 安装依赖、解决方案等目录进行解释
- 流程图(细致流程、运用组件等等)
- 目录:项目结构名作为目录
- 业务逻辑流程图等。
- 严格把控代码审查、文档编辑
- 独立部署文档独立出来,增加文档版本号。