阿里巴巴Java开发手册———个人追加的见解和补充（一）

先上干货，《阿里巴巴Java开发手册》的下载地址

https://yq.aliyun.com/articles/69327?spm=5176.100239.blogcont69327.158.xUUgiz&p=2#comments

下面分几个部分对这个手册进行说明，都是个人的见解，本人技术一般，如果有错误或者不妥，请评论指出，虚心接受，提前感谢了。

建议边看手册，边食用以下说明，效果比较好。

前言

首先当我第一次看见这个的手册的时候或许和和你们是一样激动的，因为在java行业内我还没有看见有中文的规范，也可能是我读书少。总之，这是我见到的第一个中午的java规范。

首先还是要感谢阿里能给出这样一个规范，万事还是要怀有感恩的嘛，毕竟也是别人努力的结果。

首先没有规矩不成方圆，我觉得有了规矩，才能让大家的代码可读性和鲁棒性上面有所提高。而且规矩这东西是慢慢形成的，如果之后行业内的规范越来越相同的话那么互相交流也变的方便了不少。

然后要说明的是，规矩也是人定的，所以，不同的公司肯定有不同的代码规范，至少我所在的公司内部也渐渐的形成了自己的规范，我想说的是，并非我们一定要每一条都参考上面的手册（也并非不可以），有些还是要看具体情况的，但是至少阿里的实力摆在那里，所以有的规矩有它存在的道理。

其实我们要做的就是学习其中我们所不知道的，改掉我们那些坏习惯，保留我们的好习惯，那么这个手册的价值就大大的了，不是吗？

废话了这么多，我知道肯定也没有人会看的，下面赶紧上货，我会分章节总结手册中我认为重要和解释有些不太明确的地方，没有列举的，并非不重要，而是觉得手册已经写的很棒，我没啥好说的了。

编程规约

这次说的是第一章，因为我不想脱的太长，后面的我想慢慢整理，知识点还是很多的。所以这篇暂时只说明第一章的内容。

（一）命名规范

3、说明一下DO/BO/DTO/VO是什么

看到这条的时候我对命名到是没有疑问，但是很多人可能像我一样看到这四个缩写的时候有疑问。所以解释一下。

首先要说的是他们都有一个统称叫POJO。

DO Domain Object 领域对象：从现实世界抽象出来的业务实体。

BO Business Obejct 业务对象：面向业务建立的实体，包含多个PO或VO。

DTO Data Transfer Object 数据传输对象：展示层和服务层之间的数据传输建立的实体。

VO Value Object（还有叫View Object） 值对象：仅包含数据，不包含业务逻辑的对象，通常用于页面显示。

PO Persustan Object 持久对象：对应数据库的对象，与数据库字段一一对应。

在简单的项目中，或者当时在学习的时候，老师可能会不将实体分的很细，多数命名会直接采用末尾加POJO或者Entity或者Model等，一个类从数据库一直用到页面显示，确实简单，但是也危险。对于复杂的项目来说，对于实体来说其实分开很重要，举个最简单的例子，对于一个用户实体来说，密码不应该在查询的时候返回给用户，我们之前使用的可能是在数据库中查询的时候不查询出来，但是实际中需要建立一个TO对象等，根本就不包含密码这个字段。再举个例子，很多在数据库中表的字段有10多个，但是在页面中需要显示的只需要3个，多余的数据会导致传输速度下降，所以需要新建VO对象去进行页面显示，只取用需要的数据。

对于各个对象的定义参考来自：http://www.open-open.com/lib/view/open1450427478266.html

8、POJO布尔类型不要加is，这个是真的细节，本人遇到过boolean isSuccess的错误，千万不要这样命名，其实就是不要使用翻译软件直接去翻译或者直接想着中式英语去翻译你的变量就行了，规范一点就能避免很多错误。

15、DAO中，接口后缀Dao实现用Impl就不多说了，主要是这点对于方法的命名很重要。

A) Service/DAO 层方法命名规约

1） 获取单个对象的方法用 get 做前缀。

