Java 的最佳實踐
Java 的最佳實踐
Java 是在世界各地最流行的編程語言之一, 但是看起來沒人喜歡使用它。而 Java 事實上還算是一門不錯的語言，隨著 Java 8 最近的問世，我決定編制一個庫，實踐和工具的清單，匯集 Java 的一些最佳實踐。
本文被放到了 Github 上。你可以隨意地提交貢獻，并加入自己的有關 Java 方面的建議和最佳實踐。
-
風格
-
Javadoc
-
構建器模式
-
結構
-
依賴注入
-
避免空值
-
默認不可變更
-
避免大量的工具類
-
格式化
-
流
-
發布
-
依賴收斂
-
框架
-
Maven
-
持續集成
-
Maven 資源庫
-
配置管理
-
庫
-
jUnit 4
-
jMock
-
AssertJ
-
Apache Commons
-
Guava
-
Gson
-
Java Tuples
-
Joda-Time
-
Lombok
-
Play framework
-
SLF4J
-
jOOQ
-
Missing Features
-
Testing
-
工具
-
Chronon
-
IntelliJ IDEA
-
JRebel
-
Checker 框架
-
Eclipse 內存分析器
-
資源
-
書籍
-
播客
風格
通常，我們會以一種非常詳細繁雜的企業級 JavaBean 的風格進行 Java 代碼的編寫。新的風格則更加清晰，正確，且看上去也更加的簡單。
結構
作為程序員的我們要做的最簡單的事情之一，就是傳遞數據。一般的方式就是定義一個 JavaBean：
public class DataHolder {
private String data;
public DataHolder() {
}
public void setData(String data) {
this.data = data;
}
public String getData() {
return this.data;
}} 這有點麻煩，并且也有點浪費。盡管你的 IDE 也能自動的生成這樣的代碼，但那也是種浪費。所以，別這么做。
相反，我更愿意選擇編寫類 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 static 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(); 還有其它關于構建器的更好的例子 ，而這里提供給你淺嘗輒止。這樣做最終會得到許多的我們努力去避免的樣板式代碼，不過這也讓你得到了不可變的對象和一個非常流暢的接口。
依賴注入
這是更偏向軟件工程而不是 Java 的一節。編寫可測試軟件的最佳方式之一就是使用依賴注入(DI)。因為 Java 非常鼓勵 OO 設計，為了創造出可測試的軟件，你需要使用DI。
在 Java 中，一般使用 Spring 框架 的 DI 實現。它同時支持基于代碼的裝配和基于 XML 配置的裝配。 如果你使用的是 XML 配置，因為其基于 XML 的配置， 不去過分使用 Spring 這一點很重要。XML 中絕對不能有任何邏輯或者控制結構，只能用來注入依賴。
使用 Spring 的好的選擇就是 Google 和 Square 的 Dagger 庫以及Google 的 Guice。他們不使用 Spring 的 XML 配置文件格式，而是將依賴邏輯放到注解和代碼中。
避免空值
盡你所能避免空值。如果你可以返回一個空的集合，就不要返回一個空值。如果你要使用空值，就考慮使用 @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<Bar> bar) {
this.data = data;
this.bar = bar;
}
public Optional<Bar> getBar() {
return bar;
}} 這樣現在就能很確定數據永遠都不會是空值了, 不過 bar 可能存在也可能不存在。Optional 有一些諸如 isPresent 這樣的方法，這使得其感覺跟只檢查空值的做法小同大異。但是它能讓你寫出像下面這樣的語句:
final Optional<FooWidget> fooWidget = maybeGetFooWidget(); final Baz baz = fooWidget.flatMap(FooWidget::getBar) .flatMap(BarWidget::getBaz) .orElse(defaultBaz);
這樣就比鏈條時的 if 空值檢查看起來好多了。使用 Optional 的唯一缺陷就是標準庫并沒有對 Optional 有很好的支持，因此針對空值的處理還是需要的。
默認不可被改變
除非你有一個好的理由要這樣做，那么變量、類和集合都是不應該被修改的。
變量的引用可以用 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，或者 ImmutableSet 類。這些都擁有構建器，因此你可以動態地構建它們，并通過調用 build 方法來將它們標記為不可變。
類應該（通過 final）聲明其屬性域不可變和使用不可變的集合而變成不可變的。你也可以選擇使得類自身為 final，那樣它就不能被擴展和被改變了。
避免許多的工具類
在你發現自己添加了太多的方法到一個工具類中時要小心。
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 {
default void throwIfCondition(boolean condition, String msg) {
// ...
}
default void throwAorB(Throwable a, Throwable b, boolean throwA) {
// ...
}} 然后每個有需要的類都可以簡單的實現這個接口。
格式化
格式化比起大多數程序員所認為的更加不被重視。那么它是不是同你對于自己技術水平的在意目標一致，還有是不是能有助于其他人的對于代碼的解讀呢？當然是。但我們也不要浪費一整天加空格來使得 if 的括號能“匹配”。
如果你絕對需要一個代碼格式手冊，我強烈推薦 Google 的 Java 代碼風格 指南。該指南的最佳部分就是編程實踐這一節。絕對值得一讀.
Javadoc
為你的用戶所要面對的代碼加注文檔是很重要的。而這就意味著要使用示例和對于變量、方法和類的極值描述。
這樣做的必然結果就是對于不需要加注文檔的就不要去加注文檔. 如果就一個參數代表的是什么你不想多費口舌，因為答案很明顯，就不要為其加注文檔。樣板一樣的文檔比沒有文檔更糟糕，因為這對于會思考此處為何要加注的文檔的用戶而言這會是一種戲弄。
流
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 框架 也可以被考慮也作為這些部署框架的其中之一。
它們全都試圖降低讓你的代碼發布出去的門檻. 它們在你是名Java新手或者希望能快速運行起來時特別有幫助. 單個的JAR部署比復雜的WAR和EAR部署更簡單.
不過，它們可能不怎么靈活，而且詳單笨拙，因此如果你的項目不適合框架開發者為你的框架所做出選擇，你就得自己集成一個更加手動的配置了。
Maven
好的選擇： Gradle。
Maven 讓然是構建，打包并運行你的測試的標準工具。不過還有其它可選項，比如 Gradle，但是它們并不像Maven那樣為人們所接受。如果你是Maven新手，你應該通過 示例 來上手Maven.
我喜歡能有一個根 POM，里面有你想要使用的所有的外部依賴包。它看起來像是 這樣的。這個根 POM 只有一個外部依賴，而如果你自己的項目足夠大，就會有很多個。你的根 POM 自身可能也是一個項目：收到版本控制中并且像其它的 Java 項目那樣進行發布。
如果你想過要為你的根POM標記出的每一個外部依賴的變化太多了，你不必浪費一個星期去跟蹤調試多個項目的依賴錯誤。
你的所有的 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.0 Widget library depends on Bar library v0.9
哪個版本會引入到你的項目中呢?
使用 Maven 的依賴收斂插件, 構建就會在你的依賴沒有使用相同的版本時報錯。之后要解決沖突，你可以有兩種選擇：
-
在你的dependencyManagement 一節為Bar明確挑選一個版本
-
將 Bar 從 Foo 或者 Widget 中排除出去
選擇哪種方案要視你的情形而定：如果你想要跟蹤一個項目的版本，那么就用排除的方案。另外一方面，如果你想要明確的指定它，你就可以挑選一個版本，雖然你將需要在更新其它依賴的同時對它進行更新。
持續集成
顯然你需要一些持續集成的服務來讓你連續不斷地建立你的 SNAPSHOT（快照）版本和建立基于 git 標簽的 tag。
代碼覆蓋率測試是有用的，并且 Cobertura 有一個很好的 Maven 插件 并對 CI 提供支持。還有其他 Java 的代碼覆蓋率工具，但我是使用 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 是針對 String 的創建和操作，字符集以及一堆實用工具方法的庫。
Commons IO 擁有你可以想象得到的所有文件相關的方法。它有 FileUtils.copyDirectory，FileUtils.writeStringToFile，IOUtils.readLines 以及更多的東西。
Guava
Guava 是 Google 的優秀的補充Java所缺的庫。幾乎很難提交我所喜歡的有關于這個庫的所每個功能，但我會試試。
Cache 是獲取一個內存緩存的簡單方法，可以被用來緩存網絡訪問，磁盤訪問，記憶函數或者任何實在的數據。只要實現一個 CacheBuilder 就能告訴 Guava 如何去構建你的緩存，一切盡在你的掌握之中 !
Immutable 集合。有一堆這樣東西 : ImmutableMap,ImmutableList, 或者如果那是你的風格的話，就還有 ImmutableSortedMultiSet .
我也喜歡用 Guava 的方式編寫不可變的集合：
// Instead of final Map<String, Widget> map = new HashMap<String, Widget>(); // You can use final Map<String, Widget> map = Maps.newHashMap();
還有針對 Lists, Maps, Sets 以及更多集合的靜態類。 他們更清晰和可讀。
如果你還在 Java 6 或者 7 的坑里面, 你可以使用 Collections2 類, 它擁有像 filter 和 transform 這樣的方法. 能讓你在沒有 Java 8 對流的支持下寫出流暢的代碼。
Guava 也有一些簡單的東西， 比如 Joiner 能用分隔符將字符串連接起來，以及一個通過忽略它們來 處理中斷的類.
Gson
Google的Gson 庫是一個簡單快速的JSON轉換庫。像下面這樣運作：
final Gson gson = new Gson(); final String json = gson.toJson(fooWidget); final FooWidget newFooWidget = gson.fromJson(json, FooWidget.class);
相當簡單且令人愉悅。Gson用戶手冊 有許多的示例。
Java Tuples
Java經常令我頭疼的一點就是他的標準庫里面并沒有內置元組。幸運的是， Java tuples 項目解決了這個問題。
它易于使用而且表現很棒：
Pair<String, Integer> func(String input) {
// something...
return Pair.with(stringResult, intResult);} Joda-Time
Joda-Time 是我所使用過的最棒的時間庫. 簡答，直接，易于測試. 夫復何求?
所以你只要在如果沒有使用Java8時使用這個庫，因為Java8有了新的 日期時間 庫。
Lombok
Lombok 是一個有趣的庫。它能通過注解讓你減少 Java 所嚴重遭受的樣板式代碼。
想要為你的類變量加入設置器和獲取器？ 簡單：
public class Foo {
@Getter @Setter private int var;} 現在你可以這樣做:
final Foo foo = new Foo();foo.setVar(5);
還有 更多的東西。我還沒有將 Lombok 用于生產環境，但我迫不及待的想要這么做了。
Play framework
在Java中實現 RESTful web 服務又兩個主要的陣營 : JAX-RS 和其余一切。
JAX-RS 是傳統的方式。你可以使用諸如Jersey之類的東西來將注解結合接口和實現來組織 web 服務。這里有意思的是你可以簡單的從接口類創建出客戶端。
Play framework 是 JVM 的 web服務的一個異類：你會有一個路由文件，然后你要編寫在這些路由中被引用的類。它實際上是一個完整的 MVC 框架, 但是你可以簡單地只把他用于 REST web 服務。
它在 Java 和 Scala 上都能用。它稍有偏向 Scala 優先，不過在Java中也還好.
如果你用過Python中向Flash這樣的微型框架， 你就能熟悉 Spark。它在 Java 8 上能運行得很好。
SLF4J
有許多Java日志的解決方案。我喜歡的就是 SLF4J 因為它的極度的可插入性，并且可以同時結合來自不同日志框架的日志. 有沒有過一個使用了 java.util.logging, JCL, 以及 log4j 的古怪項目? SLF4J 為你而生。
兩頁篇幅的操作手冊 就是你入門所需要的。
jOOQ
我不想換重量級的 ORM 框架，因為我喜歡 SQL。因此我寫了許多 JDBC 模板， 而這樣就有點難以維護。 jOOQ 是一個更好的解決方案。
他能讓你用 Java 以一種更加類型安全的方式編寫SQL:
// Typesafely execute the SQL statement directly with jOOQ Result<Record3<String, String, String>> result = create.select(BOOK.TITLE, AUTHOR.FIRST_NAME, AUTHOR.LAST_NAME) .from(BOOK) .join(AUTHOR) .on(BOOK.AUTHOR_ID.equal(AUTHOR.ID)) .where(BOOK.PUBLISHED_IN.equal(1948)) .fetch();
使用這個和 DAO 模式, 你可以使得訪問數據庫變得輕而易舉。
測試
測試對于你的軟件至關重要。這些包能使得測試更簡單。
jUnit 4
jUnit 不需要介紹了。它是Java中單元測試的標準工具.
而你可能不會發揮 jUnit 的全部潛能。jUnit 支持 參數化測試,，讓你不用編寫過多樣板代碼的 規則，隨機測試特定代碼的 理論， 以及 假設。
jMock
如果依賴注入那塊你弄好了的話，這時候它就能發揮點作用了 : 模擬那些有副作用的代碼 (比如同一個REST服務器進行交互) 并且仍然可以對調用它的代碼進行斷言。
jMock 是標準的Java模擬工具。它看起來像這樣:
public class FooWidgetTest {
private Mockery context = new Mockery();
@Test
public void basicTest() {
final FooWidgetDependency dep = context.mock(FooWidgetDependency.class);
context.checking(new Expectations() {{
oneOf(dep).call(with(any(String.class)));
atLeast(0).of(dep).optionalCall();
}});
final FooWidget foo = new FooWidget(dep);
Assert.assertTrue(foo.doThing());
context.assertIsSatisfied();
}} 這里通過 jMock 設置了一個 FooWidgetDependency，然后加入了一個預期（ expectation）。我們預期 dep 的 call 方法會使用某個字符串被調用一次并且 dep 的 optionalCall 方法會被調用0到多次。
如果你要一次又一次設置相同的依賴，你可能應該將那些放到一個 測試夾具（est fixture）中，并將 assertIsSatisfied 放到一個 @After 夾具中。
AssertJ
你曾經用 jUnit 這樣做過嗎?
final List<String> result = some.testMethod();
assertEquals(4, result.size());
assertTrue(result.contains("some result"));
assertTrue(result.contains("some other result"));
assertFalse(result.contains("shouldn't be here")); 這都是煩人的樣板代碼。 AssertJ 會把這些都干掉。你可以將同樣的代碼轉換成這樣：
assertThat(some.testMethod()).hasSize(4)
.contains("some result", "some other result")
.doesNotContain("shouldn't be here"); 這樣流暢的接口讓你的測試更加可讀. 夫復何求?
工具
IntelliJ IDEA
最好的Java IDE是 IntelliJ IDEA。 它有大量超贊的功能特性，并且真正讓開發 Java 相關的所有細節都暴露無遺。自動補全很棒， 檢查也是頂尖的，還有重構工具真的很有幫助。
免費的社區版本對我而言已經很好的，而旗艦版本則還有許多很棒的功能，比如數據庫工具，對 Spring Framework 和 Chronon 的支持。
Chronon
我最喜愛的 GDB 7 的一個功能就是調試的時候可以倒著走。這在你獲取到旗艦版本并且使用了 Chronon IntelliJ 插件 時是可能的。
你可以獲取到變量的歷史，后退，方法的歷史以及更多其它的東西。初次使用會有點點怪，但它能幫助你解決一些非常復雜的問題,諸如此類的海森堡 bug。
JRebel
持續集成常常是軟件即服務產品的目標。如果你不想等待編譯構建結束就看到代碼變化所產生的效果呢？
那正是 JRebel 所要做的。一旦你把你的服務器掛到了你的 JRebel 客戶端，你就可以實時看見服務器上的變化. 當你想要快速地進行試驗時這能節省大量的時間。
檢查框架（Checker Framework）
Java 的類型系統很不咋地. 它不能區分字符串和實際上是正則表達式的字符串，也沒有做 壞點檢查。不過， Checker Framework 能做到并且能做到更多。
它使用像 @Nullable 這樣的注解來檢查類型. 你甚至可以 自己定義注解 來是的靜態分析如虎添翼。
Eclipse 內存分析器
即使是在Java中，內存也會發生泄漏。幸運的是，有針對這個問題的工具。我用過的最好的解決這些問題的工具就是 Eclipse 內存分析器。它能獲取到堆棧，讓你可以找出問題何在。
有幾種方法可以獲取到一個 JVM 進程的堆棧 , 而我使用的是 jmap:
$ jmap -dump:live,format=b,file=heapdump.hprof -F 8152 Attaching to process ID 8152, please wait... Debugger attached successfully. Server compiler detected. JVM version is 23.25-b01 Dumping heap to heapdump.hprof ... ... snip ... Heap dump file created
之后你就可以用內存分析器打開 heapdump.hprof 文件，并快速的看到到底發生了什么.
資源
能幫助你成為 Java 大師的資源