在我閱讀此書之前，我應該總結(jié)一下目前在 J2EE 方面所具有的基礎(chǔ)知識。在我看來， J2EE 是一個極其龐大的系統(tǒng)架構(gòu)，對于 J2EE 有一些初步的認識，也做過一些基于此架構(gòu)的小型或中小型項目，比如基于此技術(shù)架構(gòu)的網(wǎng)站，一些應用系統(tǒng)等。 J2EE 包括以下部分：
　　
　　對于 EJB ，我僅僅只是知道其基本概念，從未有過深入的學習和研究，也就是說有一個膚淺的認識。而對于 IoC 和 AOP 則有一定的了解，因為之前在學習 Spring 的時候有過一些深入的學習，但是對于 AOP 的理解是遠遠不夠的。

好了，開始言歸正傳，真正開始談談一些我自己的膚淺觀點（甚至是錯誤的觀點）。

?

書中談到“ J2EE 應用項目至少和從前的非 J2EE 項目一樣容易失敗――如果不是更容易失敗的話”（ page 4 ），我認為一個項目的失敗與該項目采用何種框架和技術(shù)有太大的關(guān)系，在這個時代，對于架構(gòu)和技術(shù)的選擇有很多，而更關(guān)鍵的因素可能得從軟件項目管理方面來衡量，從所周知，一個項目采用何種架構(gòu)和細節(jié)性的技術(shù)只是項目管理的一個小部分。“而在 J2EE 遭遇失敗的場景中， EJB 通常都扮演著重要的角色”（ page 4 ），這樣說似乎也顯得很牽強。

書中再次強調(diào)“最成功的標準都是從實踐中發(fā)展出來的” (page 5) ，最顯著的例子莫過于 OSI 和 TCP/IP 之間的關(guān)系。

本書的主旋律主要包括以下部分：

1 、簡單

我常常在工作中就把一些問題看得較復雜，因為總覺得這不是一件壞事，考慮到一個問題的復雜性并認真想清楚此問題的各個方面，在解決這個問題的時候相對來說就會簡單一些，但是這樣也確實會帶來諸多問題，如軟件成本的核算，我就曾因此在一個客戶需求并不高的情況下把問題復雜化了，導致了那個方案的失敗。上次我就是犯了“提前叫客戶掏錢購買的復雜架構(gòu)”（ page 6 ）這樣的錯誤。“這種想法有兩個問題：首先，是否讓系統(tǒng)變得如此復雜不應該由作為架構(gòu)師和開發(fā)者的我們來決定，因為買單的人不是我們；其次，即便系統(tǒng)最終變得如此復雜，我們又怎么知道一開始將它們考慮進來就能節(jié)約成本呢？說不定，等到有需求的時候再修改架構(gòu)還會更節(jié)約呢。”（ page 6 ）

書中主要從技術(shù)層面上討論了這個問題，如數(shù)據(jù)庫的分布，多種客戶端等。對于問題的解決我們應該更切合實際一點，不要沉溺于一些不切實際的想象。

“XP 的核心教義之一就是：很多時候，越是節(jié)約成本，就越能開發(fā)出高質(zhì)量的軟件；不要試圖預先解決所有能想到的問題。 ” （ page 6 ）

“使 J2EE 項目具備架構(gòu)重構(gòu)能力的關(guān)鍵在于：遵循良好的 OO 設計法則， 并且始終針對接口編程、而非針對類編程；將EJB之類的技術(shù)隱藏在普通Java對象背后。 ”（ page 7 ）

2 、生產(chǎn)率

雖然我沒有真正的用 EJB 來開發(fā)過任何項目，但根據(jù)我對 EJB 的了解來看， EJB 在生產(chǎn)效率方面確實存在著很大的問題。

3 、 OO

以前我在設計一個對象的時候，根本沒有認真的考慮過某一個對象是否真正的合理，這個需要在以后的設計中得以重視。

4 、需求至上

“ J2EE 的開發(fā)者們僅僅因為他們的技術(shù)選擇――而不是客戶的需求――就耗費了更多的精力。” (page 8)

5 、經(jīng)驗過程

經(jīng)驗對于一個軟件開發(fā)者來說是極其重要的，很多問題只有你在具體的實施過程中才會發(fā)生，但是我從不拿一個人參加工作的時間長短來衡量一個人的經(jīng)驗是否豐富。

書中提到的循證醫(yī)學（ EBM ）到是一件很有意思的事情，我覺得值得我們中國的醫(yī)生好好的學習和思考一下（題外話）。

6 、可測試性

對于軟件測試，我其實并沒有深入的認識，我一直都處在開發(fā)的前沿，沒有更多的機會和時間來深入研究測試，其實軟件測試是一門很值得研究的學問。就拿騰訊的程序來說，其出錯的機率遠遠高于其它軟件，這是人的共知的，我想這也是騰訊所需要重視的。

?

關(guān)于輕量級框架和容器，我一直在關(guān)注 Spring 、 PicoContainer 和 Nanning 等。

?

書中講到的“帕累托法則（ 80/20 法則，或 90/10 法則）”的確可以作為我們在項目實施過程中考慮該如何解決問題的一個衡量標準。即“花比較少的力氣就可以解決大部分的問題，而要解決剩下的少部分問題則需要多得多的努力。”（ page 11 ）這教會了我們?nèi)绾卧陧椖恐凶鲞m當?shù)娜∩幔òㄜ浖軜?gòu)的取舍和需求的取舍，當然很多時候需求是不能改變的）。

EJB 在那些真正需要對象的分布應用方面仍是上佳之選，同時在需要大量使用異步消息的應用中，也是不錯的選擇，同時， EJB 在金融中間件的應用中，也能為項目提供價值。

本書所推行的思想就是， EJB 并不是要被我們完全拋棄，只是在一些沒有必要使用 EJB 的項目中，我們可以如何找到更好，更簡單，更具生產(chǎn)率的替代方案。

同時需要澄清的一個誤解是： EJB 一直被視為 J2EE 平臺的核心。這種觀點把 EJB 的地位看得太重了一些。

書中說“還有強大的政治因素（而非技術(shù)因素）促使人們使用 EJB ”（ page 12 ），對于此句中的“政治因素”不知所指。是說的來自 Java 官方（即 SUN ）的因素嗎？