阿里巴巴Java开发手册与自己开发对照笔记

一编程规约

（一）命名风格

某些时候在命名常量的时候，会觉得太长而减少长度导致命名不清。

抽象类及测试类写得比较少。

这一点值得注意，在开发中，布尔变量我都是使用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映射

很多时候为了方便习惯直接使用集合类做为返回类型。

一般情况下都是使用#{},某些特殊情况下也只能使用${}