【小家java】《阿里巴巴 Java开发手册》读后感---团队协作效率提升的保证
每篇一句
无规矩不成方圆 无规范不能协作
拥抱规范，远离伤害
前言
对于编码规范，本人一直是公司里的大力推崇者。其实不乏发现有很多人并不注重编码的规范性，觉得只要功能实现了就ok了，其实这种认识是非常初级的。
了解了规范，可以提前避免一些开发盲区，大大提高团队协作的效率。规范的编程习惯，更能提升我们coder的职业素养，向代码致敬
一个成熟的项目要想长足发展（其实我还没看过什么项目只考虑work几个月就够了的），后期维护成本是设计者不得不做长远设计和考虑的
阿里巴巴作为国内Java行业的领头羊，各个领域都具有极高的发言权和权威。2017年开春之际，阿里诚意献上重磅大礼：《阿里巴巴Java开发手册》，首次公开阿里官方Java代码规范标准。这套Java统一规范标准将有助于提高行业编码规范化水平，帮助行业人员提高开发质量和效率、大大降低代码维护成本。
引用书上的一句话：
很多编程方式客观上没有对错之分，一致性很重要，可读性很重要，团队沟通效率很重要。程序员天生需要团队协作，而协作的正能量要放在问题的有效沟通上。个性化应尽量表现在系统架构和算法效率的提升上，而不是在合作规范上进行纠缠不休的讨论、争论，最后没有结论。
作者(孤尽)在知乎回答的一句话：
翻完了不代表记住了，记住了不代表理解了，理解了不代表能够应用上去，真正的知识是实践，实践，实践。
北京的冬天外面非常的冷，所以有个周末，天气阴沉沉的，比较适合在室内呆着。看看我的书籍，才发现当时618买了一堆书，这堆书还有没撕包装的呢（其实有好几本书还是全新的呢）….于是我翻出了最薄的一本《阿里巴巴 Java开发手册》：
说明：
- 书上很多的规范是可以用IDE来避免的，也有很多我之前已经知道的了
- 这篇文章只记录
**我认为**比较重要，或者说是我之前开发时没有注意到的一些规范(知识点)。 - 该文章的内容肯定没有书上写得那么全的，如果感兴趣的同学可以去买一本来读一下~（或者各种PDF版本的电子档随处可以下载）
Java相关
- POJO是DO/DTO/BO/VO的统称，禁止命名为xxxPOJO
- 获取多个对象的方法中list作为前缀（不用清一色的get）
- 获取统计值的方法用count作为前缀（比get…Count这种命名简略）
- POJO类中的布尔类型(Boolean)的变量都不要加is前缀，否则部分框架解析会引起序列化错误
如果你的变量名带is的话，比如isActive，框架解析的时候可能就当成active了。
- 如果是形容能力的接口名称，取对应的形容词为接口名(通常是-able的形式)
- 不允许任何魔法值(未经预先定义的常量)直接出现在代码中（这个要尽量避免，因为后人来阅读的你代码，根本不知道魔法值代表什么）
- 所有POJO类的属性全部使用包装数据类型，RPC的返回值和参数必须使用包装数据类型，所有的局部变量都使用基本数据类型。定义VO/DTO/DO等POJO类时，不要设定任何属性的默认值
简单的说就是0是有意义的，而很多时候我们只想表达null，那基本类型就无能为力了（局部变量有基本类型是因为我清楚意义，效率稍微高那么一点点）
- 构造方法禁止加入任何的业务逻辑，如果初始化逻辑可以放在init方法中。set/get方法也不要增加业务逻辑。此处指的是业务逻辑，比如一些基本的数据赋值，这种还是允许的
如果set/get方法放入业务逻辑，有时候排查问题就变得很麻烦了
- 工具类Arrays.asList()把数组转成List时，不能使用其修改集合的相关方法。比如说add、clear、remove （因为他产生的是一个不可变的List）
- 使用entrySet遍历Map类集合K/V，而不是用keySet方式遍历
keySet遍历了两次，一次是转成Iterator对象，一次是从hashMap中取出key所对应的value，如果JDK8可以使用Map.foreach方法
- 线程资源必须由线程池提供，不允许在应用中自行显示创建线程。线程池不允许用Executors创建，通过ThreadPoolExecutor的方式创建，这样的处理方式能够让编写代码的工程师更加明确线程池的运行规则，规避资源耗尽的风险。