项目规范思考

一、项目中的命名

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、核心业务逻辑，需要统一（较复杂的补充流程图、时序图）