Java开发总结技巧，Java最佳实践，提升代码可读性与可靠性

从命名变量到设计软件架构，开发人员每天都要做出许多决定，而做出正确决定的最好的办法就是经验。虽然并非每个人都具备丰富的软件开发经验，但每个人都可以从他人身上学习。下面是我对 Java 开发总结的一些技巧，希望可以有助你提高 Java 代码的可读性和可靠性。

整理了最新2020整理收集的一线互联网公司面试真题（都整理成文档），有很多干货，包含netty，spring，线程，spring cloud等详细讲解，也有详细的学习规划图，面试题整理等，我感觉在面试这块讲的非常清楚:获取面试资料只需:点击这里领取!!!暗号：CSDN

1、编程原则

写代码不是够用就好，因为这些代码不仅需要你维护，未来某个时刻还有其他人会加入维护的行列。软件开发的“二八定律”，开发人员 80％ 的时间在阅读代码，而仅有 20％ 的时间在编写和调试。

请务必编写可读性高的代码。

这样的代码不看注释只通过代码就可以了解代码完成的功能。

下面我会列出一些重要的设计原则，可以帮助我们设计出优秀的代码。

KISS 原则：在设计当中应当注重简约的原则。与之相对的是，在刚开始编程时就高出复杂、摸棱两可的设计。
DRY 原则：不要做重复的工作。把重复的代码和逻辑提取出来。
YAGNI 原则：不要过度设计。可以为将来预留扩展点，但不要仅仅因为可能需要就开始工作。
代码整洁更重要：没有必要为了展示聪明和学识而去“打磨”代码。
避免过早优化：过早的优化的问题在于，只有事后才能真正知道真正的瓶颈在哪里。
单一职责：一个类只负责一个功能领域中的相应职责。
组合优于继承：实现具有复杂行为的对象应该通过实现接口而不是继承来添加行为。
对象健身操：对象健身操时一组编程练习，包含了9条规则（也称为“九戒”）。
快速失败原则：快速失败原则表示一旦发生任何意外错误，应立即停止当前操作。坚持这一原则通常会带来更稳定的解决方案。

2、Package 最佳实践

优先考虑按业务领域而非技术层次构组织 package。
定义 package 时要考虑信息的封装和隐藏，避免按技术实现定义 package 带来的错误使用。
View package 作为严格的 API 对待：不要暴露内部实现。
不要为只在 package 内使用的类使用 pulic。

3、Class 最佳实践

3.1 静态类

静态类不允许实例化，为静态类添加一个私有构造函数。
静态类必须满足：无状态、不可变、不允许继承、线程安全。
确保使用静态类不会给程序带来副作用。通常静态类会作为工具类提供，例如过滤列表等。

3.2 继承

优先考虑组合而不是继承。
不要公开 protected 字段，可以提供一个 protected accessor。
如果可以使用 final，请把类标记为 final 。
如果不希望被其他类继承，同样把类标记为 final。
除非允许子类覆盖方法，否则请把方法标记为 final。
如果不需要构造函数，请不要创建没有实现逻辑的默认构造函数。Java 会替你创建一个默认构造函数。

4、接口最佳实践

不要在接口中定义常量，这样不但无法阻止类实现该接口同时还会污染 API。请改为使用静态类。使用静态类还有一个好处，就是可以在 static 代码块中执行更复杂的对象初始化操作。
不要过度使用接口。
如果有且只有一个类实现接口，这可能是过度使用接口的表现。这种用法的弊大于利。
“面向接口编程，不要面向实现编程”并不意味着每个业务类都要有接口，这种是过度设计，违反前面提到的 YAGNI 原则。
保持接口功能小而具体，这样使用的人能快速找到自己感兴趣的功能。可以参考 SOLID 六大设计原则中的 SIP 原则（接口隔离原则）。

5、Finalizer 最佳实践

请谨慎使用 Object#finalize()。只用作清理资源时 fail-safe 措施（失效安全措施）使用，比如关闭文件。使用资源的时，始终提供显式的清理方法，比如 close()。
在继承层次结构中，始终在 try 块中调用父类的 finalize()，在 finally 中执行清理操作。
如果没有显示调用清理方法并且 finalizer 关闭了资源，要记录错误。
如果没有 logger，请使用线程异常处理程序。最终会转到标准错误并记录日志。

6、通用原则

6.1 断言

断言用来检查程序执行的先决条件，是快速失败原则的一种体现。可以借助断言更快地定位错误根源。

对象的状态：

永远不要创建无效对象或把对象变为无效状态。
在构造函数和方法中，始终检查入参确保符合要求。
不要使用Java assert 关键字，因为它可能会被禁用。
使用 Assertions 类避免冗长的 if-else 检查。

6.2 泛型

下面是开发者应该注意的泛型使用典型场景。

1、尽可能使用类型推断而不是返回基类或接口：

// MySpecialObject o = MyObjectFactory.getMyObject();
public <T extends MyObject> T getMyObject(int type) {
    
    return (T) factory.create(type);
}

2、当无法自动推断类型时使用 inline。

public class MySpecialObject extends MyObject<SpecialType> {
   
  public MySpecialObject() {
   
   super(Collections.emptyList());   // 这种写法很丑陋，还丢弃了类型
   super(Collections.EMPTY_LIST();    // 这种写法很蠢
   // 推荐写法
   super(new ArrayList<SpecialType>());    
   super(Collections.<SpecialType>emptyList());
  }
}

3、通配符：

只读不可写时用 exends，只写不可读时用 super。如果需要读写，则不要用通配符。

大家都喜欢 PECS 原则（生产者用 extends，消费者用 super）
T Producer 使用 Foo<? extends T>。
T Consumer 使用 Foo<? super T>。

7、单例最佳实践

不要原封不动地照抄经典“设计模式”代码实现单例。虽然在 C++ 中有效，但在 Java 中不合适。

1、下面的代码尽管线程安全，但请不要这么做（当心性能瓶颈）。

public final class MySingleton {
   
  private static MySingleton instance;

  private MySingleton(