编写高质量代码:改善Java程序的151个建议(秦小波著)

编辑推荐

《编写高质量代码:改善Java程序的151个建议》：大多数Java程序员都会在前进的道路上被以下几类问题所困扰：一、来自于语言本身的问题。例如：覆写变长方法为什么会出现不能编译的情况？final修饰的int类型常量竟然在运行期被修改？匿名类是否有构造函数？它与普通类的构造函数有何不同？为什么要把受检异常转化为非受检异常？
二、来自于程序设计和常用API的问题。例如：如何用一行代码实现两个集合的交、差、并集？如何才能动态加载一个类？数组如何动态加载？在switch中使用枚举类型，为什么会出现NullPointer Exception异常？为什么使用了volatile关键字后数据还是出现混乱？显式锁（Lock类）和内部锁（synchronized关键宇）完全一样吗？三、来自于程序架构和思想方面的问题。例如：Java的性能是否曾经让你担忧过？或者曾经让你很受伤？到底是该多采用开源工具还是自己写工具类？若采用开源工具，有什么评测标准？什么样的代码风格才是优秀的？怎么才能让一个团队保持同样的风格？
如果你曾经为诸如此类的问题感到疑惑不解或顿然大悟，说明你正在向Java技术的巅峰攀登，正在成长为“振臂一呼，应者云集”的技术大牛，恭喜你！《编写高质量代码:改善Java程序的151个建议》从不同的侧面出发，对Java编码中各种棘手的疑难杂症和常见问题奉献了真知灼见，相信你一定能从中受益。
从语法、程序设计和架构、工具和框架、编码风格、编程思想，5个方面深入探讨编写高质量Java代码的技巧、禁忌和最佳实践。

媒体推荐

本书是一本关于Java编码最佳实践的集大成之作，也是一本能指导Java程序员编写出高质量代码的指点迷津之作。全书从Java语法、程序的架构和设计、编码规范和编程习惯等方面为广大的Java程序员们总结出了151条极富借鉴意义的建议，这些建议都在实践中被证明是解决Java编码中疑难问题的最佳实践。如果能掌握本书中的内容，不仅能加深对Java语言的理解，还能提升程序架构和设计方面的能力，同时还能规范我们的开发行为和习惯，让我们成为优秀的程序员，编写出更高质量的代码。
　　——51CTO（中国领先的IT技术网站）
Coding为我们创造了一个丰富多彩的虚拟世界，本书是作者秦小波多年工作经验的总结，也许能为所有从事Java软件开发的同行们提供有益的参考。本书除了与大家分享了151条编写高质里java代码的宝贵建议之外，它还在试图告诉创造虚拟世界的程序员们，Coding不仅仅是使用智慧，更多的是对它的热爱，唯有热爱和用心才能编写出高质量的代码，才能开发出优秀的应用。
　　——李海宁交通银行软件开发中心总经理
本书有几个很突出的特点：第一，内容实用，它没有去讲解基本语法，那是大学教科书的内容，本书着重探讨了如何才能将Java代码编写得更高效、更优雅；第二，涉及面广，从语法到编程规范和编程思想，从JDK API到开源框架，都有所涉猎；第三，注重实战，书中的所有建议都是从实践中总结出来的，都是真实场景的重现，不是纸上谈兵。除此之外，本书内容精炼、语言幽默、通俗流畅，阅读体验十分好。对于正在进阶修炼途中的Java程序员来说，本书是提高开发技能和自身修养的好帮手。
　　——计文柯资深Java技术专家，著有畅销书《Spring技术内幕：深入解析Spring架构与设计原理》

作者简介

秦小波，资深软件开发工程师、系统分析师和架构师(获Sun架构师认证)，从事软件开发工作10余年，实践经验极其丰富。资深Java技术专家，精通Java语言、Spring、Struts 2、Hibernate、iBatis、jBPM等Java技术，在企业级Java应用领域积累了大量工程经验，对ESB、BPEL等整合技术也有较深入的认识。精通设计模式，对设计模式有深刻的认识和独到见解，而且创造性地提出了自己在大量实践中总结出来的新的设计模式。他撰写的《设计模式之禅》一书凭借优质的内容和良好的可读性广获读者好评，被誉为“设计模式领域的里程碑之作”。此外，他还是一位优秀的DBA，获IBM DB2 DBA资格认证，对海量数据处理有深入的研究。

