结论就是不要给不需要文档的地方添加文档。如果对于某个参数你没什么可说的,或者它已经非常明显了,别写文档了。模板化的文档比没有文档更糟糕,因为它欺骗了你的用户,让他觉得这里有文档。
流
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程序还是需要点技巧的。现在部署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