2） 获取多个对象的方法用 list 做前缀。

3） 获取统计值的方法用 count 做前缀。

4） 插入的方法用 save（推荐）或 insert 做前缀。

5） 删除的方法用 remove（推荐）或 delete 做前缀。

6） 修改的方法用 update 做前缀。

B) 领域模型命名规约

1） 数据对象：xxxDO，xxx 即为数据表名。

2） 数据传输对象：xxxDTO，xxx 为业务领域相关的名称。

3） 展示对象：xxxVO，xxx 一般为网页名称。

4） POJO 是 DO/DTO/BO/VO 的统称，禁止命名成 xxxPOJO。

首先为什么要使用前缀，因为我们的IDE都有自动识别你要的方法，当我们使用的时候很方便，方法前缀的统一，可以让多人开发的时候想要找别人写好的接口方法很容易。sava和remove我之前在github上面看见过，不知道是不是国外这么写的，insert和delete太数据库化了感觉。

这里还要补充一点的是，每个公司最好定义一下分页方法的规则，对于分页来说用到的很多，而且特别的命名让别人知道这个是分页的方法。有时还有特别的用处。

补充第二点，如果是系统的项目，后台管理系统和前台的系统方法最好分开命名，比如在方法中加入back，虽然代码量上去了，但是为了保证以后进行修改的时候，一旦修改后台要动到前台这种麻烦，还有就是，前台和后台查询的数据肯定是不同的，有些数据不应该显示的就不要查询出来。

（二）常量定义

这里主要总结一点，把常量进行区域范围管理，不要总是不动脑子的全部全局变量。

（三）格式规范

5、这里我使用的tab不喜欢空格，空格容易敲错。其他均同意。

10、关于空行，空行的使用是这样的，首先我们在写代码的时候，我习惯先写注释，然后用很多的空行把业务逻辑分块，这样出现的代码会是一块块的，这样容易识别，但是要注意的是，最后需要删除多余的空行，保留最需要的，利用注释去分块业务。

（四）OOP规约

6、不要使用Object的equals，使用常量调用equals

7、注意包装类的数值比较用equals（是不是很疑惑为什么要列这一条，而且这条你还从来不注意。看下一条！）

8、（这里的RPC可以理解为通信获取数据）

1） 所有的 POJO 类属性必须使用包装数据类型。

2） RPC 方法的返回值和参数必须使用包装数据类型。

3） 所有的局部变量【推荐】使用基本数据类型。

说实话，我看见这条的时候吓死了，因为我之前在实体类中使用的一直是int double，几乎没用过包装类。 但是更吓人的是阿里的反例说明正是我之前遇到的情况，而且我正是在这种情况下才使用的包装类，其他都没用过。真的是被吓死了。

这里给出我的意见，包装类的好处是可以有null，基本类型是必须有值的。

在页面显示的时候，有的数据其实查询的是null应该显示的是空白，而不是0，那么必须使用包装类，其他我真的找不到的其他的必要。所以要不要尊重这一条就看你们自己了。

9、之前已经我们公司已经有人试过了，设置实体类默认值会导致一系列问题，最后崩盘，所以千万不要中招。

12、POJO必须写toString，我这个人比较懒，所以没写过。（应该不止我一个人吧~害怕）因为大多数时间我都使用断点调试，并不需要输出数据进行调试，但是当一些日志调试的时候还真的需要使用，所以我之后会考虑加上的。同时如果你觉得没有必要，我也不反对。

16、不要在get和set方法中加入业务逻辑，注意这里指的是业务逻辑，如果是对数据的处理是没关系的，比如对于一些数据字段的拼接。

17、一句话，尽量使用StringBuilder，不要怕麻烦，内存不是用来给你浪费的。

18和20一起说，时时刻刻都要注意final关键字的使用，这个关键字其实我们很多时候都会忘记掉，我就是，除了全局变量，我还真的很少用，其实这里列举的很好，不需要重新赋值，不允许修改引用的指向，不允许被重写，都要使用final，会避免很多问题，真的。变量的控制永远从严，我觉得举的例子特别形象，就在下面列一下。

