项目规范思考
一、项目中的命名
1、项目名称统一
2、关键文件名称统一
3、关键类名统一
4、关键类中的变量名及API统一
二、项目中的结构
1、系统架构统一
三层架构、四层架构等
2、目录结构统一
3、模块中架构模式统一
mvc、mvvm、mvp....
比如：一个Demo根据业务可能使用多种架构模式，某一种业务，移动端某块功能都用mvc开发
4、设计模式统一
单例模式、工厂模式、代理模式等
比如：一个Demo可能有多种业务，每种业务的设计模式需统一，某个管理类都使用单例模式开发
三、核心业务流程
核心业务逻辑，需要统一（较复杂的补充流程图、时序图）
1、核心业务流程图
2、核心业务时序图
四、代码规范
1、为什么需要规范
代码规范也是代码风格，每个人都有自己的编码习惯，如果这个习惯不统一约定，项目多人接手后会造成混乱，不利于维护。所以需要约定统一风格。代码是给人看的，其次才是给机器执行。规范决定质量，质量依赖规范，代码写规范了，质量也就提上去了。
2、开发规约
3、代码提交
代码提交要干净，只提交开发程序运行必须的代码
不能提交的：
- 无关注释（注释掉的代码）
- 没用到的函数调用
- 没用到的无关变量
4、代码评审
- 涉及的旧代码
- 旧代码不规范（历史原因），在空闲时、做需求或者改bug的时候涉及到的代码需要修改
- 评审人数
- 若前期问题比较多，建议前期3-4人参加评审，形成统一规范后再由1~2人评审
- 评审人：
- 端之间的相互review，指定人review
5、代码合入
- 指定分支合入的代码必现先review
- 评审人全部通过才能合并代码到指定分支
五、参考资料
2、其他
一些常用的代码规范总结，代码规范以 规约 为主要依据，在写代码的时候多思考一下
- 命名
- 1、命名的长度选择
- 2、利用上下文简化命名
- 3、命名要可读、可搜索
- 4、如何命名接口
- 注释
- 1、注释到底该写什么
- 2、注释是不是越多越好
- 代码风格
- 1、函数多大才合适
- 2、一行代码多长最合适
- 3、善用空行分割单元块
- 编程技巧
- 1、把代码分割成更小的单元块
- 2、避免函数或方法参数过多
- 3、勿用函数参数来控制逻辑
- 4、函数设计要职责单一
- 5、移除过深的嵌套层次
- 6、学会使用解释性变量
后期完成
1、代码风格，参考代码规约
2、命名规定（项目名、文件名、类名、变量名）商量统一
3、项目目录结构、系统架构（三层架构、四层架构等），项目架构模式(mvc、mvvm等)统一，设计模式（单例模式、工厂模式等）统一。
例如项目架构图
一个Demo根据业务可能使用多种架构模式，某一种业务，比如移动端某块功能都用mvc开发；
也会用到多重设计模式，单例、代理、工厂等，比如rtc管理类都使用单例模式开发
还要考虑移动端和pc端的差异性，至少移动端之间需要统一
4、核心业务逻辑，需要统一（较复杂的补充流程图、时序图）
