前言
下面是阿里对《阿里巴巴 Java 开发手册》（下称《手册》）的介绍：
凝聚了阿里集团很多同学的知识智慧和经验，这些经验甚至是用血淋淋的故障换来的，希望前车之鉴，后车之师，能够帮助更多的开发者少踩坑，杜绝踩重复的坑。
在知乎上，也有关于这本开发手册的讨论十分热烈的帖子：https://www.zhihu.com/question/55642203。
其中一位网友的话让楼主觉得十分有趣，现贴出来博大家一笑：
在楼主看来，阿里巴巴的这本Java开发手册，可谓包罗万象，几乎日常Java开发中方方面面都有所涉及。
由于里面涉及的内容比较多，下面重点罗列下一些楼主读过之后十分赞同与持保留意见的条目：
（一）编码规范
（一）命名规约
8. 【强制】POJO 类中布尔类型的变量，都不要加 is 前缀，否则部分框架解析会引起序列化错误。
反例： 定义为基本数据类型 Boolean isDeleted 的属性，它的方法也是 isDeleted()， RPC框架在反向解析的时候， “误以为” 对应的属性名称是 deleted，导致属性获取不到，进而抛出异常。
看法：此条级别为强制，不过是有特殊的应用场景的，boolean类型变量加上is前缀无可厚非。举例来说，对于处理状态标志，我觉得isProcessed/processed/processFlag/processStatus，这四种写法都是很OK的。不过我个人可能更偏好用processed，比较简洁。当然此条目被列举在开发手册中，也是前人踩坑的教训，吸收一下挺好。
10. 【强制】杜绝完全不规范的缩写，避免望文不知义。
反例: AbstractClass“缩写”命名成 AbsClass;condition“缩写”命名成 condi，此类 随意缩写严重降低了代码的可阅读性。
看法：非常赞同，时常在公司项目代码中看到不能一眼看出含义的拼音或者英文缩写比如cashFlow缩写为CF，代码可读性降低很多。Java代码不要害怕变量名或者方法名过长，除非你能找到一个比原先短，并且含义完全相同的更好的命名。
15.【参考】枚举类名建议带上 Enum 后缀，枚举成员名称需要全大写，单词间用下划线隔开。
说明： 枚举其实就是特殊的类， 域成员均为常量， 且构造方法被默认强制是私有。
正例： 枚举名字为 ProcessStatusEnum 的成员名称： SUCCESS / UNKNOWN_REASON。
看法：级别被列为参考，代表此条目推荐程度不是太高。我的看法也是如此，其实枚举类命名后缀什么type啦，status都可以啊。
（二）常量定义
3. 【推荐】不要使用一个常量类维护所有常量， 要按常量功能进行归类，分开维护。
说明： 大而全的常量类， 杂乱无章， 使用查找功能才能定位到修改的常量，不利于理解和维护。
正例： 缓存相关常量放在类 CacheConsts 下； 系统配置相关常量放在类 ConfigConsts 下。
看法：挺好的规范，对于大型项目，按照业务功能/模块常量类分开维护还是很有必要的。
（三）格式规约
12.【推荐】 不同逻辑、不同语义、不同业务的代码之间插入一个空行分隔开来以提升可读性。
说明： 任何情形， 没有必要插入多个空行进行隔开。
看法：在方法内部，逻辑上互相较为独立的代码块之间加入一个空行，会看起来更为清楚。但是也不要太极端，每行代码之间都插入空行，显得反而看起来空洞。
（四）OOP规约
9. 【强制】定义 DO/DTO/VO 等 POJO 类时，不要设定任何属性默认值。
反例： POJO 类的 gmtCreate 默认值为 new Date()， 但是这个属性在数据提取时并没有置入具体值，在更新其它字段时又附带更新了此字段，导致创建时间被修改成当前时间。
看法：非常赞同。曾经遇到一个bug，按条件筛选数据集怎么也查不出来，后来发现是实体类中一些字段被加入了默认值，导致查询的时候带上了这些莫名增加的筛选字段。
（五）集合处理
10. 【推荐】集合初始化时， 指定集合初始值大小。
说明： HashMap 使用 HashMap(int initialCapacity) 初始化。
正例：initialCapacity = (需要存储的元素个数 / 负载因子) + 1。注意负载因子（即 loaderfactor） 默认为 0.75， 如果暂时无法确定初始值大小，请设置为 16（即默认值） 。
反例： HashMap 需要放置 1024 个元素， 由于没有设置容量初始大小，随着元素不断增加，容量 7 次*扩大， resize 需要重建 hash 表，严重影响性能。
看法：非常赞同，在确定集合中元素个数的情况下，最好new的时候就指定好大小，这样不仅可以减少空间开销，也可以避免内存碎片的产生。