這里所涉及到的都是與軟件開發(fā)有關(guān)的技術(shù)，感覺很有必要總結(jié)一下我從業(yè)以來所使用過的開發(fā)技術(shù)以及所經(jīng)歷過的幾次技術(shù)轉(zhuǎn)型。

1996年7月-1999年10月3年時間一直使用C語言編寫電信協(xié)議軟件，算作我的C語言時代。其中還使用過一段時間SDL語言和基于SDL的代碼自動生成工具（瑞典Telelogic公司的SDT）。
2000年3月-2000年10月7個多月時間使用Perl語言做網(wǎng)站開發(fā)，算作我的Perl語言時代。后來轉(zhuǎn)向了使用Java和JSP，用了兩個月。
2001年2月-2001年8月6個月時間使用JavaScript做DHTML開發(fā)，還使用ColdFusion做網(wǎng)站開發(fā)。
2001年12月-2001年6月7個月時間使用C語言做企業(yè)級郵件服務(wù)器開發(fā)。
2002年8月之后做開發(fā)一直使用Java語言至今，算作我的Java語言時代，算算已經(jīng)快5年了。

在我使用過的這些語言中，有3種語言對我的影響最大，那就是C、Perl和Java。當(dāng)然JavaScript對我的影響也很大，不過對于整體的應(yīng)用軟件開發(fā)來說，JavaScript并不是一個主角。

現(xiàn)在我正在經(jīng)歷一次新的技術(shù)轉(zhuǎn)型，從Java語言轉(zhuǎn)向Ruby語言和Rails框架。

如果說以前的幾次技術(shù)轉(zhuǎn)型都是因為工作的變動而導(dǎo)致的，那么這一次技術(shù)轉(zhuǎn)型則是我自己主動發(fā)起的，因為我感覺Ruby代表著應(yīng)用軟件開發(fā)技術(shù)（注意限定詞 “應(yīng)用軟件”）的未來。Ruby是一種比Java更加先進(jìn)的應(yīng)用軟件開發(fā)語言，最重要的是它能夠帶來極高的開發(fā)效率，而且不會影響代碼的可讀性和可維護(hù)性。

一年多以前我對Java還抱有一些幻想，認(rèn)為Java社區(qū)如果有更好的框架，開發(fā)效率一定會追上Rails。今年5月我讀了 Bruce A. Tate的《超越Java》這本書，希望從專家那里了解一下Java語言和Java社區(qū)到底出了什么問題。這本書打消了我的幻想，讓我理解了Java最大的問題在于靜態(tài)類型對開發(fā)效率造成的嚴(yán)重影響。聯(lián)想到我去年下半年做的那個廣告發(fā)布平臺，我對此深有感觸。我當(dāng)時所采用的框架是Spring MVC+Spring IoC+Hibernate+FreeMarker+SiteMesh，按理說在Java開發(fā)領(lǐng)域，這套組合的開發(fā)效率應(yīng)該算是比較高的了。然而實際的開發(fā)進(jìn)度遠(yuǎn)遠(yuǎn)低于我的預(yù)期，我作出第一個版本的時間差不多是預(yù)計時間的兩倍。當(dāng)然因為資金的缺乏，大部分時間都只有我一個人在做開發(fā)，什么都要親自動手，困難確實很多。不過我認(rèn)為主要的問題還是在于Java語言做Web開發(fā)的笨拙。

因為資金的缺乏，我今后要做一些自己感興趣的東西，注定仍然只會有很少的人參與（2、3個人），Java這樣笨拙的語言可能會使我付出雙倍的代價。

當(dāng)然，Java語言仍然在發(fā)展和變化，但是它變的越來越復(fù)雜，越來越缺乏一致性，最終很可能會發(fā)展成為像C++那么復(fù)雜的一種語言。Java越來越不適合Web應(yīng)用的開發(fā)了（我說的比較謹(jǐn)慎是因為這個領(lǐng)域是我最熟悉的），是到需要尋找一種新的開發(fā)語言的時候了。

Rod Johnson確實很偉大，在參與翻譯了《J2EE without EJB》之后，我至今仍然對Rod Johnson對于JavaEE的偉大貢獻(xiàn)深感敬意。但是Spring是從企業(yè)應(yīng)用環(huán)境成長起來的，它對于面向Internet的Web應(yīng)用來說，仍然是太重了。而Web 應(yīng)用的很多重要的需求（例如對Ajax的支持、對REST的支持等等），Spring并沒有解決。做企業(yè)應(yīng)用，Spring仍然是很好的選擇，然而做Web應(yīng)用，Spring，甚至是Java語言本身，都不是很好的選擇。為何在Web應(yīng)用開發(fā)技術(shù)方面，PHP最終占據(jù)了第一的份額，這是很值得思考的。

