Java EE和RoR的牛人感慨

從架構思想上看：

JavaEE的（起碼早期的）思想一直是 用大型架構 建設 錯綜複雜的商業系統（注意這些系統中web只是所用的眾多技術中的一部分），導致他十分強調分層，開發部署比較繁重。
這個思想根深蒂固，幾乎影響了所有java框架的設計。甚至所謂的輕量級框架也是如此。
（似乎成了企業級技術的特點，看看現在火熱的SOA，其複雜和繁重程度甚至比JavaEE更嚴重）。

http://pig345.javaeye.com/blog/199384

ROR顯然沒這麼大的野心，它要解決的只是如何快速搭建好一個網站（因此會更注重如何多多利用web標準：html、css、javascript），他在架構上的考慮就只是MVC，能保持一個好的程式結構即可，根本無須分層。
（與JavaEE這麼多年一直擁抱SOA對比，ROR到了2.0更是拋棄了webservice，轉到更加簡潔的REST了）

但是sun沒想到實際中大多數人開發的東西沒那麼複雜，反倒更強調快速開發、快速適應變化，因此ROR在java社群裡面引起很大反思。
（在中國這個情況更加普遍，系統不復雜、倒是需求變化快。。。）
（在網站製作領域一直都是喜歡用指令碼語言，可以做到快速編碼、快速部署、快速變化。PHP就是一個例子，只不過PHP結構實在太差，java們一直看不上眼，而ROR實現的MVC卻相當正統、嚴密，框架結構甚至比流行的java框架如ssh作的更完美，這自然引起了java們的廣泛興趣）

[@more@]看起來，ROR就像一枚銀彈，尤其是對我們們這些中國的開發人員
然而實際作起來，你會發現：
1）從語言環境到應用框架都不熟悉，需要不短的一段時間學習和準備
（對於那些看了幾天 文件／影片／教程 就敢輪胳膊開幹，還說入門簡單學習曲線低的，我真要罵人了：不是人您就別在人堆裡面瞎炫耀了）
2）動態語言真的很動態，沒有編譯過程，你可能會犯下一些低階錯誤，而具體到Rails框架中，因為使用了各種動態的程式碼生成技術，導致要想搞清楚其中一些bug，可能需要你花費幾個小時進行跟蹤查詢。
3）Rails中的View是基於html的模板技術，這跟jsp類似，你需要自己控制自己，因為沒人會阻止你在裡面寫業務程式碼。
4）ruby之前應用的還比較少，一些常見解決方案還非常不完善（比如：全文檢索，目前最好的ferret，還是有bug經常導致rails意外退出）。
5）Rails的各種外掛比較多，但是質量不齊，有些看起來很cool，但是無法深入定製（比如：ROR書裡面提到的streamlined，就有點像玩具），具體的調研和選擇代價比較大。
6）有時碰到Rails外掛的bug或功能缺陷，如果你自己直接改的話，之後的外掛升級版本管理上似乎會有點麻煩，需要你手工合併。
7）可能你要自己解決部署後的原始碼保護問題，而這個問題對於產品開發無疑是最重要的。
8）動態語言的全面掌握需要比靜態語言花費更多時間精力。

呵呵，潑了這麼多涼水，其實是想說明一點：要認真地對待ROR技術，不要被一些宣傳所矇蔽。
基本上，在沒有熟練掌握ROR、而又需要深入開發的時候，ROR帶來的好處（程式碼量少、開發修改部署快），和他帶來的各種問題幾乎可以互相抵消，千萬別以為能省多少時間。
但是從長遠看，程式碼量少還是非常吸引人的，想象一下，同樣的業務邏輯程式碼，10萬行和100萬行那個更容易維護？

偶然和一個作過ROR的開發人員有過一次交流，發現大家目前的想法有點相似，ROR更適合少量的高手合作開發，或者私人接活。
普通的團隊開發似乎還需要大量探索。