[[377171]]

為了應對新工作，筆者在過去兩周一直在重新熟悉一位老朋友：JAVA。我以JAVA開啟了我的軟件事業(yè)，與之共行了兩年半左右的時間。但是隨著容器和微服務的出現(xiàn)，JAVA很快消失了。時至今日，距我上次用Java正經(jīng)寫代碼已有三年。筆者沒想到它會再次出現(xiàn)，尤其是出現(xiàn)在微服務領域。

這是怎么回事?答案很簡單：無處不在的微服務鋪天蓋地。

• 易于擴展
• 高可用性
• 更簡單的代碼庫，不必擔心并發(fā)和多線程
• 容器化帶來的便攜性

所有這些都使人們質(zhì)疑Java(更具體地說是JVM)，更不用提Java最臭名昭著的Spring框架了。

有時，人們沉浸在Kubernetes之類的技術中，感覺Java的時代已是歷史，Java在容器和微服務生態(tài)系統(tǒng)中表現(xiàn)欠佳(軟件可擴展性和高可用性的關鍵)。盡管被Python等語言(筆者現(xiàn)在的首選語言)的簡單和優(yōu)雅所動搖，但作為Java曾經(jīng)的死忠粉，筆者認為Java仍在某些領域有毋庸置疑的優(yōu)勢。

例如，Java有強大的線程功能，筆者職業(yè)生涯的早期就將它們直接用于關鍵銀行應用。雖然將編譯語言與腳本語言的性能指標進行比較并不公平，但Java堅如磐石的性能確實無與倫比。

而對于水平擴展性和微服務體系結構，這種語言固有性能的作用微乎其微，因為人們可以直接產(chǎn)生更多容器來獲得出色的性能。顯然，這些腳本語言，再加上在容器范圍內(nèi)即時放大或縮小的能力，就能使Java打道回府了。筆者確信，Java已死，至少在微服務領域。

在新工作中，筆者進一步確信并痛苦地意識到這種語言有多令人厭惡、煩躁和費解(一部分在于Spring等過時的死板框架)。

Java與Spring的一派正經(jīng)

首先講講臭名昭著的Spring框架。與五年前無異，Spring體積龐大且令人費解，充斥著無窮無盡的注釋，開發(fā)人員每次要么得求助于教程或示例代碼，要么只能研讀Spring提供的冗長文檔。

Spring本就采用了一種很死板的語言，用單行注釋和看似簡化的包裝器加以掩蓋，從而加劇了這個問題的嚴重性，這些包裝器會帶來一堆調(diào)用和類別例示，通常都派不上用場。

所有開發(fā)人員都同意這點：語言的可控性、指令和透明度對是高效開發(fā)軟件的關鍵。簡而言之，開發(fā)人員希望準確了解代碼中發(fā)生了什么以及執(zhí)行了哪些例程(至少是在較高層次上)。但Spring在此有著極大阻礙。

如果必須在類的頂部插入六個各自運行任務注釋，它們在Spring環(huán)境中錯綜復雜地相互聯(lián)系，那你的處境就復雜了。不僅Spring如此，以Lombok庫為例。這是其首頁上第一行描述：

“Lombok項目是一個Java庫，它會自動插入您的編輯器和構建工具中，從而為您的Java增光添彩。無需再編寫另一個getter或equals方法，一個帶有注釋的類將具有功能全面的生成器，自動執(zhí)行日志記錄變量等等。”

壓縮Java代碼的目標不過是照本宣科，不能真正發(fā)揮作用。

Java應該停止匹配腳本語言的簡潔性。第一，這犧牲了Java代碼的一致性：想象返回Java發(fā)現(xiàn)所有的getter和setter都消失了，取而代之的是單行注釋@NoArgsConstructor。這哪還有一致性?

其次，它增加了本就費解的抽象數(shù)組。例如，Spring可以在后臺設置自動裝配(bean注入)，這是可以理解的，但是Lombok在應用程序環(huán)境中位于何處，以及如何協(xié)調(diào)消息?如果每個類都有六個注釋，那么這些注釋還實例化了多少其他例程或類來完成這種簡單的工作?

每個開發(fā)人員都不希望有額外的代碼四處潛伏。然而這就是筆者三年后遇到的Java代碼，沒有任何改變。實際上，微小的變化也只會使情況變得更糟。Java仍然側重于愚蠢的規(guī)則，這些規(guī)則規(guī)定了應使用的類名，所在的包，以及變量是私有的還是受保護的。但根本沒人在乎這些。

相比之下，Python對缺少語言的訪問說明符直接回復：“大家都是成年人了”。這僅僅一行的回復嘲諷意味十足又極具吸引力，它立刻引起了我的共鳴，我過去常常覺得荒謬且無用的概念在它的影響下合理了很多。

保持簡單，程序員們

在軟件行業(yè)，你經(jīng)常能聽到人們說“KISS”：保持簡單(Keep it simple)，傻子們(Stupid)。Java只有認真考慮這點才能生存。

如今，微服務模式在軟件行業(yè)中幾乎無處不在，甚至許多運行古早應用程序的組織也越來越多地替換其舊的整體，以簡化設計并提高可擴展性。對于程序員而言，這意味著將其龐大的代碼庫或復雜的業(yè)務邏輯分解為更簡單、簡潔的功能——一種無需在代碼中進行狀態(tài)管理的范例，從而避免并發(fā)和多線程的問題。

歸根結底，無論何種服務，都只處理某種格式(JSON或XML)的數(shù)據(jù)，然后將它們傳遞到消息總線(如Kafka)以進行進一步處理。即使是這樣簡單的設置中，Java和Spring還在照搬過時又死板的代碼語法：Application Contexts、 bean injections,、autowiring、 POJO mappers、需要大量內(nèi)存的 JVM、討厭的 class loader。

所以，結論是什么?“保持簡單，程序員們!”