上週五是 Tony (C.A.R.) Hoare 的生日。 C. A. R. Hoare 是誰？ 如果你是程式設計師，你可能熟悉 快速排序--一種優雅且出乎意料的簡單排序演算法，在大多數情況下速度極快。 如果你學習過電腦科學，你幾乎肯定用多種語言實現過快速排序，並且會認出此頁面上的動畫。 Hoare 在 1960 年發明了快速排序，它現在是最廣泛使用的排序演算法。

除了其他貢獻外，Hoare 還發明了用於指定並行進程交互的「通信順序進程 (CSP)」語言。 一位聰明的人，為電腦科學的發展做出了顯著的貢獻。

1980 年，Hoare 獲得了圖靈獎，「因為他對程式設計語言的定義和設計做出了根本性的貢獻。」 他的獲獎感言，名為 皇帝的新衣，不僅應該是電腦科學家的必讀之物，也應該是 IT 經理和應用程式開發人員的必讀之物。

讓我引用一些精華

程式設計師總是處於複雜性之中； 我們無法避免它。 我們的應用程式很複雜，因為我們渴望以越來越複雜的方式使用我們的電腦。 程式設計之所以複雜，是因為我們每個程式設計專案都有大量相互衝突的目標。 如果我們的基本工具，即我們設計和編碼程式的語言，也變得複雜，那麼該語言本身就會成為問題的一部分，而不是解決方案的一部分。

這不僅適用於語言；它也適用於平台和框架。 越來越多的情況是，在實現業務應用程式時，這些對成功和失敗的影響比語言本身更大——這一點在我在 11 月在 QCon San Francisco 參加的小組討論中，關於 Java 語言的未來就提到了。 根本的事實是，基礎設施（無論是語言還是平台）的作用是簡化開發人員的生活，讓他們專注於交付業務價值的真正任務。

與語言（和早已過時的技術）相關的觀點至今仍有共鳴

對於分時或個人電腦系統的用戶來說，輸入程式（或修改）到開始運行該程式之間的時間間隔是完全沒有生產力的。

現代翻譯——程式碼到測試的週期必須盡可能短，這使得敏捷測試對於提高生產力至關重要。

在描述一個過於複雜的語言專案時，Hoare 評論道

起初，我希望這樣一個技術上不健全的專案會崩潰，但我很快意識到它注定會成功。 幾乎任何軟體都可以通過足夠的決心來實現、銷售甚至使用。 僅僅是一位科學家所說的任何話都無法抵擋一億美元的洪流。 但有一種品質是無法通過這種方式購買的——那就是可靠性。 可靠性的代價是對極致簡化的追求。 這是非常富有的人發現最難支付的代價。

當我 5 或 6 年前第一次看到這篇演講稿時，正值「舊 J2EE」的黑暗時期，我感覺 Tony Hoare 直接在對我說話。Tony Hoare 在 1980 年預言了 J2EE 的問題。 那時，像大多數 J2EE 架構師一樣，我更關心取得成果而不是提升履歷，我與 Hoare 在 PL/1 中所處的境況相同——眼睜睜地看著一場災難以慢動作發生，卻無力阻止它。在 2004 年的 沒有 EJB 的 J2EE 中，我寫到了「複雜性產業」，它以金錢、時間和純粹的失敗為代價，產生了過於複雜的解決方案。複雜性產業在應用程式開發團隊和內部架構小組以及基礎設施中蓬勃發展。很難克服複雜性產業，因為很多人都有既得利益——有時是經濟上的；有時是專業上的（當它允許他們建立帝國時）；而且通常只是為了提升履歷。那些捍衛它的人總是會辯稱，批評者只是不了解他們在批評什麼——當像 Hoare 這樣無可置疑的傑出人士發聲時，這一點就更重要了。

那是本世紀初——是上個世紀概念的遺產。 今天，情況有所不同——至少在企業 Java 領域是這樣。 Tomcat 的普及程度大幅增長也許是開發人員現在有能力強制執行簡單性的最大證明。 Ruby on Rails 對 Java 的（健康）壓力（我認為最終會加強 Java）也指向了同樣的事情。 甚至有證據表明，一些傳統的應用程式伺服器供應商了解了這種變化以及它如何使他們的客戶受益。 BEA 通過 擁抱 Spring 和其他簡化客戶體驗的技術，可以說是引領了潮流。 甚至 Sun——通過 Java EE 6 Profile 概念——似乎也在與時俱進，並承認許多客戶不再需要傳統的、單體的應用程式伺服器的現實。

每次有人選擇不使用 EJB； 每次有人選擇在 Tomcat 上而不是在 WebSphere 上部署 Web 應用程式； 每次有人選擇使用簡單的遠程策略而不是基於 SOAP 的複雜方法時，他們都在做出簡單的選擇。 正如 Hoare 評論的那樣，他們不僅沒有建立「非企業級」解決方案，而且通過更簡單的方法，他們實際上在可靠性等關鍵企業級功能方面取得了顯著的收益。

可靠性的代價是對極致簡化的追求。 這是非常富有的人發現最難支付的代價。

自從最近去雪梨旅行遇到一位現在是學者的老大學朋友以來，我一直在更多地思考電腦科學。 因此，我重新審視了 Hoare 的講座。 但除了 Hoare 在商業和學術界的經驗中得出的明顯教訓之外，在企業 Java 應用程式開發的背景下思考電腦科學是令人沮喪的。 我們離做聰明的事情還很遠。 我們遭受了太多的複雜性，以至於我們專注於讓事情正常運作。 正如 Hoare 強調的那樣，無論你想做什麼，從程式設計師的角度來看，擁有一個簡單的模型是成功完成它的先決條件。 （通常基礎設施需要很聰明才能實現這種簡單性。）

過去幾年一直在努力使企業 Java 的模型在實踐中發揮作用並擊敗複雜性產業。 這基本上已經完成。 今天，企業 Java 專案的結果是相當可預測和良好的。 我相信未來幾年將解決超出明顯範圍的問題，並構建更智慧且對其運行的程式碼具有更多了解的基礎設施。 我很自豪我認為我們公司可以幫助實現這一現實。 隨著我們在許多領域不斷帶來創新，SpringSource 將站在致力於解決構建下一代技術（例如 用於 OSGi 服務平台的 Spring Dynamic Modules 和 AspectJ）的最前沿，而不僅僅是清理昨天的爛攤子。 無論事情如何發展，應用程式開發人員和想要可預測、具有成本效益的結果的經理們的前景都是光明的。

新年快樂！