如何写出更好的Java代码

共计 10732 个字符，预计需要花费 27 分钟才能阅读完成。

from: http://it.deepinmind.com/java/2014/05/21/better-java.html

Java 是最流行的编程语言之一，但似乎并没有人喜欢使用它。好吧，实际上 Java 是一门还不错的编程语言，由于最近 Java 8 发布了，我决定来编辑一个如何能更好地使用 Java 的列表，这里面包括一些库，实践技巧以及工具。

这篇文章在 GitHub 上也有。你可以随时在上面贡献或者添加你自己的 Java 使用技巧或者最佳实践。

• 编码风格

  • 结构体

    *   builder 模式

    • 依赖注入

  • 避免 null 值

  • 不可变

  • 避免过多的工具类

  • 格式

    *   文档

    • Stream

• 部署

  • 框架

  • Maven

    *   依赖收敛

    • 持续集成

  • Maven 仓储

  • 配置管理

• 库

  • 遗失的特性

    *   Apache Commons

    • Guava

    • Gson

    • Java Tuples

    • Joda-Time

    • Lombok

    • Play framework

    • SLF4J

    • jOOQ

    • 测试

      • jUnit 4

    • jMock

    • AssertJ

• 工具

  • IntelliJ IDEA

    *   Chronon

    • JRebel

  • 校验框架

  • Eclipse Memory Analyzer

• 资源

  • 书籍
  • 播客

编码风格

传统的 Java 编码方式是非常啰嗦的企业级 JavaBean 的风格。新的风格更简洁准确，对眼睛也更好。

结构体

我们这些码农干的最简单的事情就是传递数据了。传统的方式就是定义一个 JavaBean:

public class DataHolder {private String data;
public DataHolder() {}public void setData(String data) {    this.data = data;}public String getData() {    return this.data;}
}

