项目的统一性

一.数据库的统一性，一个项目有很多模块，可以用前缀区分我找了一个项目举例：

 

 

 这个是部分表的截图，看出了问题所在，一部分是遵循模块化有前缀的，一部分是乱的，导致这个现象的出现应该就是多人协助开发，功能迭代过程中出现的，项目刚刚开始按模块开发大家比较遵守，后来人员的流动啊等等原因大家就放飞自我了，这个是小问题，其他的一致性其实安装阿里的java开发手册大家都遵守的话这些问题应该不会存在：

1.阿里的java开发手册中有这个规定，但是上面的截图中就有很多复数，不够统一。

 

 

 

2.这个就很少能做到了，尤其是关联表。

 

 

 3.备注，表的备注和表字段的备注又是后会缺失。下图就是有些表不知道是什么表，项目熟悉的人了解，新人接收会一脸懵逼。

 

 

 有时候表里d和is_deleted会没有注释，可能大家都知道这个是什么意思有人就想省略了，这个问题会在项目验收的时候爆发，本来直接导出需要的格式表名字段名注释都有了，现在导出了有些字段注释是缺失的就要手动补充，你说烦不烦。

4.统一使用enum类型，不要再使用1234代表什么了，不够明确，有可能有些业务有交叉可能用到相同的类型，这样程序里enum有可能用一个就行了。

二.基本的model生成要统一，即生成model的工具要统一：

 

 

  

 

 

 

 

 

 上述的三个表model应该三种工具生成的，不讨论他的性能如何，第一是不美观，第二他们的service，mybatis的使用也有可能不一样，这个有可能造成开发的不必要的模式切换浪费。

2.接口方法的共用（比如一个业务分成web端和h5端，有可能他们的业务不一样但是能用一个接口就用一个接口，是在不行才拆开），不要相同的业务多个接口（方法），项目开发初期这个需求变来变去，用到这个接口（方法）也要改来改去，你写了多个那改起来也是多份的，工作量就翻倍了，尤其是有些都上线了，怕修改导致出错不敢合并，后续的维护成本就非常的高。其实成熟的项目以前的轮子都造的差不多了，后续增加什么需求啊改动起来应该很流畅才对，如果不流畅就说明项目已经有些臃肿了，需要提取简化。

总结：上述都是粗浅的统一性讨论，都说印度程序员一个项目写的像一个人写的，印度的码农规范好。你甭管他写的算法怎么笨，但写的规范，比如变量名，注释，排版，文档。好处是，易于维护。其他人读起来不费劲。越是大工程，这一点越重要。我们也要做到基本的一致，与君共勉。