重拾JAVA：這種編程語言為什么不行了？
本文轉載自公眾號“讀芯術”(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庫為例。這是其首頁上第一行描述：
“Lombok項目是一個Java庫，它會自動插入您的編輯器和構建工具中，從而為您的Java增光添彩。無需再編寫另一個getter或equals方法，一個帶有注釋的類將具有功能全面的生成器，自動執行日志記錄變量等等。”
壓縮Java代碼的目標不過是照本宣科，不能真正發揮作用。
Java應該停止匹配腳本語言的簡潔性。第一，這犧牲了Java代碼的一致性：想象返回Java發現所有的getter和setter都消失了，取而代之的是單行注釋@NoArgsConstructor。這哪還有一致性?
其次，它增加了本就費解的抽象數組。例如，Spring可以在后臺設置自動裝配(bean注入)，這是可以理解的，但是Lombok在應用程序環境中位于何處，以及如何協調消息?如果每個類都有六個注釋，那么這些注釋還實例化了多少其他例程或類來完成這種簡單的工作?
每個開發人員都不希望有額外的代碼四處潛伏。然而這就是筆者三年后遇到的Java代碼，沒有任何改變。實際上，微小的變化也只會使情況變得更糟。Java仍然側重于愚蠢的規則，這些規則規定了應使用的類名，所在的包，以及變量是私有的還是受保護的。但根本沒人在乎這些。
相比之下，Python對缺少語言的訪問說明符直接回復：“大家都是成年人了”。這僅僅一行的回復嘲諷意味十足又極具吸引力，它立刻引起了我的共鳴，我過去常常覺得荒謬且無用的概念在它的影響下合理了很多。
保持簡單，程序員們
在軟件行業，你經常能聽到人們說“KISS”：保持簡單(Keep it simple)，傻子們(Stupid)。Java只有認真考慮這點才能生存。
如今，微服務模式在軟件行業中幾乎無處不在，甚至許多運行古早應用程序的組織也越來越多地替換其舊的整體，以簡化設計并提高可擴展性。對于程序員而言，這意味著將其龐大的代碼庫或復雜的業務邏輯分解為更簡單、簡潔的功能——一種無需在代碼中進行狀態管理的范例，從而避免并發和多線程的問題。
歸根結底，無論何種服務，都只處理某種格式(JSON或XML)的數據，然后將它們傳遞到消息總線(如Kafka)以進行進一步處理。即使是這樣簡單的設置中，Java和Spring還在照搬過時又死板的代碼語法：Application Contexts、 bean injections,、autowiring、 POJO mappers、需要大量內存的 JVM、討厭的 class loader。
所以，結論是什么?“保持簡單，程序員們!”
