Java程式設計師的錯

　　編者注：可以噴語言，但不要搞人身攻擊！ BTW：我也是一名 Java 程式設計師！

　　Java程式設計師是有問題的。我使用Java程式設計已經有10多年的歷史。同時，我還有過大量的使用其它語言開發的經歷，比如C#， C， C++， Python， Lua， Objective-C等等，我認為這些經歷在對我認識Java程式設計師的問題上起到了巨大的幫助。很多人說Java是一種很糟糕的程式語言。我不同意。Java語言有它自己的缺點，但我想，很多時候，當你看到Java在有些地方讓人很多人不爽時，那本質上不是Java語言的問題，而是它被錯誤的使用。

　　這些年來，在我見過的各種Java程式碼中，我發現這最大的問題是，寫程式碼的人痴迷於把自己當作架構師。他們很喜歡這樣，在我閱讀他們的程式碼時，經常會發現這些程式碼與其說是去真正的解決一個問題，事實上更像是為了解決一個問題而規劃的一個藍圖模板。這兩者之間並不是細微的差別。你會看到繼承很深的抽象層和成堆臃腫的樣板式的程式碼。由物件導向而誕生的子類超生現象無以復加。你根本無法一眼看明白、理解這些程式碼是幹什麼的——你需要一層層深入 挖掘，你需要理解它的整套濫用的術語和折磨人的詞彙(“AbstractAdapterFactory”)，你必須要把自己當成系統的一部分。我已經記不起來上一次看到一個不是這種情況的Java專案是什麼時候了。

　　導致在Java王國裡程式碼最終總會變成這樣的原因有很多。Java語言自身要承擔一定責任。Java平臺的API就是上面說的這些問題的典範，於是，善良的程式設計師們沿襲標準類庫裡體現出來的編碼規範和風格，將之當作通用的好的程式設計原則，一下子就誤入迷途。Java語言還會對程式設計師強迫施加一種上層的形式主義和囉嗦，以至於最後你不得不習慣了這樣的風格，當看到其它語言的簡潔語法時，反而感覺就像它們都是沒穿衣服的裸體——這就是“斯德哥爾摩綜合症”(譯註：來源於1973年發生於此地的一次銀行搶劫案中，一個人質浪漫地被她的劫持者吸引住了)。

　　物件導向的流行部分原因也是這種心理作用造成的。有越來越多的程式設計師開始退後一步用整體的眼光認識Java，他們發現，作為一種程式設計模式，物件導向真的是相當的糟糕。然而，Java是最大限度的根植於物件導向模式，如果沒有物件導向，Java寸步難行。即使是今天，你仍然能看到大學裡的程式設計課程嚴重的偏向物件導向，大量的使用Java授課，相比起10年前、5年前要普遍的多。

　　雖然Java語言非常的流行，在企業軟體開發裡被普遍的採用，但這一點都無助於Java程式設計質量的提高。我坦白的說，你在各種企業產品裡看到的大量的Java程式碼都是由非常低質量的程式設計師寫出來的。

　　非常糟糕的是，這些問題並不是只體現在程式碼上，而是在整個Java生態系統上也是如此。不論是你使用的Java單元測試工具、依賴關係管理工具，還是模擬框架，即使是很小的Java程式，你也逃離不了它周邊龐大的系統。Java程式設計師無能為力——讓他們開發一個小功能，你必然會看到一個繼承15層的類工廠(factory)的出現。

　　今天，我在學習Gradle框架，很顯然是因為最近它在Android開發社群裡很火。Gradle來自於Java世界，所以它繼承了上面我說的所有的Java所具有的問題。正像Tim Bray 最近抱怨的：

“我的瀏覽器開啟的是Gradle文件的一頁：第50章.依賴關係管理。它有63個小章節，劃歸在10個一級章節下，這是第50章，文件一共有65章(包括五節附錄)。”

　　Android——如果說除了那些開發企業軟體的人，還有人會在意Java，那一定是因為它——它沿襲Java的老路，走的更遠。你會習以為常的發現，在讀一頁Android API文件時，你根本不知道它究竟是在說什麼。當然，最終你會弄明白，你需要繞道弄清楚其它17個類才行。什麼？這讓你吃不消？你顯然不具備學習Java系統API的百折不撓的精神。你會變成一個Loser。

　　谷歌公司裡開發Android的工程師忙於構築偉大的系統框架，沒有時間解決真正的問題。

　　我是一個Android程式設計師，我討厭Java。它讓我很受傷。