前言
第1章　java开发中通用的方法和准则
建议1: 不要在常量和变量中出现易混淆的字母
建议2: 莫让常量蜕变成变量
建议3: 三元操作符的类型务必一致
建议4: 避免带有变长参数的方法重载
建议5: 别让null值和空值威胁到变长方法
建议6: 覆写变长方法也循规蹈矩
建议7: 警惕自增的陷阱
建议8: 不要让旧语法困扰你
建议9: 少用静态导入
建议10: 不要在本类中覆盖静态导入的变量和方法
建议11: 养成良好习惯,显式声明uid
建议12: 避免用序列化类在构造函数中为不变量赋值
建议13: 避免为final变量复杂赋值
建议14: 使用序列化类的私有方法巧妙解决部分属性持久化问题
建议15: break万万不可忘
建议16: 易变业务使用脚本语言编写
建议17: 慎用动态编译
建议18: 避免instanceof非预期结果
建议19: 断言绝对不是鸡肋
建议20: 不要只替换一个类

第2章　基本类型
建议21: 用偶判断,不用奇判断
建议22: 用整数类型处理货币
建议23: 不要让类型默默转换
建议24: 边界,边界,还是边界
建议25: 不要让四舍五入亏了一方
建议26: 提防包装类型的null值
建议27: 谨慎包装类型的大小比较
建议28: 优先使用整型池
建议29: 优先选择基本类型
建议30: 不要随便设置随机种子

第3章　类、对象及方法
建议31: 在接口中不要存在实现代码
建议32: 静态变量一定要先声明后赋值
建议33: 不要覆写静态方法
建议34: 构造函数尽量简化
建议35: 避免在构造函数中初始化其他类
建议36: 使用构造代码块精炼程序
建议37: 构造代码块会想你所想
建议38: 使用静态内部类提高封装性
建议39: 使用匿名类的构造函数
建议40: 匿名类的构造函数很特殊
建议41: 让多重继承成为现实
建议42: 让工具类不可实例化
建议43: 避免对象的浅拷贝
建议44: 推荐使用序列化实现对象的拷贝
建议45: 覆写equals方法时不要识别不出自己
建议46: equals应该考虑null值情景
建议47: 在equals中使用getclass进行类型判断
建议48: 覆写equals方法必须覆写hashcode方法
建议49: 推荐覆写tostring方法
建议50: 使用package-info类为包服务
建议51: 不要主动进行垃圾回收

第4章　字符串
建议52: 推荐使用string直接量赋值
建议53: 注意方法中传递的参数要求
建议54: 正确使用string、stringbuffer、stringbuilder
建议55: 注意字符串的位置
建议56: 自由选择字符串拼接方法
建议57: 推荐在复杂字符串操作中使用正则表达式
建议58: 强烈　建议使用utf编码
建议59: 对字符串排序持一种宽容的心态

第5章　数组和集合
建议60: 性能考虑,数组是首选
建议61: 若有必要,使用变长数组
建议62: 警惕数组的浅拷贝
建议63: 在明确的场景下,为集合指定初始容量
建议64: 多种最值算法,适时选择
建议65: 避开基本类型数组转换列表陷阱
建议66: aslist方法产生的list对象不可更改
建议67: 不同的列表选择不同的遍历方法
建议68: 频繁插入和删除时使用linkedlist
建议69: 列表相等只需关心元素数据
建议70:子列表只是原列表的一个视图
建议71: 推荐使用sublist处理局部列表
建议72: 生成子列表后不要再操作原列表
建议73: 使用comparator进行排序
建议74: 不推荐使用binarysearch对列表进行检索
建议75: 集合中的元素必须做到compareto和equals同步
建议76: 集合运算时使用更优雅的方式
建议77: 使用shuffle打乱列表
建议78: 减少hashmap中元素的数量
建议79: 集合中的哈希码不要重复
建议80: 多线程使用vector或hashtable
建议81: 非稳定排序推荐使用list
建议82: 由点及面,一叶知秋-集合大家族

第6章　枚举和注解
建议83: 推荐使用枚举定义常量
建议84: 使用构造函数协助描述枚举项
建议85: 小心switch带来的空值异常
建议86: 在switch的default代码块中增加assertionerror错误
建议87: 使用valueof前必须进行校验
建议88: 用枚举实现工厂方法模式更简洁
建议89: 枚举项的数量限制在64个以内
建议90: 小心注解继承
建议91: 枚举和注解结合使用威力更大
建议92: 注意@override不同版本的区别

第7章　泛型和反射
建议93: java的泛型是类型擦除的
建议94: 不能初始化泛型参数和数组
建议95: 强制声明泛型的实际类型
建议96: 不同的场景使用不同的泛型通配符
建议97: 警惕泛型是不能协变和逆变的
建议98: 　建议采用的顺序是list[t]、list[?]、list[object]
建议99: 严格限定泛型类型采用多重界限
建议100: 数组的真实类型必须是泛型类型的子类型
建议101: 注意class类的特殊性
建议102: 适时选择getdeclared×××和get×××
建议103: 反射访问属性或方法时将accessible设置为true
建议104: 使用forname动态加载类文件
建议105: 动态加载不适合数组
建议106: 动态代理可以使代理模式更加灵活
建议107: 使用反射增加装饰模式的普适性
建议108: 反射让模板方法模式更强大
建议109: 不需要太多关注反射效率

