为什么需要规范？
- 提高代码整体的可读性、可维护性、可复用性和可靠性，从根本上降低开发成本
- 保证代码的一致性，提高代码的开发效率
- 尽早发现问题，甚至预防问题
- 减少code review的争议
案例:
规范的重要性
- 约束代码，提高可维护性。想象一下，马路上面没有交通规则，会是什么场景，程序开发也是一样，没有规范开发就会受阻，后续的需求难以继续。
- 降本增效，提高开发效率。规范的存在往往会避免很多不必要的bug，也会给测试减轻压力，为需求的按时上线提供保证。
- 提高团队整体编码能力，营造良好的氛围。相信任何一个程序员都不想看到一个没有规范、逻辑混乱的项目，这也是有些团队留不住人的原因。
开发者需要建立和遵守的规范
- 开发流程规范
- 代码规范
- git commit规范
- 项目文件结构规范
- UI设计规范
开发流程规范：
很多时候，开发人员在拿到一个需求往往都是先考虑如何去实现，而忽略了需求要解决的痛点和场景，对于不合理的需求缺乏判断力。有些需求所需要的开发成本是很大的，或者需求本身就是不合理的，开发人员应该有驳回的权。
需要强调的是，编写自测用例及测试这个环节是非常重要的，因为很多错误都可以通过自测发现，不会进入bug流程，可以为开发和测试节省不少时间。
代码格式化工具配置
推荐prettier
1.安装依赖
2.配置文件
创建一个[.prettiergnore](https://)文件
3.编辑器配置
5.自定义其他规范
- 命名规范
- 变量命名
- 变量命名应该尽量采用小驼峰, 语义明确
- 例：
- 常量命名
- 采用全大写+下划线连接
- 例：
- class类名
- 小写单词 + 下划线连接
- 例：
- 函数命名
- 写注释
- 文件注释 快速定位要修改的位置
@file 文件用途
@descript 文件大概描述
@author 创建人
@date 创建日期
src\utils\index.js文件顶部注释
- 函数注释 方便使用，最好一眼就可以看出功能参数返回值
1.description 功能描述
2.params {参数类型} 参数名
3.返回值 {返回值类型} 返回的参数名。没有可以省略，但是类型要标注
4.author 函数创建人 用的时候不懂可以直接找对应的人问
5.date 更新时间 可以知道是否还在维护
vscode插件： Document This
鼠标右键，点击扩展设置可以自己配置参数
- 业务难点注释
- 业务代码的函数可以单行注释，但是
一些奇怪的操作，比如：
业务代码尽量多一些注释，因为改动的可能性会比较大
- 变量注释
一些魔数要做好注释，否则维护起来很浪费时间
- html注释
- 较长的的HTML文件，请在板块之间加入注释，使得结构更清晰：
- 变量兜底
请求回来的数据一定要最好变量兜底，不要因为后端的数据错误导致前端报错，不该自己背的锅不要自己背。
数据不能太相信后端，尽量能给默认值就给，尽量try。。。。catch，保证代码的健壮
- 常量抽离
写一些表单的时候经常会用到一些下拉框选项列表、配置项等，尽量把这些东西都抽离出一个单独的文件放在对应的组件下面，后期维护起来也方便，业务组件里面的代码看起来也会清爽很多。
引入之后可以使用Object.freeze()冻结一下常量
书写业务代码需要注意的点：
1.修改样式的时候一定要加scope，否则可能造成样式污染
**2.业务代码最佳长度在200-300行之间，能抽离成组件的尽量抽离，增加可阅读性。 **
**3.禁止大段代码复制，尤其是整个文件复制，然后就该一两行的那种，比如上面的实例。 **
导致的结果就是修改bug的时候很难考虑周全，永远不知道同样的bug还会在哪里出现
4.尽量按常理出牌，代码的书写要符合阅读习惯
vue官方的规范文档：
腾讯公开的规范：[tgideas.qq.com/doc/index.h…](https://)
代码合入规范
一个合并记录里面只能有一条commit记录
例：
目的：保证每个功能模块的合入记录清晰，出现问题也比较容易定为是哪一个功能开发的时候出现的问题
如果已经有了多条commit记录可以使用git rebase将多条合并成一条
教程：[blog.csdn.net/qq_33588730…](https://)
如果是只提交了一次，后续还需要提交，可以在后续提交的时候可以加参数：git commit --amend
单个合并记录修改的文件不应该超过15个
目的：避免修改不相关的文件，正常情况不会涉及这么多文件。另一方面也是为了代码review方便
确实需要超过15个可以分两次合入
提了合并请求要关注是否有冲突
有冲突要及时解决然后重新推送。即解决完了之后使用git push -f 覆盖之前的推送
合并信息中应该包含：
1.本次提交的功能点
2.可能会影响哪些功能模块
3.做了哪些自测
冲突处理
以feat-personl合入dev分支为例：
- 切换到dev分支拉去最新代码 git checkout dev git pull
- 切回自己的分支 git checkout feat-personl
- 变基，把代码的基点提升到最新的dev分支git rebase dev,这里会有vscode会自动帮我们合并冲突，合并不了的需要手动合并，处理好了之后重新git add，然后根据提示重新执行git rebase --continue
- 强推，覆盖之前的推送。git push -f
- 刷新合并请求即可看到没有冲突了
单个文件代码长度尽量不要超过500行
为了出现问题好定为，如果一个文件一两千行代码，找起来会相当麻烦，而且里面的逻辑绝对是混在一起的没有做拆分。而且在代码review的时候审核人也会头疼。
当一个业务文件代码超过500行的时候可以看看是否能进行模块化。
git规范
优点：适合协同开发，每个模块的开发不会相互影响，避免了都在dev分支开发，导致动了别人的代码，也保证了dev分支的稳定。而且就算开发分支出现问题，测试分支不收影响，不会阻塞测试
main分支：用于上线生产环境的代码，要保证安全，不可随意改动
stage分支：用于上线测试环境的代码，主要是供测试人员使用，用于bug修改
dev_x.x: 用于开发环境可以流畅运行的代码，供开发人员拉取
feat-ljl-demo: 个人开发分支的代码，从dev_x.x拉取，开发完了合入dev_x.x
**开发阶段： **
从dev_1.0建立自己的个人分支进行开发，开发完成之后合入dev_1.0。尽量做到一个模块一个分支，合入之后删除。
等到所有人都开发完成，组长把dev_1.0分支合入stage，进入测试阶段
**测试阶段： **
组长再从stage分支拉一个分支bug-fixed出来用于bug修复。
这个时候如果哪位同事有bug，就可以从bug-fixed分支拉一个个人bug修复分支，比如：lejl-bugFixed-bug编号
修改完了之后一定要先合入bug-fixed分支，再合入stage分支，保证bug-fixed分支合stage分支同步。
统一基础脚手架
目前采用的基本上都是若依的前后端分离的框架，这个框架的优点在于权限模块，很多常用的工具都有，上手比较块，可以快速搭建出一个后台管理系统。但是缺点也很明显，封装的过于死板，开发时需要考虑兼容性。
建议：
前期：可以在若依的基础上进行改进，保存为公司的统一脚手架
后期：自己开发出一套公司专属的后台基础框架
统一常用业务组件库
尽量把常用的业务模块封装成组件，实现风格统一，开发配置化，避免代码冗余，提高可读性
例如：
列表的查询、分页
总结
前端的规范化要实现起来并不容易，因为要改变的是这么多年的开发习惯，前期必然会造成开发效率的降低，但是从长远来看，bug率会下降、代码走读时间会缩短、同事之间的沟通也会降低，后期开发效率会大大提升。当然，这需要一个蜕变的过程，不是一个月两个月就可以实现的，也需要各个同事之间的配合。
