为了在新工作中更好地与技术堆栈保持一致，过去两周我一直在和一个老朋友Java进行自我重新认识。不久之前，它以无与伦比的热情和活力开始了我的软件事业。这一过程持续了大约两年半的时间，但是随着容器和微服务的出现而很快消失。到今天，距我上次编写任何严肃的Java代码已经三年了。老实说，我从没想到它会再次出现，尤其是在微服务领域。
所以发生了什么事?答案很简单：微服务无所不在的浪潮席卷了我们。
- 易于扩展
- 高可用性
- 无需担心并发和多线程的简化代码库
- 容器化带来了可移植性
所有这些因素促使我们质疑Java(更具体地说是JVM)的功效，更不用说Java最臭名昭著的框架Spring了。
有时，人们沉浸在Kubernetes之类的技术中，感觉Java的时代已经过去，并且在容器和微服务生态系统中的表现不佳(这是软件可扩展性和高可用性的关键)。但是，作为曾经坚定支持Java的人-尽管一直受到Python之类的语言(现在已经成为我的首选语言)的简单和优雅的影响，但我仍然继续为Java不可否认的某些领域保留一席之地优点。
例如，我很清楚Java强大的线程功能，在我的职业生涯初期就将它们直接用于关键银行应用程序。虽然将编译语言的性能指标与脚本语言的性能指标进行比较是不公平的，但Java坚如磐石的性能却无与伦比。
但是在水平可伸缩性和微服务体系结构的世界中，这种语言的固有性能太重要了，因为人们可以简单地产生更多的容器来获得出色的性能。显然，这些脚本语言以及它们在容器领域中即时放大或缩小的能力，使Java物有所值。我一劳永逸地确信Java已经完成了(至少在微服务领域如此)。我是对的!
在我的新工作中，这些信念仅得到进一步加强，使我感到痛苦的是，我意识到这种语言变得多么令人讨厌，烦躁和令人费解-部分原因是由于Spring等过时的仪式框架。
Java和Spring的仪式
让我们从臭名昭著的Spring框架开始。
与五年前相比，Spring是如此庞大且令人费解，充斥着无穷无尽的注解，这些注解使开发人员每次需要完成工作时就只能依靠教程或示例代码。细读Spring自己详尽的文档既是艰巨的任务，又是艰巨的任务。
实际上，我最喜欢的是像Spring这样的框架，而不是Java本身。Spring采用了一种已经很礼貌的语言，用单行注解和看似简化的包装器对其进行掩盖，从而加剧了这个问题，这些包装器最终召唤出了通常不需要的类的调用和实例化的狂欢。正如任何开发人员都会同意的那样，语言的控制，命令和透明性对于有效的软件开发至关重要。简而言之，作为一名开发人员，想准确地了解代码中发生了什么以及执行了哪些例程-至少是在较高层次上。但是Spring在这方面痛苦地阻止了你。
如果必须在类的顶部放置六个注解，而每个注解都在做自己的事情，并且在Spring上下文的网格中错综复杂地相互联系，那么你将处于一片模糊的境地。这不仅是Spring。以Lombok库为例。这是其首页上宣传的第一线：
| " Project Lombok是一个Java库，它会自动插入你的编辑器和构建工具中，从而为你，的Java增光添彩。永远不要再编写另一个getter或equals方法，带有一个注释的类将具有功能齐全的生成器，自动执行日志记录变量等等。" |
压缩Java代码的这种反常的目标令人沮丧，并且痛苦地针对该语言进行工作，而不是做任何真正的事。
Java应该简单地停止尝试与脚本语言的简洁性相匹配。首先，这牺牲了Java代码的一致性：想象回到Java只是发现所有的getter和setter都消失了(我们曾经学过的知识对于Spring自动装配很重要)，现在已被单行注释@NoArgsConstructor取代。一致性在哪里?
其次，它增加了已经令人费解的抽象数组。例如，在这里，Spring可以在后台设置自动装配(bean注入)，这是可以理解的，但是Lombok在应用程序上下文中位于何处，以及如何在两者之间协调消息传递?如果我的每个类都有六个注解，那么这些注解还实例化了多少其他例程或类来完成这一简单的工作?没有真正的开发人员会希望将所有这些额外的代码潜伏在角落。可悲的是，这是三年后我遇到的那种Java代码。没有一件事情发生改变。实际上，即使发生的微小变化也只会使情况变得更糟。
Java仍将重点放在愚蠢的规则上，这些规则规定了应使用的类名，应使用的包以及变量是私有的还是受保护的。说真的，谁在乎?
相反，"我们都是成年人"实际上是Python对该语言中缺少访问说明符的官方回应。这种嘲讽而引人入胜的单行回应立刻引起了我的共鸣。最终，它使我经常觉得是荒谬且不必要的概念更为理智。
保持简单，愚蠢 KISS
如果您在软件行业一次又一次地听到一件事，那就是KISS的首字母缩写：保持简单，愚蠢。如果Java要生存，这是需要认真考虑的事情。
如今，微服务模式已在软件行业中几乎普及。甚至许多运行旧版应用程序的组织也越来越多地替换其旧的整体，以简化设计并提高可伸缩性。对于程序员而言，这意味着将其庞大的代码库或复杂的业务逻辑分解为更简单，简洁的功能-一种无需在代码中进行状态管理的范例，从而免除了并发问题和多线程噩梦。
归根结底，所有服务，无论是某种形式或形式，都只处理某种格式(JSON或XML)的数据，然后将它们传递到消息总线(如Kafka)以进行进一步处理。甚至在这样简单的设置中，Java和Spring仍在反驳礼节性代码语法，应用程序上下文，复杂的bean注入，自动装配，POJO映射器，内存消耗巨大的JVM和臭名昭著的类加载器的过时修辞。毫无意义地应对。
判决?"保持简单，愚蠢!"
