建议139：大胆采用开源工具
MVC框架有Structs，也有Spring MVC、WebWorker；IoC容器有Spring，也有Coolgle Guice；ORM有Hibernate、MyBatis；日志有经典的log4j、崭新的logback。选择开源工具和框架时要遵循一定的规则：
1、普适性原则:不能有太大的跨度或跳跃性。2、唯一性原则：相同工具选一种，不要让多种相同或功能相似工具共存。3、“大树纳凉”原则：（有名的开源组织）4、精而专原则：精而准不是广泛的。5、高热度原则。
建议140：推荐使用Guava扩展工具包
Guava（石榴）是Google发布的，对JDK的Collection包进行扩展。其中包含了collections、caching、primitives support、concurrency libraries、common annotations、I/O等：
1、Collection：com.goolgle.common.collect包括不可变集合（Immutable Collections）、多值Map、table表和集合工具类。不可变集合包括ImmutableList、ImmutableMap、ImmutableSet、ImmutableSortMap、ImmutableSortedSet等比不可修改集合更容易实现。多值Map。Map是键值对形式。put时如果键重复了则会覆盖原有的值，但一键多值就比较麻烦。使用Guava的Multimap可以解决。集合工具类：Lists、Maps、Sets分别对应List、Map、Set工具类。
2、字符串操作：Guava提供的字符串工具类：Joiner连接器和Splitter拆分器。当然JDK的方法也能实现但是Guava更简单些。Joiner不仅可以连接字符串还可以吧Map中键值对串联起来。
3、基本类型工具：基本类型工具在primitives包中，以基本类型名+S的方式命名的，如Ints是以int的工具类，Doubles是double的工具类。
建议141：Apache扩展包
Apache Commons通用扩展包基本上是每个项目都会使用的，一般情况下lang包用作JDK的基础语言扩展。Apache Commons项目包含非常好用的工具，如DBCP、net、Math等。
建议142：推荐使用Joda日期时间扩展包
Joda可以很好地与现有的日期类保持兼容，在需要复杂的日期计算时使用Joda。日期工具类也可以选择date4j：1、本地格式的日期时间：如当前时间DateTime d=new DataeTime（）；本地日期格式d.toLocalDate()；2、日期计算，比如计算100天后事星期几使用JDK日期类比较麻烦，使用Joda就会很简单。d.plusHours(100).dayofWeek();加100小时候周几。DateTime是一个不可变类型，与String非常相似即使通过plusXX。minusXX等方法进行操作，d仍然不会变。只是生成一个新的对象。但Joda提供一个可变类型的日期对象：MutableDateTime类。
建议143：可以选择多种Collections扩展
三个比较有个性的Collections扩展工具包：1、FastUtil，主要提供两种功能：一种是限定键值类型的Map、List、Set等，另一种是大容量的集合；2、Trove，提供了一个快速、高效、低内存消耗的Collection集合，并且还提供了过滤和拦截功能，同时还提供了基本类型的集合，优势在于性能上，在进行一般的增删改它的相应比JDK集合少一个数量级。3、lambdaj，是一个纯净的集合操作工具，它不会提供任何的集合扩展，只会提供对集合的操作，比如查询、过滤、统一初始化等
建议144：提倡良好的代码风格
提高可读性，良好的编码风格包括以下几种特征：1、整洁；2、统一；3、流行；4、便捷，推荐使用Checkstyle检测代码是否遵循规范。
建议145：不要完全依靠单元测试来发现问题
单元测试的目的是保证各个独立分隔的程序单元的正确性，虽然它能够发现程序中存在的问题（或缺陷、或错误），但是单元测试只是排查程序错误的一种方式，不能保证代码中的所有错误都能被单元测试挖掘出来，原因：1、单元测试不可能测试所有的场景（路径）：包括正常场景测试代码的主逻辑、边界数据场景用来测试在边界情况下的数据场景，异常场景测试异常故障下能否按照预期运行；2、代码整合错误是不可避免的；3、部分代码无法（或很难）测试；4、单元测试验证的是编码人员的假设。
建议146：让注释正确、清晰、简洁
坏注释：1、废话式注释、2、故事式注释（太多）。3、不必要注释。4、过时式注释。5、大块式注释。6、流水账式注释。7、转为javaDoc编写的注释。号类型的注释：1、法律版本信息。2、解释意图的注释。3、警告性注释。4、TODO注释。注释不是美化剂，而是催化剂，或为优秀加分，或为拙略减分。
建议147：让接口的职责保持单一
接口职责一定要单一，实现类职责尽量单一（单一职责原则（Single Responsibility Principle，简称SRP）有以下三个优点：1、类的复杂性降低，接口功能单一复杂度减少，当然接口数量就会增多；2、可读性和可维护性提高；3、降低变更风险。以电话通信为例说明如何实施单一职责：1、分析职责。2、设计接口。3、合并实现。
建议148：增强类的可替换性
Java的三大特征：封装、继承、多态；说说多态，一个接口可以有多种实现方式，一个父类可以有多个子类，并且可以把不同的实现或子类赋给不同的接口或父类。多态的好处非常多，其中一点就是增强了类的可替换性，但是单单一个多态特性，很难保证我们的类是完全可以替换的，幸好还有一个里氏替换原则来约束。里氏替换原则：所有引用基类的地方必须能透明地使用其子类的对象。通俗点讲，只要父类型能出现的地方子类型就可以出现，而且将父类型替换为子类型还不会产生任何错误或异常，使用者可能根本就不需要知道是父类型还是子类型。为了增强类的可替换性，在设计类时需要考虑以下三点：1、子类型必须完全实现父类型的方法；2、前置条件可以被放大；3、后置条件可以被缩小。
建议149：依赖抽象而不是实现
此处的抽象是指物体的抽象，比如出行，依赖的是抽象的运输能力，而不是具体的运输交通工具。依赖倒置原则（Dependence Inversion Principle，简称DIP）要求实现解耦，保持代码间的松耦合，提高代码的复用率。DIP的原始定义包含三层含义：1、高层模块不应该依赖底层模块，两者都应该依赖其抽象；2、抽象不应该依赖细节；3、细节应该依赖抽象；DIP在Java语言中的表现就是：1、模块间的依赖是通过抽象发生的，实现类之间不发生直接的依赖关系，其依赖关系是通过接口或抽象类产生的；2、接口或抽象类不依赖于实现类；3、实现类依赖接口或抽象类；更加精简的定义就是：面向接口编程。实现模块间的松耦合遵循规则：1、尽量抽象；2、表面类型必须是抽象的；3、任何类都不应该从具体类派生；4、尽量不要覆写基类的方法；5、抽象不关注细节。
建议150：抛弃7条不良的编码习惯
7条经常犯的错误：1）自由格式的代码；2）不使用抽象的代码；3）彰显个性的代码；4）死代码；5）冗余代码；6）拒绝变化的代码；7）自以为是的代码。
建议151：以技术人员自律而不是工人
20条建议技术人员定向培养：1、熟悉工具。2、使用IDE。3、坚持编码。 4、编码前思考。 5、坚持重构。6、多写文档。 7、保持程序版本的简单性。8、做好备份。 9、做单元测试。 10、不要重复发明轮子。11、不要拷贝。 12、让代码充满灵性。13、测试自动化。 14、做压力测试。15、“剽窃”不可耻。 16、坚持向敏捷学习。17、重里更重面。 18、分享。19、刨根问底。 20、横向扩展。
