编写高质量代码: 改善Java程序的151个建议 | 第十一、十二章 开源世界 思想为源

编写高质量代码: 改善Java程序的151个建议

前言

大家好, 这里是 Rocky编程日记, 该篇文是学习 编写高质量Java代码的151个建议记录。
希望我写得笔记你能够喜欢, 希望我写的笔记能够给你提供帮助。
同时若笔记中存在不对的地方,那一定是圈主当时的理解还不够, 希望你能够及时指出嗷~
前人述备矣, 我只是知识的搬运工~
编写高质量代码: 改善Java程序的151个建议 的代码仓库地址: https://gitee.com/Rocky-BCRJ/java-diary.git。

第十一章 开源世界

建议139：大胆采用开源工具

• 选择开源工具和框架时要遵循一定的规则：
  • 1、普适性原则；
    选择一个工具或框架就必须考虑项目成员的整体技术水平, 不能有太大的跨度或跳跃性, 要确保大部分项目成员对工具都比较熟悉, 若一个项目中的成员大部分是新员工, 那么在持久层框架的选择上。使用MyBatis就比Hibernate要合适,因为MyBatis相对简单、方便; 再比如在一个熟悉 SSH 开发的团队中, 就不应该无故选择 Guice 作为 IOC 容器, 除非是 行政 命令 或为了尝鲜。
  • 2、唯一性原则；
    相同的工具只选择一个或一种,不要让多种相同或相似职能的工具共存。例如集合工具可以使用 Apache Commons 的 collections 包, 当然也可以使用 Google Guava 的 Collections 的工具包, 但是在项目开发前就应该确认下来, 不能让两者共存。
  • 3、“大树纳凉”原则；
    在没有空调、电风扇的年代, 最好的纳凉方式就是找一颗大树, 躲在树荫下享受着习习凉风,惬意自在。我们在选择工具包时也应如此, 得寻找比较有名的开源组织, 比如 Apache 、Spring、opensymphony、Google等,这些开源组织一则具有固定的开发和运作风格, 二则具有广阔的使用人群, 在这样的大树下, 我们才有时间和精力纳凉, 而不会把大好的时间消耗在排查 Bug 上。
  • 4、精而专原则；
    在武术上, 对一个顶级高手的描述是 “精通十八般武器”, 但对工具包来说这就不适合了, 我们选择的工具包应该是精而专的,而不是广而多的,比如虽然 Spring 框架提供了 Utils 工具包, 但在一般情况下不要使用它, 因为它不专, Utils工具包只是 Spring 框架中的一个附加功能而已。
  • 5、高热度原则
    一个开源项目的热度越高, 更新得就越频繁,使用的人群就越广, Bug的瀑光率就越快, 修复效率也就越高, 这对我们项目的稳定性来说是非常重要的。

建议140：推荐使用Guava扩展工具包

• Guava（石榴）是Google发布的，其中包含了collections、caching、primitives support、concurrency libraries、common annotations、I/O等

建议141：Apache扩展包

• Apache Commons通用扩展包基本上是每个项目都会使用的，一般情况下lang包用作JDK的基础语言扩展。Apache Commons项目包含非常好用的工具，如DBCP、net、Math等

建议142：推荐使用Joda日期时间扩展包

• Joda可以很好地与现有的日期类保持兼容，在需要复杂的日期计算时使用Joda。日期工具类也可以选择date4j

建议143：可以选择多种Collections扩展

• 三个比较有个性的Collections扩展工具包：
  • FastUtil，主要提供两种功能：一种是限定键值类型的Map、List、Set等，另一种是大容量的集合；
  • Trove，提供了一个快速、高效、低内存消耗的Collection集合，并且还提供了过滤和拦截功能，同时还提供了基本类型的集合；
  • lambdaj，是一个纯净的集合操作工具，它不会提供任何的集合扩展，只会提供对集合的操作，比如查询、过滤、统一初始化等

第十二章 思想为源

建议144：提倡良好的代码风格

• 良好的编码风格包括：
  • 1、整洁；
  • 2、统一；
  • 3、流行；
  • 4、便捷，推荐使用Checkstyle检测代码是否遵循规范

建议145：不要完全依靠单元测试来发现问题

• 单元测试的目的是保证各个独立分隔的程序单元的正确性，虽然它能够发现程序中存在的问题（或缺陷、或错误），但是单元测试只是排查程序错误的一种方式，不能保证代码中的所有错误都能被单元测试挖掘出来，
• 原因：
  • 单元测试不可能测试所有的场景（路径）；
  • 代码整合错误是不可避免的；
  • 部分代码无法（或很难）测试；
  • 单元测试验证的是编码人员的假设

建议146：让注释正确、清晰、简洁

• 注释不是美化剂，而是催化剂，或为优秀加分，或为拙略减分

建议147：让接口的职责保持单一

• 接口职责一定要单一，实现类职责尽量单一）（单一职责原则（Single Responsibility Principle，简称SRP）有以下三个优点：
  • 类的复杂性降低；
  • 可读性和可维护性提高；
  • 降低变更风险

建议148：增强类的可替换性

• Java的三大特征：封装、继承、多态；说说多态，一个接口可以有多种实现方式，一个父类可以有多个子类，并且可以把不同的实现或子类赋给不同的接口或父类。
• 多态的好处非常多，其中一点就是增强了类的可替换性，但是单单一个多态特性，很难保证我们的类是完全可以替换的，幸好还有一个里氏替换原则来约束。
• 里氏替换原则：所有引用基类的地方必须能透明地使用其子类的对象。通俗点讲，只要父类型能出现的地方子类型就可以出现，而且将父类型替换为子类型还不会产生任何错误或异常，使用者可能根本就不需要知道是父类型还是子类型。
• 为了增强类的可替换性，在设计类时需要考虑以下三点：
  • 子类型必须完全实现父类型的方法；
  • 前置条件可以被放大；
  • 后置条件可以被缩小

建议149：依赖抽象而不是实现

• 此处的抽象是指物体的抽象，比如出行，依赖的是抽象的运输能力，而不是具体的运输交通工具。**依赖倒置原则（Dependence Inversion Principle，简称DIP）**要求实现解耦，保持代码间的松耦合，提高代码的复用率。
• DIP的原始定义包含三层含义：
  1、高层模块不应该依赖底层模块，两者都应该依赖其抽象；
  2、抽象不应该依赖细节；
  3、细节应该依赖抽象；
• DIP在Java语言中的表现就是：
  1、模块间的依赖是通过抽象发生的，实现类之间不发生直接的依赖关系，其依赖关系是通过接口或抽象类产生的；
  2、接口或抽象类不依赖于实现类；
  3、实现类依赖接口或抽象类；更加精简的定义就是：
  面向接口编程。实现模块间的松耦合遵循规则：
  1、尽量抽象；
  2、表面类型必须是抽象的；
  3、任何类都不应该从具体类派生；
  4、尽量不要覆写基类的方法；
  5、抽象不关注细节

建议150：抛弃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. 横向扩展