本文转载自公众号《读书芯》（ID：AI_Discovery）为了应对新的工作，笔者这两周重新认识了一个老朋友：JAVA。我从JAVA开始了我的软件生涯，并且已经使用了大约两年半。但是随着容器和微服务的出现，JAVA很快就消失了。今天，距我上次用Java编写正式代码已经三年了。没想到它又出现了，尤其是在微服务领域。这里发生了什么？答案很简单：微服务无处不在。易于扩展高可用性更简单的代码库，无需担心并发和多线程通过容器化实现的可移植性所有这些都让人质疑Java（更具体地说是JVM），更不用说Java最臭名昭著的Spring框架了。有时，沉浸在Kubernetes等技术中的人们觉得Java的时代已经成为历史，而Java在容器和微服务生态系统（软件可扩展性和高可用性的关键）中表现不佳。尽管被Python（我目前选择的语言）这样的语言的简洁和优雅所折服，但作为曾经的Java死忠粉，我认为Java在某些领域仍然有着毋庸置疑的优势。例如，Java具有强大的线程功能，我在职业生涯早期直接将它们用于关键的银行应用程序。虽然将编译语言的性能指标与脚本语言进行比较是不公平的，但Java坚如磐石的性能确实是无与伦比的。对于水平可扩展性和微服务架构，这种语言固有的性能几乎没有帮助，因为可以简单地生成更多容器来获得出色的性能。显然，这些脚本语言与在容器内动态放大和缩小的能力相结合，将把Java带回家。作者坚信Java已经死了，至少在微服务领域是这样。在我的新工作中，我进一步确信并痛苦地意识到这种语言是多么令人厌恶、令人恼火和难以理解（部分原因是Spring等过时的僵化框架）。Java与Spring的严肃性首先说说臭名昭著的Spring框架。就像五年前一样，Spring庞大而复杂，充斥着没完没了的注释，开发者要么每次都求助于教程或示例代码，要么只能研究Spring提供的冗长文档。Spring加剧了这个问题，因为它采用了一种固有的死板语言，被单行注释和看似简化的包装器所掩盖，这些包装器带来了一堆调用和类实例化，通常发送无用。所有开发人员都同意这一点：语言控制、指令和透明度是高效软件开发的关键。简而言之，开发人员想要确切地知道代码中发生了什么以及执行了哪些例程（至少在较高级别）。但是Spring在这里有很大的障碍。如果您必须在类的顶部插入六个单独的运行任务注释，这些注释在Spring环境中错综复杂地相互关联，那么您的处境就很复杂了。不仅是Spring，以Lombok库为例。这是其首页上的第一行描述：“ProjectLombok是一个Java库，它会自动插入您的编辑器并构建工具来为您的Java添加光彩。无需编写另一个getter或equals方法，一个带注释的类将具有全功能生成器、自动记录变量等。”缩小Java代码的目标不仅仅是脚本化的，而且并没有真正起作用。Java应该停止匹配脚本语言的简单性。首先，它牺牲了Java代码的一致性：想象一下返回到Java发现所有的getter和setter都消失了，取而代之的是单行注释@NoArgsConstructor。这怎么能保持一致呢？其次，它增加了已经很复杂的抽象数组。比如Spring可以在后台设置autowiring（bean注入），这无可厚非，但是Lombok在应用环境中处于什么位置，它又是如何协调消息的呢？有多少其他例程或类被实例化来做这么简单的事情？每个开发人员都不希望有额外的代码潜伏在周围。然而，这是我三年后遇到的Java代码，没有任何改动。事实上，微小的改变只会让事情变得更糟。Java仍然专注于愚蠢的规则，这些规则规定应该使用什么类名，它应该在什么包中，以及变量应该是私有的还是受保护的。但根本没有人关心这一点。相比之下，Python对缺少一种语言的访问说明符的直接答复是：“每个人都是成年人”。一句话的回复既讽刺又迷人，它立即引起了我的共鸣，让我以前认为荒谬和无用的概念有了很多意义。Keepitsimple,programmers在软件行业，你经常听到人们说“KISS”：保持简单（Keepitsimple），笨蛋（Stupid）。Java只有认真对待这一点才能生存。如今，微服务模式在软件行业几乎无处不在，甚至许多运行古老应用程序的组织也越来越多地更换其遗留的单体应用程序，以简化设计并提高可扩展性。对于程序员来说，这意味着将他们庞大的代码库或复杂的业务逻辑分解成更简单、简洁的函数——一种不需要在代码中进行状态管理的范式，从而避免并发和多线程的问题。归根结底，无论服务是什么，它都只是处理某种格式（JSON或XML）的数据，然后将它们传递给消息总线（例如Kafka）进行进一步处理。即使在这样一个简单的设置中，Java和Spring仍然在复制过时和严格的代码语法：应用程序上下文、bean注入、自动装配、POJO映射器、需要大量内存的JVM、讨厌的类加载器。那么，结论呢？“保持简单，程序员！”