我們以前做網(wǎng)站開發(fā)從Perl語言轉(zhuǎn)向了Java語言，主要的原因有以下這些：
1. Perl開發(fā)的應(yīng)用代碼量大了之后很難維護(hù)。我自己寫過一個4、500行的復(fù)雜Perl程序，過了兩個月后再讀居然都讀不懂了。
2. Perl這個工具最初是設(shè)計用來取代bash、awk、sed等工具的，因為Larry Wall覺得這些工具還不夠強大靈活。Perl最初并不是設(shè)計用來作為一種全功能的應(yīng)用軟件編程語言的。
3. Perl對面向?qū)ο缶幊讨С值牟⒉缓谩?br/>4. 對于Web開發(fā)來說，Perl的資源（開發(fā)框架、開發(fā)庫）沒有Java豐富，很多功能需要自己來開發(fā)。
5. CGI開發(fā)與支持session的Servlet/JSP開發(fā)相比太原始，開發(fā)難度太大。

所以我們有非常充足的理由轉(zhuǎn)向Java語言。還有一個不大好開口的理由就是，做Java開發(fā)當(dāng)時似乎是成為一個專業(yè)程序員的標(biāo)志，純粹的面子問題，當(dāng)然Java程序員的就業(yè)前景也要好的多。

但是轉(zhuǎn)向Java之初最強烈的感覺就是Java做一些與文本處理相關(guān)的工作非常麻煩，沒有Perl快捷，而這些工作對于開發(fā)Web應(yīng)用來說是很常見的。當(dāng)時 Java核心類庫甚至還不支持正則表達(dá)式，需要下載學(xué)習(xí)其他的開發(fā)包，直到JDK1.4之后Java核心類庫才開始支持正則表達(dá)式。不過JSP這樣與 ASP、PHP類似的服務(wù)器頁面技術(shù)是比CGI要先進(jìn)一代的技術(shù)，所以開發(fā)效率還是比寫Perl CGI有所提高。

我做了一段時間JSP 開發(fā)，發(fā)現(xiàn)全部代碼都混在頁面中問題很多，于是開始學(xué)習(xí)Java Web開發(fā)的Model1和Model2，并且接觸到了當(dāng)時剛剛興起的Struts。不過因為工作轉(zhuǎn)換，并沒有深入使用Struts。后來我用了半年 ColdFusion之后，就不愛使用JSP了。JSP的開發(fā)效率雖然比Perl CGI高一些，但是比起ColdFusion來說還是要低很多。JSP開發(fā)后來逐漸轉(zhuǎn)向基于custom tag的開發(fā)方式，并且最終出現(xiàn)了JSTL，在我看來是一種對ColdFusion的模仿。Java社區(qū)后來出現(xiàn)了n多的MVC框架、n多的IoC框架、 n多的ORM框架�！禞2EE核心模式》所提倡的標(biāo)準(zhǔn)的三層架構(gòu)至今仍然被當(dāng)作鐵律來遵循，過多的層次帶來了巨大的靈活性，同時也帶來了巨大的復(fù)雜性。除了JavaEE之外，我還沒有看到其他的服務(wù)器端開發(fā)技術(shù)如此強調(diào)三層架構(gòu)或者多層架構(gòu)。一般來說，分出MVC就足夠了。而JavaEE開發(fā)不僅要在 Web表現(xiàn)層中分出MVC，還要在M中再分出業(yè)務(wù)層和持久層。這個分層的設(shè)計，是做JavaEE開發(fā)很難實現(xiàn)Martin Fowler在《企業(yè)應(yīng)用架構(gòu)模式》中提倡的充血的domain model的一個主要原因。另外Java語言本身的靜態(tài)類型所造成的笨拙和無法避免的重復(fù)代碼也是一個主要的原因，如果不強調(diào)分層，并且真的實現(xiàn)充血的 domain model，那么一個類中包含的代碼量會顯得太多太復(fù)雜了。

