結論就是不要給不需要文檔的地方添加文檔。如果對于某個參數你沒什么可說的,或者它已經非常明顯了,別寫文檔了。模板化的文檔比沒有文檔更糟糕,因為它欺騙了你的用戶,讓他覺得這里有文檔。
流
Java 8有一個漂亮的流和lambda表達式的語法。你的代碼可以這么寫:
final List filtered = list.stream()
.filter(s -> s.startsWith("s"))
.map(s -> s.toUpperCase());
而不是這樣:
final List filtered = Lists.newArrayList();
for (String str : list) {
if (str.startsWith("s") {
filtered.add(str.toUpperCase());
}
}
這樣你能寫出更連貫的代碼,可讀性也更強。
部署
正確地部署Java程序還是需要點技巧的?,F在部署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插件。如果你需要引入一個外部依賴的話,大概是這樣的:
org.third.party
some-artifact
如果你需要進行內部依賴的話,應該在項目的段中單獨進行維護。不然的話,主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。
Foo或者Widget都不要依賴Bar。
到底選擇哪種方案取決你的具體情況: 如果你想要跟蹤某個工程的版本,不依賴它是最好的。另一方面,如果你想要明確一點,你可以自己選擇一個版本,不過這樣的話,如果更新了其它的依賴,也得同步地修改它。
持續集成
很明顯你需要某種持續集成的服務器來不斷地編譯你的SNAPSHOT版本,或者對Git分支進行構建。
Jenkins和Travis-CI是你的不二選擇。
代碼覆蓋率也很重要,Cobertura有一個不錯的Maven插件,并且對CI支持的也不錯。當然還有其它的代碼覆蓋的工具,不過我用的是Cobertura。
Maven庫
你需要一個地方來存儲你編譯好的jar包,war包,以及EAR包,因此你需要一個代碼倉庫。
常見的選擇是Artifactory或者Nexus。兩個都能用,并且各有利弊。
你應該自己進行Artifactory/Nexus的安裝并且將你的依賴做一份鏡像。這樣不會由于下載Maven 庫的時候出錯了導到編譯中斷。
原文轉自:http://it.deepinmind.com/java/2014/05/21/better-java.html