第8章　异常
建议110: 提倡异常封装
建议111: 采用异常链传递异常
建议112: 受检异常尽可能转化为非受检异常
建议113: 不要在finally块中处理返回值
建议114: 不要在构造函数中抛出异常
建议115: 使用throwable获得栈信息
建议116: 异常只为异常服务
建议117: 多使用异常,把性能问题放一边

第9章　多线程和并发
建议118: 不推荐覆写start方法
建议119: 启动线程前stop方法是不可靠的
建议120: 不使用stop方法停止线程
建议121: 线程优先级只使用三个等级
建议122: 使用线程异常处理器提升系统可靠性
建议123: volatile不能保证数据同步
建议124: 异步运算考虑使用callable接口
建议125: 优先选择线程池
建议126: 适时选择不同的线程池来实现
建议127: lock与synchronized是不一样的
建议128: 预防线程死锁
建议129: 适当设置阻塞队列长度
建议130: 使用countdownlatch协调子线程
建议131: cyclicbarrier让多线程齐步走

第10章　性能和效率
建议132: 提升java性能的基本方法
建议133: 若非必要,不要克隆对象
建议134: 推荐使用“望闻问切”的方式诊断性能
建议135: 必须定义性能衡量标准
建议136: 枪打出头鸟-解决首要系统性能问题
建议137: 调整jvm参数以提升性能
建议138: 性能是个大“咕咚”

第11章　开源世界
建议139: 大胆采用开源工具
建议140: 推荐使用guava扩展工具包
建议141: apache扩展包
建议142: 推荐使用joda日期时间扩展包
建议143: 可以选择多种collections扩展

第12章　思想为源
建议144: 提倡良好的代码风格
建议145: 不要完全依靠单元测试来发现问题
建议146: 让注释正确、清晰、简洁
建议147: 让接口的职责保持单一
建议148: 增强类的可替换性
建议149: 依赖抽象而不是实现
建议150: 抛弃7条不良的编码习惯
建议151: 以技术员自律而不是工人

文摘

版权页：

插图：

从决定撰写本书到完稿历时9个月，期间曾经遇到过种种困难和挫折，但这个过程让我明白了坚持的意义，明白了“行百里者半九十”的寓意—坚持下去，终于到了写前言的时刻。
为什么写这本书
从第一次敲出“Hello World”到现在已经有15年时间了，在这15年里，我当过程序员和架构师，也担任过项目经理和技术顾问—基本上与技术沾边的事情都做过。从第一次接触Java到现在，已经有11年4个月了，在这些年里，我对Java可谓是情有独钟，对其编程思想、开源产品、商业产品、趣闻轶事、风流人物等都有所了解和研究。对于Java，我非常感激，从物质上来说，它给了我工作，帮助我养家糊口；从精神上来说，它带给我无数的喜悦、困惑、痛苦和无奈— 一如我们的生活。
我不是技术高手，只是技术领域的一个拓荒者，我希望能把自己的知识和经验贡献出来，以飨读者。在写作的过程中，我也反复地思考：我为谁而写这本书？为什么要写？
希望本书能帮您少走弯路
您是否曾经为了提供一个“One Line”的解决方案而彻夜地查看源代码？现在您不用了。
您是否曾经为了理解某个算法而冥思苦想、阅览群书？现在您不用了。
您是否曾经为了提升0.1秒的性能而对N种实现方案进行严格测试和对比？现在您不用了。
您是否曾经为了避免多线程死锁问题而遍寻高手共同诊治？现在您不用了。
……
在学习和使用Java的过程中您是否在原本可以很快掌握或解决的问题上耗费了大量的时间和精力？也许您现在不用了，本书的很多内容都是我用曾经付出的代价换来的，希望它能帮助您少走弯路！
希望本书能帮您打牢基础
那些所谓的架构师、设计师、项目经理、分析师们，已经有多长时间没有写过代码了？代码是一切的基石，我不太信任连“Hello World”都没有写过的架构师。看看我们软件界的先辈们吧，Dennis M. Ritchie决定创造一门“看上去很好”的语言时，如果只是站在高处呐喊，这门语言是划时代的，它有多么优秀，但不去实现，又有何用呢？没有Dennis M. Ritchie的亲自编码实现，C语言不可能诞生，UNIX操作系统也不可能诞生。Linux在聚拢成千上万的开源狂热者对它进行开发和扩展之前，如果没有Linus的编码实现，仅凭他高声呐喊“我要创造一个划时代的操作系统”，有用吗？一切的一切都是以编码实现为前提的，代码是我们前进的基石。