Better, Faster, Lighter Java(心得一)

有時候其實最簡單的架構, 卻是最棒的答案~

從最簡單的答案變成最棒的答案, 總是在你堅守這原則後驚異發現...

這本書雖然以Java來看,
但實際上卻很適合各領域的程式語言開發案的成員們閱讀
每種語言的背後都應該以這精神來構建會是個良方...

Better, Faster, Lighter Java

http://www.oreilly.com/catalog/bfljava/

http://www.oreilly.com.tw/product_java.php?id=a168

Java的複雜度已經超越我們的能力...
我們漸漸發現控制不了也學不完的新 Java架構...

我們的經驗與能力的極限的結果,
我們花在撰寫利用新架構的Code竟比解決真正問題的部分還多
新的枷鎖不斷增加, 卻離直接的幫助漸行漸遠...

面對不對受商業影響的 Java 我們不需要

• 超過三到五層的 Logic Layer, 應當簡化為二層簡化無法控制的複雜度
• 不需要 EJB, 大多數的結果只是 the bloat "澎風" 的虛表與走向失控
• 使用 Tomcat 不是龐大的 Web Logic or JBoss ..

J2EE 的學習成本超乎我們個人的學習極限, 且受廠商們不斷為了收益,
廠商必需持績加諸新疊床 Design pattern, 來確保企業對其產品的買單...

Hibernate, Spring 捨 J2EE 改採以走最少量簡化的 API 來達到同樣的目的,
但這卻是每位Java開發者最想要的！

不可避免的膨風

• 超大型的企業架構才叫時尚? 卻苦了近90%的Java開發者
• 用大砲打小鳥的架構?
• Design pattern 拾簡單化換威力, 就是膨風
• 超多的膨脹程式碼並不是來自對於寫code知道太多的人, 反是來自那些知道太少的人

對抗膨脹的五個基本法則

1.保持簡單
優秀程式員的價值在於簡化, 更易除錯, 更易進行測試, 更易進行加強與維護, 更易其它團員接手

2.每次做好一件事
單體化的 MVC (Model-View-Controller)是優雅與專注的表現
也利於Refactor重構, 更利於測試.

3.力求通透transparency
Hibernate or JDO 是很棒的替代方案

4.開放擴充
善用OO設計原則中的部份 Abstraction
善用 ORMDBS 的設計
善用 RMI (Remote method invocation)

5.吃什麼像什麼
過度的相信Java廠商建議, 特定J2EE的信仰與廣告只會引領你走向毀滅與專案失控...