為了在新工作中更好地與技術(shù)堆棧保持一致，過去兩周我一直在和一個老朋友Java進(jìn)行自我重新認(rèn)識。不久之前，它以無與倫比的熱情和活力開始了我的軟件事業(yè)。這一過程持續(xù)了大約兩年半的時間，但是隨著容器和微服務(wù)的出現(xiàn)而很快消失。到今天，距我上次編寫任何嚴(yán)肅的Java代碼已經(jīng)三年了。老實說，我從沒想到它會再次出現(xiàn)，尤其是在微服務(wù)領(lǐng)域。

[[358793]]

所以發(fā)生了什么事?答案很簡單：微服務(wù)無所不在的浪潮席卷了我們。

• 易于擴(kuò)展
• 高可用性
• 無需擔(dān)心并發(fā)和多線程的簡化代碼庫
• 容器化帶來了可移植性

所有這些因素促使我們質(zhì)疑Java(更具體地說是JVM)的功效，更不用說Java最臭名昭著的框架Spring了。

有時，人們沉浸在Kubernetes之類的技術(shù)中，感覺Java的時代已經(jīng)過去，并且在容器和微服務(wù)生態(tài)系統(tǒng)中的表現(xiàn)不佳(這是軟件可擴(kuò)展性和高可用性的關(guān)鍵)。但是，作為曾經(jīng)堅定支持Java的人-盡管一直受到Python之類的語言(現(xiàn)在已經(jīng)成為我的首選語言)的簡單和優(yōu)雅的影響，但我仍然繼續(xù)為Java不可否認(rèn)的某些領(lǐng)域保留一席之地優(yōu)點。

例如，我很清楚Java強(qiáng)大的線程功能，在我的職業(yè)生涯初期就將它們直接用于關(guān)鍵銀行應(yīng)用程序。雖然將編譯語言的性能指標(biāo)與腳本語言的性能指標(biāo)進(jìn)行比較是不公平的，但Java堅如磐石的性能卻無與倫比。

但是在水平可伸縮性和微服務(wù)體系結(jié)構(gòu)的世界中，這種語言的固有性能太重要了，因為人們可以簡單地產(chǎn)生更多的容器來獲得出色的性能。顯然，這些腳本語言以及它們在容器領(lǐng)域中即時放大或縮小的能力，使Java物有所值。我一勞永逸地確信Java已經(jīng)完成了(至少在微服務(wù)領(lǐng)域如此)。我是對的!

在我的新工作中，這些信念僅得到進(jìn)一步加強(qiáng)，使我感到痛苦的是，我意識到這種語言變得多么令人討厭，煩躁和令人費解-部分原因是由于Spring等過時的儀式框架。

Java和Spring的儀式

讓我們從臭名昭著的Spring框架開始。

與五年前相比，Spring是如此龐大且令人費解，充斥著無窮無盡的注解，這些注解使開發(fā)人員每次需要完成工作時就只能依靠教程或示例代碼。細(xì)讀Spring自己詳盡的文檔既是艱巨的任務(wù)，又是艱巨的任務(wù)。

實際上，我最喜歡的是像Spring這樣的框架，而不是Java本身。Spring采用了一種已經(jīng)很禮貌的語言，用單行注解和看似簡化的包裝器對其進(jìn)行掩蓋，從而加劇了這個問題，這些包裝器最終召喚出了通常不需要的類的調(diào)用和實例化的狂歡。正如任何開發(fā)人員都會同意的那樣，語言的控制，命令和透明性對于有效的軟件開發(fā)至關(guān)重要。簡而言之，作為一名開發(fā)人員，想準(zhǔn)確地了解代碼中發(fā)生了什么以及執(zhí)行了哪些例程-至少是在較高層次上。但是Spring在這方面痛苦地阻止了你。

如果必須在類的頂部放置六個注解，而每個注解都在做自己的事情，并且在Spring上下文的網(wǎng)格中錯綜復(fù)雜地相互聯(lián)系，那么你將處于一片模糊的境地。這不僅是Spring。以Lombok庫為例。這是其首頁上宣傳的第一線：

壓縮Java代碼的這種反常的目標(biāo)令人沮喪，并且痛苦地針對該語言進(jìn)行工作，而不是做任何真正的事。

Java應(yīng)該簡單地停止嘗試與腳本語言的簡潔性相匹配。首先，這犧牲了Java代碼的一致性：想象回到Java只是發(fā)現(xiàn)所有的getter和setter都消失了(我們曾經(jīng)學(xué)過的知識對于Spring自動裝配很重要)，現(xiàn)在已被單行注釋@NoArgsConstructor取代。一致性在哪里?

其次，它增加了已經(jīng)令人費解的抽象數(shù)組。例如，在這里，Spring可以在后臺設(shè)置自動裝配(bean注入)，這是可以理解的，但是Lombok在應(yīng)用程序上下文中位于何處，以及如何在兩者之間協(xié)調(diào)消息傳遞?如果我的每個類都有六個注解，那么這些注解還實例化了多少其他例程或類來完成這一簡單的工作?沒有真正的開發(fā)人員會希望將所有這些額外的代碼潛伏在角落。可悲的是，這是三年后我遇到的那種Java代碼。沒有一件事情發(fā)生改變。實際上，即使發(fā)生的微小變化也只會使情況變得更糟。

Java仍將重點放在愚蠢的規(guī)則上，這些規(guī)則規(guī)定了應(yīng)使用的類名，應(yīng)使用的包以及變量是私有的還是受保護(hù)的。說真的，誰在乎?

相反，"我們都是成年人"實際上是Python對該語言中缺少訪問說明符的官方回應(yīng)。這種嘲諷而引人入勝的單行回應(yīng)立刻引起了我的共鳴。最終，它使我經(jīng)常覺得是荒謬且不必要的概念更為理智。

保持簡單，愚蠢 KISS

如果您在軟件行業(yè)一次又一次地聽到一件事，那就是KISS的首字母縮寫：保持簡單，愚蠢。如果Java要生存，這是需要認(rèn)真考慮的事情。

如今，微服務(wù)模式已在軟件行業(yè)中幾乎普及。甚至許多運行舊版應(yīng)用程序的組織也越來越多地替換其舊的整體，以簡化設(shè)計并提高可伸縮性。對于程序員而言，這意味著將其龐大的代碼庫或復(fù)雜的業(yè)務(wù)邏輯分解為更簡單，簡潔的功能-一種無需在代碼中進(jìn)行狀態(tài)管理的范例，從而免除了并發(fā)問題和多線程噩夢。

歸根結(jié)底，所有服務(wù)，無論是某種形式或形式，都只處理某種格式(JSON或XML)的數(shù)據(jù)，然后將它們傳遞到消息總線(如Kafka)以進(jìn)行進(jìn)一步處理。甚至在這樣簡單的設(shè)置中，Java和Spring仍在反駁禮節(jié)性代碼語法，應(yīng)用程序上下文，復(fù)雜的bean注入，自動裝配，POJO映射器，內(nèi)存消耗巨大的JVM和臭名昭著的類加載器的過時修辭。毫無意義地應(yīng)對。

判決?"保持簡單，愚蠢!"