Java社區(qū)中的一些廠商目前在大力追捧JSF和EJB3，但是我并不認(rèn)為JSF和EJB3或者將兩者集成在一起的JBoss Seam能夠拯救JavaEE。復(fù)雜性才是JavaEE最大的問題，JBoss Seam成功的關(guān)鍵在于它能否成功地掩蓋JSF和EJB3的復(fù)雜性，使得學(xué)習(xí)成本降低到與Rails相當(dāng)?shù)募墑e。不過即使它能夠做到，將來開發(fā)者還是要面對Java語言本身的靜態(tài)類型所造成的開發(fā)效率低下。我并不認(rèn)為JBoss Seam有機會在開發(fā)效率上超越Rails。另外一個值得關(guān)注的框架是Grails，它是基于動態(tài)語言Groovy的，嚴(yán)格來說不能算是Java社區(qū)的框架。不過由于它基于Spring、Hibernate、SiteMesh，所以也可以看作是Java框架的進(jìn)一步發(fā)展。在開發(fā)效率方面Grails也不大可能超越Rails。除了開發(fā)框架本身，還需要考慮眾多外圍工具的支持和社區(qū)的規(guī)模，在這些方面Grails不可能達(dá)到Rails的水平。還有一個RIFE呢，雖然我完全不了解它，不過看來它受到的關(guān)注很少。一個幾乎完全被忽視的框架，成功的前景估計很渺茫。Wicket我認(rèn)為是不值得考慮的，現(xiàn)在我們應(yīng)該把目光僅僅投向那些full stack框架上，建造一個更加精巧的Web MVC框架解決不了根本的問題，對開發(fā)效率的提升是有限的。Cetia4和Restlet也是兩個很有趣的框架，特別是它們能夠支持REST開發(fā)，代表了 Java Web開發(fā)框架的未來。Google的Guice是一個很有可能取代Spring的輕量級IoC框架，前景似乎不錯。不過Cetia4、Restlet、Guice這些框架和Wicket一樣，并不是full stack框架，對開發(fā)效率的提升是有限的。

根據(jù)上述分析，我現(xiàn)在對Java社區(qū)內(nèi)部的創(chuàng)新能力已經(jīng)感到很失望了（很明顯我后知后覺了，感到失望的大有人在），這種持續(xù)了10年之久的創(chuàng)新能力似乎已經(jīng)逐漸枯竭。由于動態(tài)類型的腳本語言（Python、Ruby、JavaScript等等）這些年來取得了長足的進(jìn)步，而且在Web開發(fā)方面出現(xiàn)了一些killer級的框架，現(xiàn)在是將目光投向其他開發(fā)語言的時候了。我的決定就是在今年下半年完全轉(zhuǎn)到Ruby和Rails這個平臺上面。從Java轉(zhuǎn)到 Ruby有幾個強有力的理由：
1. Rails可以讓單個開發(fā)者在開發(fā)效率方面接近自己能力的極限。我并不是一個完美架構(gòu)的fans，熱衷于不寫一行代碼，巨細(xì)無靡地分析各種架構(gòu)優(yōu)劣直到腦神經(jīng)癱瘓。我熱衷的是解決用戶真正關(guān)心的問題，用技術(shù)改善他們的生活，與用戶建立起良好的人際關(guān)系。
2. Rails框架對Ajax有更好的支持，通過使用RJS模板可以極大減輕一般情況下做Ajax開發(fā)的復(fù)雜性，提高開發(fā)的效率。
3. Rails框架對REST開發(fā)提供了最好的支持。REST在Web開發(fā)方面會越來越重要，全面支持REST就是未來所有語言Web開發(fā)框架發(fā)展的方向。
4. JRuby 1.0對Rails的支持已經(jīng)很好，而且支持直接使用Java開發(fā)的資源，所以現(xiàn)在是從Java轉(zhuǎn)到Ruby的一個適當(dāng)?shù)臅r機。

我已經(jīng)讀完了《Ruby for Rails中文版》，并且出了一個個人的勘誤。《應(yīng)用Rails進(jìn)行敏捷Web開發(fā)》第2版我已經(jīng)讀了1/3，在一周之內(nèi)可以全部讀完。這兩本書讀完之后，基本上已經(jīng)入門了。在入門階段我只準(zhǔn)備讀這兩本書，然后我會通過開發(fā)來熟悉更多的技術(shù)。因為我對Perl、JavaScript和Java語言的熟悉，所以學(xué)習(xí)Ruby和Rails并沒有感覺有什么難度。事實上閱讀《應(yīng)用Rails進(jìn)行敏捷Web開發(fā)》第2版要比我閱讀《Struts實戰(zhàn)》之類的書容易理解的多（同時也更加有趣味，我第一次沒有感覺犯困），到目前為止，一切都感覺很自然。Ruby在我看來就是Perl+JavaScript+Java，毫無疑問是一門偉大的語言。很可惜晚學(xué)習(xí)了整整一年多，否則去年見到Martin Fowler的時候本應(yīng)該問他更多關(guān)于Ruby的問題的。