20. 【推荐】类成员与方法访问控制从严：

1） 如果不允许外部直接通过 new 来创建对象，那么构造方法必须是 private。

2） 工具类不允许有 public 或 default 构造方法。

3） 类非 static 成员变量并且与子类共享，必须是 protected。

4） 类非 static 成员变量并且仅在本类使用，必须是 private。

5） 类 static 成员变量如果仅在本类使用，必须是 private。

6） 若是 static 成员变量，必须考虑是否为 final。

7） 类成员方法只供类内部调用，必须是 private。

8） 类成员方法只对继承类公开，那么限制为 protected。

说明：任何类、方法、参数、变量，严控访问范围。过宽泛的访问范围，不利于模块解耦。思 考：如果是一个 private 的方法，想删除就删除，可是一个 public 的 Service 方法，或者一 个 public 的成员变量，删除一下，不得手心冒点汗吗？变量像自己的小孩，尽量在自己的视 线内，变量作用域太大，如果无限制的到处跑，那么你会担心的。

（五）集合处理

2、这个点我遇到过，参考我之前写的博客，比较好理解的。

http://www.cnblogs.com/linkstar/p/5710116.html

7、foreach中不要进行remove和add

11、这张表格是重点（考试是重点，记一下咯）

（六）并发处理

对于并发，本人经验不足，而且在下载地址的最底下的评论，你们可以看见，有人对其中一些产生了质疑，我暂时真的在实际中运用过，所以等有经验我在告诉你们，虽然我知道很重要，但我也很无奈啊（滑稽脸）

（七）控制语句

3、多使用if+return，你们懂的。我们老师有一句经典的话，尽早退出能更好选择对的人。

7和8一起说：很多人都在编程中纠结这个问题，我到底判不判断这个参数对不对空不空啊，判的太多，性能就下去了，判的太少，那么容易出问题。

这里我给出我的建议，首先你大可不比去记手册上面说的，情况，我觉得有点多，我给出我自己的方法，你们看着接住。

1、循环调用，尽可能不判，性能太低，或者判断之前就应该解决掉。

2、dao不判，接触数据库，这种底层是不会出错的，否则就是你代码有问题，上层再去判断。

3、私有不判，这个参数上面刚用过，不可能是空的，要错上面早就之前这个参数早就错了，所以不判。

4、如果不确定，先判再删，不判不知道会不会出错，那么就判，判最多就是效率低，但是不会出错，优化性能的时候在考虑要不要把判断的语句删除即可。

5、我们只记住不需要判断的情况剩下的都是要判的。

（八）注释规范

对于注释就总结一下：

对于注释的要求：第一、能够准确反应设计思想和代码逻辑；第二、能够描述业务含 义，使别的程序员能够迅速了解到代码背后的信息。完全没有注释的大段代码对于阅读者形同
天书，注释是给自己看的，即使隔很长时间，也能清晰理解当时的思路；注释也是给继任者看 的，使其能够快速接替自己的工作。 好的命名、代码结构是自解释的，注释力求精简准确、表达到位。避免出现注释的 一个极端：过多过滥的注释，代码的逻辑一旦修改，修改注释是相当大的负担。

特殊标记：TODO我们经常用，FIXME还没开发或者有错误，///////吃饭之前我刚写到这（别小看这个注释，救了很多人的），//-----业务逻辑….（利用这个分离还没写的业务逻辑），OTHER需要调用别人的接口（开发的时候并接口都是你自己写的，有可能别人还没写好，注释一下自己就不会忘记，或者自己写多了。），当然你们可以规定你们自己的。这些是我常用的。

（九）其他

3、这个点我保留怀疑态度，我觉的有的业务下面是允许空的，所以不应该为强制。

4、使用 Random 对象的 nextInt 或者 nextLong 方法获取整数随机数。

以上就是我需要整理出来的点，如果有什么地方说的不对的，谦虚求评论，我马上改正。

你们需要的就拿走不要的就留下就行咯。