Java 可能很冗长，但是谁在乎呢？

在Java超过15年的经验之后，我倾向于使用以下参数之一而忽略了关于Java冗长性的评论：

• 代码行（LOC）是伪造的指标；
• IDE生成了我Java代码的90％；
• 从PERL臭名昭著、简明扼要的简洁中学到的教训。

LOC指标根本不重要。

还是他们？

不久前，我们开始构建我们的第一个Spark作业。我们写的前两个基本相同：

1. 从HDFS读取CSV文件
2. 将每行转换为JSON
3. 将每个JSON推送到Kafka

碰巧的是，我们用Clojure写了一篇，用Java 写了一篇。当我们查看代码时，这是Java版本的外观：

起初，我惊讶的是有这么多的课程。

然后，我惊讶于发现如此多的课程而感到惊讶。毕竟，该代码是我们所有人都写的完全习惯的Java代码。

但是为什么我首先会感到惊讶？可能是因为Clojure版本看起来像这样：

但是，也许这是一个包含数百行代码的巨大文件？不，只有58行代码。

也许Clojure版本是完全不可读的、到处都是变量和括号的胡言乱语?以下是两个版本之间的主要转换逻辑：

可读性的唯一区别是Java版本具有更多的括号。

代码修订

我通常不会关注Java的冗长性，但是在Java代码审查期间，我发现自己在思考：

• 我应该从哪门课开始?
• 我下一步应该去哪一堂课？
• 各个班级如何融合在一起？
• 依赖图的外观如何？
• 谁实现这些接口？他们有必要吗？
• 每个班级的职责是什么？
• 数据转换在哪里？
• 数据转换正确吗？

尽管Clojure代码审查是关于：

• 数据转换正确吗？

这让我意识到Clojure版本更易于理解，而拥有58行代码的单个文件这一事实是一个非常重要的原因。

bigger项目呢？

我没有任何更大的项目，其要求与此处的要求完全相同，但是确实，我们的Clojure微服务的文件不超过10个，通常为3个或4个，而我们的Java微服务中最简单的是有几十个。

从经验中，我们知道理解具有4个小类的代码库的时间与理解具有50个小类的代码库的时间并不相同。

偶然的复杂性

因此，假设问题的内在复杂性相同，并且Clojure版本能够以58行代码表示解决方案，而Java版本需要441行代码，并且Clojure版本更容易理解，那么完全惯用的Java代码的那383行（占代码库的87％）是关于什么的？

答案是，所有这些额外的代码行都属于附带的复杂性——我们(程序员)由于没有使用正确的工具而造成的复杂性，我们的业务付钱让我们去创建的复杂性，付钱让我们去维护的复杂性，但从来没有真正要求过。

代码行重要吗？并不是用来衡量生产率，而是可以用来衡量复杂性，尤其是当这种复杂性是偶然的而非固有的时。

想象一下，删除您必须维护的所有代码中的87％！

原文链接：https://dev.to//danlebrero/java-maybe-verbose-but-who-cares