这不仅拖沓而且浪费。尽管你的 IDE 可以自动地生成这个，但这还是浪费。因此，[不要这么写](http://www.javapractices.com/topic/TopicAction.do?Id=84)。

相反的，我更喜欢 C 的结构体的风格，写出来的类只是包装数据：

public class DataHolder {public final String data;
public DataHolder(String data) {    this.data = data;}
}

这样写减少了一半的代码。不仅如此，除非你继承它，不然这个类是不可变的，由于它是不可变的，因此推断它的值就简单多了。

如果你存储的是 Map 或者 List 这些可以容易被修改的数据，你可以使用 ImmutableMap 或者 ImmutableList，这个在不可变性这节中会有讨论。

Builder 模式

如果你有一个相对复杂的对象，可以考虑下 Builder 模式。

你在对象里边创建一个子类，用来构造你的这个对象。它使用的是可修改的状态，但一旦你调用了 build 方法，它会生成一个不可变对象。

想象一下我们有一个非常复杂的对象 DataHolder。它的构造器看起来应该是这样的：

public class ComplicatedDataHolder {public final String data;    public final int num;    // lots more fields and a constructor
public class Builder {    private String data;    private int num;    public Builder data(String data) {        this.data = data;        return this;    }    public Builder num(int num) {        this.num = num;        return this;    }    public ComplicatedDataHolder build() {        return new ComplicatedDataHolder(data, num); // etc    }}
}

现在你可以使用它了：

final ComplicatedDataHolder cdh = new ComplicatedDataHolder.Builder()    .data("set this")    .num(523)    .build();

关于 Builder 的使用 [这里](http://en.deepinmind.com/blog/2014/05/21/the-builder-pattern-in-practice.html) 还有些更好的例子，我这里举的例子只是想让你大概感受一下。当然这会产生许多我们希望避免的样板代码，不过好处就是你有了一个不可变对象以及一个连贯接口。

依赖注入

这更像是一个软件工程的章节而不是 Java 的，写出可测的软件的一个最佳方式就是使用依赖注入（Dependency injection，DI）。由于 Java 强烈鼓励使用面向对象设计，因此想写出可测性强的软件，你需要使用 DI。

在 Java 中，这个通常都是用 Spring 框架来完成的。它有一个基于 XML 配置的绑定方式，并且仍然相当流行。重要的一点是你不要因为它的基于 XML 的配置格式而过度使用它了。在 XML 中应该没有任何的逻辑和控制结构。它只应该是依赖注入。

还有一个不错的方式是使用 Dagger 库 以及 Google 的Guice。它们并没有使用 Spring 的 XML 配置文件的格式，而是将注入的逻辑放到了注解和代码里。

避免 null 值

如果有可能的话尽量避免使用 null 值。你可以返回一个空的集合，但不要返回 null 集合。如果你准备使用 null 的话，考虑一下 @Nullable 注解。IntelliJ IDEA 对于 @Nullable 注解有内建的支持。

如果你使用的是 Java 8 的话，可以考虑下新的 Optional 类型。如果一个值可能存在也可能不存在，把它封装到 Optional 类里面，就像这样：

public class FooWidget {private final String data;    private final Optional<Bar> bar;
public FooWidget(String data) {    this(data, Optional.empty());}public FooWidget(String data, Optional&lt;Bar&gt; bar) {    this.data = data;    this.bar = bar;}public Optional&lt;Bar&gt; getBar() {    return bar;}
}

现在问题就清楚了，data 是不会为 null 的，而 bar 可能为空。Optional 类有一些像 isPresent 这样的方法，这让它感觉跟检查 null 没什么区别。不过有了它你可以写出这样的语句：

final Optional<FooWidget> fooWidget = maybeGetFooWidget();final Baz baz = fooWidget.flatMap(FooWidget::getBar)                         .flatMap(BarWidget::getBaz)                         .orElse(defaultBaz);

这比使用 if 来检查 null 好多了。唯一的缺点就是标准类库中对 Optional 的支持并不是很好，因此你还是需要对 null 进行检查的。

不可变

变量，类，集合，这些都应该是不可变的，除非你有更好的理由它们的确需要进行修改。

变量可以通过 final 来设置成不可变的：

final FooWidget fooWidget;if (condition()) {fooWidget = getWidget();} else {try {        fooWidget = cachedFooWidget.get();    } catch (CachingException e) {log.error("Couldn't get cached value", e);        throw e;    }}// fooWidget is guaranteed to be set here

现在你可以确认 fooWidget 不会不小心被重新赋值了。final 关键字可以和 if/else 块以及 try/catch 块配合使用。当然了，如果 fooWidget 对象不是不可变的，你也可以很容易地对它进行修改。

有可能的话，集合都应该尽量使用 Guava 的 ImmutableMap, ImmutableList, or ImmutableSet 类。这些类都有自己的构造器，你可以动态的创建它们，然后将它们设置成不可变的，。

要使一个类不可变，你可以将它的字段声明成不可变的（设置成 final)。你也可以把类自身也设置成 final 的这样它就不能被扩展并且修改了，当然这是可选的。

避免大量的工具类

如果你发现自己添加了许多方法到一个 Util 类里，你要注意了。

public class MiscUtil {public static String frobnicateString(String base, int times) {// ... etc}
public static void throwIfCondition(boolean condition, String msg) {    // ... etc}
}

这些类乍一看挺吸引人的，因为它们里面的这些方法不属于任何一个地方。因此你以代码重用之名将它们全都扔到这里了。

这么解决问题结果更糟。把它们放回它们原本属于的地方吧，如果你确实有一些类似的常用方法，考虑下 Java 8 里接口的默认方法。并且由于它们是接口，你可以实现多个方法。

public interface Thrower {public void throwIfCondition(boolean condition, String msg) {// ...}
public void throwAorB(Throwable a, Throwable b, boolean throwA) {    // ...}
}

这样需要使用它的类只需简单的实现下这个接口就可以了。

格式

格式远比许多程序员相像的要重要的多。一致的格式说明你关注自己的代码或者对别人有所帮助？是的。不过你先不要着急为了让代码整齐点而浪费一整天的时间在那给 if 块加空格了。

如果你确实需要一份代码格式规范，我强烈推荐 Google 的 Java 风格指南。这份指南最精彩的部分就是 编程实践 这节了。非常值得一读。

文档

面向用户的代码编写下文档还是很重要的。这意味着你需要提供一些 使用的示例，同时你的变量方法和类名都应该有适当的描述信息。

结论就是不要给不需要文档的地方添加文档。如果对于某个参数你没什么可说的，或者它已经非常明显了，别写文档了。模板化的文档比没有文档更糟糕，因为它欺骗了你的用户，让他觉得这里有文档。

流

Java 8 有一个漂亮的流和 lambda 表达式的语法。你的代码可以这么写：

final List<String> filtered = list.stream()    .filter(s -> s.startsWith("s"))    .map(s -> s.toUpperCase());

而不是这样：

final List<String> filtered = Lists.newArrayList();for (String str : list) {if (str.startsWith("s") {filtered.add(str.toUpperCase());    }}

这样你能写出更连贯的代码，可读性也更强。

部署

正确地部署 Java 程序还是需要点技巧的。现在部署 Java 代码的主流方式有两种：使用框架或者使用自家摸索出来的解决方案，当然那样更灵活。

框架

由于部署 Java 程序并不容易，因此才有了各种框架来用于部署。最好的两个是 Dropwizard 以及 Spring Boot。Play Framework 也可以算是一个部署框架。

这些框架都试图降低部署程序的门槛。如果你是一个 Java 的新手或者你需要快速把事情搞定的话，那么框架就派上用场了。单个 jar 的部署当然会比复杂的 WAR 或者 EAR 部署要更容易一些。

然而，这些框架的灵活性不够，并且相当顽固，因此如果这些框架的开发人员给出的方式不太适合你的项目的话，你只能自己进行配置了。

Maven

备选方案：Gradle。

Maven 仍然是编译，打包，运行测试的标准化工具。还有其它一些选择，比如 Gradle，不过它们的采用程度远不 Maven。如果你之前没用过 Maven，你可以看下这个Maven 的使用示例。

我喜欢用一个根 POM 文件来包含所有的外部依赖。它看起来就像是 这样。这个根 POM 文件只有一个外部依赖，不过如果你的产品很大的话，你可能会有很多依赖。你的根 POM 文件自己就应该是一个项目：它有版本控制，并且和其它的 Java 项目一样进行发布。

如果你觉得为每个外部依赖的修改都给 POM 文件打个标签（tag)有点太浪费了，那是你还没有经历过花了一个星期的时间来跟踪项目依赖错误的问题。

你的所有 Maven 工程都应该包含你的主 POM 文件以及所有的版本信息。这样的话，你能知道公司项目的每个外部依赖所选择的版本，以及所有正确的 Maven 插件。如果你需要引入一个外部依赖的话，大概是这样的：

<dependencies>    <dependency>        <groupId>org.third.party</groupId>        <artifactId>some-artifact</artifactId>    </dependency></dependencies>

如果你需要进行内部依赖的话，应该在项目的段中单独进行维护。不然的话，主 POM 文件的版本号就要疯涨了。

依赖收敛

Java 的一个最好的地方就是有大量的第三方库，它们无所不能。几乎每个 API 或者工具都有相应的 Java SDK，并且可以很容易地引入到 Maven 中来。

所有的这些 Java 库自身可能又会依赖一些特定的版本的其它类库。如果你引入了大量的库，可能会出现版本冲突，比如说像这样：

Foo library depends on Bar library v1.0Widget library depends on Bar library v0.9

你的工程应该引入哪个版本？

有了 Maven 的依赖收敛的插件后，如果你的依赖版本不一致的话，编译的时候就会报错。那么你有两种解决冲突的方案：

• 在 dependencyManagement 区中显式地选择某个版本的 bar。
• Foo 或者 Widget 都不要依赖 Bar。
  到底选择哪种方案取决你的具体情况：如果你想要跟踪某个工程的版本，不依赖它是最好的。另一方面，如果你想要明确一点，你可以自己选择一个版本，不过这样的话，如果更新了其它的依赖，也得同步地修改它。

持续集成

很明显你需要某种持续集成的服务器来不断地编译你的 SNAPSHOT 版本，或者对 Git 分支进行构建。

Jenkins和 Travis-CI 是你的不二选择。

代码覆盖率也很重要，Cobertura有一个不错的 Maven 插件，并且对 CI 支持的也不错。当然还有其它的代码覆盖的工具，不过我用的是 Cobertura。

Maven 库

你需要一个地方来存储你编译好的 jar 包，war 包，以及 EAR 包，因此你需要一个代码仓库。

常见的选择是 Artifactory 或者Nexus。两个都能用，并且各有利弊。

你应该自己进行 Artifactory/Nexus 的安装并且将你的依赖做一份镜像。这样不会由于下载 Maven 库的时候出错了导到编译中断。

配置管理

那现在你的代码可以编译了，仓库也搭建起来了，你需要把你的代码带出开发环境，走向最终的发布了。别马虎了，因为自动化执行从长远来看，好处是大大的。

Chef，Puppet，和 Ansible 都是常见的选择。我自己也写了一个可选方案，Squadron。这个嘛，当然了，我自然是希望你们能下载下它的，因为它比其它那些要好用多了。

不管你用的是哪个工具，别忘了自动化部署就好。

库

可能 Java 最好的特性就是它拥有的这些库了。下面列出了一些库，应该绝大多数人都会用得上。

Java 的标准库，曾经还是很不错的，但在现在看来它也遗漏掉了很多关键的特性。

Apache Commons

Apache Commons 项目 有许多有用的功能。

• Commons Codec 有许多有用的 Base64 或者 16 进制字符串的编解码的方法。别浪费时间自己又写一遍了。
• Commons Lang 是一个字符串操作，创建，字符集，以及许多工具方法的类库。
• Commons IO，你想要的文件相关的方法都在这里了。它有 FileUtils.copyDirectory，FileUtils.writeStringToFile, IOUtils.readLines，等等。

Guava

Guava 是一个非常棒的库，它就是 Java 标准库”所缺失的那部分”。它有很多我喜欢的地方，很难一一赘述，不过我还是想试一下。

• Cache，这是一个最简单的获取内存缓存的方式了，你可以用它来缓存网络访问，磁盘访问，或者几乎所有东西。你只需实现一个 CacheBuilder，告诉 Guava 如何创建缓存就好了。
• 不可变集合。这里有许多类：ImmutableMap, ImmutableList，甚至还有 ImmutableSortedMultiSet，如果这就是你想要的话。
  我还喜欢用 Guava 的方式来新建可变集合：

  // Instead offinal Map<String, Widget> map = new HashMap<String, Widget>();

// You can use
final Map<String, Widget> map = Maps.newHashMap();