近日，从网上下载了阿里云栖社区发布的《阿里巴巴Java开发手册（正式版）》v1.1.0版。从编程以来，一直苦于没有相关的、全面的、靠谱的规范可以参考，有了这手册，日后编程也算是找到了依据。瞧，人家阿里都是按照这规则来操作的！

云栖社区此举对于普通Java开发者来说，算是功德无量，在一定程度上规范了Java开发者的编程习惯。为后来者谋福利了。

　　这本手册一共分为五个部分，包括了编程规约、异常日志、MySQL规约、工程规约、安全规约。基本上从编码的各个方面都细细的理了一遍，感觉完全可以当做是公司招人的面试题，用来考较对方的编码习惯，甚至也能在一定程度上能推断出对方的编码水平，毕竟高的编码水平，其编码习惯肯定不会差到哪去。

手册的内容约束分为三种级别，分别为强制、推荐、参考。强制，即必须遵从的编码规范；推荐，则表示最好遵从该规范，有利于提高代码水平；参考，则表示需要了解即可。

花了一个上午，仔细地将这篇手册阅读了一番，结果只看了编程规约这部分，从中摘录了一些规约，我觉得日后在编码过程中需要注意及提升的地方。

命名规约

              【强制】抽象类命名使用 Abstract 或 Base 开头； 异常类命名使用 Exception 结尾； 测试类命名以它要测试的类的名称开始，以 Test 结尾。                点评：一直以来对于命名都比较随意，尤其是面对很长的类名及方法名时都会自己进行单词简化，时间久了，连自己都会忘记这个缩写到底是个什么意思，o(╯□╰)o。另外，这些类名的命名规则也能遵守，只是这些标识词语总是有时放开头有时放结尾，缺少些统一性。        【强制】 POJO 类中布尔类型的变量，都不要加 is，否则部分框架解析会引起序列化错误。                 点评：可能因为开发的项目少，使用的框架不够丰富，这个问题倒是从来没遇到过。当然也基本上没这么写过。        【参考】各层命名规约：

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。 

点评：因为公司人来人往的缘故，对方法的命名从来都是自己按照自己的那套玩。就我个人习惯而言，只要是获取对象全部都是get做前缀，阿里的这种做法的确可以用来参考参考。

OOP规约

                 【强制】 POJO 类必须写 toString 方法。使用 IDE 的中工具： source> generate toString时，如果继承了另一个 POJO 类，注意在前面加一下 super.toString。

说明： 在方法执行抛出异常时，可以直接调用 POJO 的 toString()方法打印其属性值，便于排查问题。

         点评：这个提议非常好。如其所言，有利于排查问题。          【强制】泛型通配符<? extends T>来接收返回的数据，此写法的泛型集合不能使用 add 方法， 而<? super T>不能使用 get 方法，做为接口调用赋值时易出错。

说明： 扩展说一下 PECS(Producer Extends Consumer Super)原则： 1） 频繁往外读取内容的，适合用上界 Extends。 2） 经常往里插入的，适合用下界 Super。

         点评：泛型经常用。但是，泛型通配符却基本上没怎么用过。看了一下PECS原则，很有意思。如果熟练掌握的话，可以在某些特定场景中提升代码的质量。             【强制】不要在 foreach 循环里进行元素的 remove/add 操作。 remove 元素请使用 Iterator方式，如果并发操作，需要对 Iterator 对象加锁。           点评：这个问题我在开发中遇到过。不过，在处理这个问题时有些笨拙。对于并发操作，我使用的是并发队列ConcurrentLinkedQueue。