一编程规约
（一）命名风格
某些时候在命名常量的时候，会觉得太长而减少长度导致命名不清。
抽象类及测试类写得比较少。
这一点值得注意，在开发中，布尔变量我都是使用is开始。
关于包名和类名的单数和复数形式，主要集中在util这里，有时候傻傻分不清楚。看到公司很多项目的帮助类包名都为com.xxx.utils.
有时候嫌变量太长，会搞一些缩写。
开发中不会在接口里定义变量。但会在接口的方法里访问修饰符，公司很多代码接口里都有访问修饰符。
领域模型命名命名基本上没有按照阿里巴巴的规约，当然阿里巴巴也注明了这只是参考，而不是强制。与数据库打交道的数据对象，多半在com.xxx.model包下，命名比较随意，没有加上DO后辍。
一个WEB工程的数据类通常分为三大类：
持久类 包括与数据每张表完全对应的实体类（属性与表字段一一对应），包括实体接收查询结果类（属性与表字段部份对应，比如只需要一个表的部份字段，比如多表联合查询，将多张表的字段组合成一个实体类，以便于接收查询结果）。统一以DO结尾。
响应类 以DTO结尾。如果是JSP可能会直接传回一个实体对象，如果是AJAX的话，直接会加一个json数组。
业务类 比如纯粹传参，包括从控制类传到业务类，控制类接受前端参数类等。比如临时数据传输类，包括从数据库中得到一个列表，需要二次排序，使用一个实体来中间转换。 统一以VO结尾。
（二）常量定义
有时候一个值只在代码中出现1次，会偷懒不去定义变量。
这个问题偶尔会犯。
开发中常量会是一个类，但是里面会根据业务分成许多内部类。
（三）代码格式
这个平时开发中不会出现这种情况，但没有形成严格的禁令。
这个值得注意，开发中确实在犯这种错误。
关于开发中一行代码过长的换行，一般比较随意，比如缩进
sb.appeng("zi").appeng("xin")...
.append("huang")...//为了美观，多半以对齐换行，没有以四个字符换行
而且并于什么时候换行，是以120个为临界点，但有时候是以当前编辑器显示大小来权衡，并没有严格执行。
这个没有形成禁令，有时候能做到，有时候忘记。
（三）OOP规约
这点做得不是很好。
对Integer类型，我都会使用intValue来进行比较。
1),2)没有问题，3）并没有注意。不过这也只是推荐。
这块做得不好。
这条只是推荐。
这条也只是推荐。但是自己在开发过程中对于修饰符的使用相对比较随意。值得思考 。
（七）控制语句
刚开始写Java时有炫技的心态，喜欢这样写，后来就不会了。不过scala表示不服。
开发中会这样去做，但也要权衡具体情况。
这一点也要权衡具体情况吧，”复杂的语句“，怎样才算是复杂呢？
（八）注释规约
方法，类基本都能做到，但类属性上有时候做得不好。确实，在别处调用时，如果看不到注释会非常不方便。同理，常量类，枚举等也应该使用/***/注释，而不是//.
二异常日志
（二）日志规约
五MySQL数据库
（一）建表规约
一是字段命名，一是数据类型
数据库表字段名使用驼峰命名。
对于一些表习惯使用联合主表，摒弃自增主键。
（二）索引规约
通过只在需要通过索引执行查询，使用insert into on dumpcate key update语法时才会去创建唯一索引。可以使用唯一索引做一些数据校验。
前辍索引的缺点是不能进行group by 和order by.
对于mysql来说，limit是个好东西。前提是表数据量在千万级以内，一旦超过这个值，性能急剧下降。很多时候，都要想到这一点。
所有SQL语句都应该使用explain看下执行结果，进行优化。
（四）ORM映射
很多时候为了方便习惯直接使用集合类做为返回类型。
一般情况下都是使用#{},某些特殊情况下也只能使用${}