[指令碼_Ruby]ROR為什麼暫時無法成為公司專屬應用程式開發的主流？

標籤：blog   io   使用   java   for   strong   檔案   sp   div   

1. 應該能規範書寫，而不是像c那樣可以造就多種不同的風格。 


Java明顯是一個編程風格非常容易統一起來的語言，而ruby則很明顯是一個難以統一編程風格的語言。JavaEye論壇裡面有人曾經說過： 

引用
Java語言，高手和低手寫出來的代碼都差不多，而ruby則不同，高手和低手的代碼，高下立判 

Java程式設計語言的文法非常簡單，規範比較嚴密，這樣正常化帶來的好處就是，一旦程式員具有比較良好的物件導向編程基礎和設計模式的掌握，那麼編寫出來的代碼幾乎是大同小異的。 

為什麼優秀的Java開源架構的原始碼我們讀起來都比較容易呢？為什麼Java那麼容易寫出來無二義性，相似性那麼高的代碼風格呢？為什麼用Java做同樣一件事情，往往只有一種最優的寫法呢？為什麼Java很難搞出來奇技淫巧呢？為什麼Java語言一直被人認為是大巧若拙呢？我們再想想，為什麼JDK5.0引入的技巧頗高的泛型程式設計到現在也有三年，為什麼還是沒有被廣泛採用？再想想Java語言被設計出來是用在什麼場合的呢？ 

想清楚這些問題，那麼我們就會發現Java成為公司專屬應用程式開發主流的一個內在原因(外因也很多，這裡不談)，因為Java語言足夠死板！ 

所以寫Java程式沒有什麼花巧，所以為了弄出來點花巧，逼的Java社區搞出來動態反射，搞出來AOP，抄襲了泛型，其目的都是增加Java語言的靈活性。 

那麼Java這種死板而簡單的語言有什麼好處呢？好處就是適合作為工業語言！ 

那麼我們分析一下工業語言在文法上面有著什麼樣的要求呢？ 

1、文法足夠簡單而且強壯 
2、文法足夠死板、做同樣的事情，只有一種最優解 
3、足夠的文法障礙，抑制你的隨意發揮，給我規規矩矩的編碼 

工業語言為什麼有這種內在的要求呢？ 

1、團隊協作的需要 
大規模的項目需要幾十人以上的協作，甚至是異地協作。這種大規模的團隊協作要求程式員的代碼風格必須高度一致，並且代碼塊之間的依賴性降到最低。顯然死板而容易解藕的Java非常的合格 

2、批量生產的需要 
現在的軟體外包產業體現的尤為明顯！不需要你的創意，不需要你的設計，就需要你的coding，而且coding風格，功能已經規定死了。Java顯然又非常合適。 


好了，上面分析了從文法特點角度，為什麼Java成為了工業語言，那麼再分析一下為什麼ruby不能成為工業語言： 

1、ruby的文法過於靈活，發揮的餘地太大，導致每個人的代碼風格迥異 

我剛開始學習ruby的時候非常不適應，被ruby五花八門的文法糖衣搞暈了，同樣的一件事情，你有無數種做法，笨拙的，普通的，聰明的，天才的，各式各樣，甚至有本《ruby quiz》的書專門講解ruby編程的各種奇技淫巧。ruby這種內在文法特性直接造就了ruby on rails奇蹟。在ruby on rails架構裡面，有無數的ruby magic，好用之極又讓你驚喜萬分，沒有ruby這麼多靈活的文法支援，rails變不出來這麼多魔術。 

但是ruby的文法靈活性恰恰是成為工業語言的一大障礙！Java絕頂高手和Java普通高手的代碼在風格上不會有大的差別(我就不覺得Rod Johnson代碼比我高明到哪裡去)，但是ruby絕頂高手和ruby普通高手的代碼簡直判若雲泥！高下立判！絕頂高手如DHH把ruby用的出神入化歎服之餘，也讓你我之輩根本無法寫出來符合DHH風格的ruby代碼。 

在我們JavaEye2.0網站開發中，也出現了這種問題，兩個人寫的ruby代碼，互相之間理解起來存在困難。而由於做一件事情有很多ruby寫法，不同性格的人甚至都會選擇不同的實現方法，在一個團隊中，要統一編碼風格，實在難乎其難！而在Java項目中，基本可以杜絕此類問題。 

由於代碼風格難以統一，因此在大規模的團隊中使用ruby編程，會造成合作上面的障礙！ 


2、ruby on rails會導致你的代碼藕合度非常高，不利於團隊協作開發 

由於rails規定死你的代碼架構，不論是橫向的功能解藕，還是縱向的分層解藕，都比較困難。 

首先來說縱向的分層解藕，這是Java大規模項目常用的辦法，但是在ruby on rails中基本不可能。因為ruby on rails各層之間的隱式約定太多了，你不可能分層開發。目前ruby on rails項目都是建議橫向功能解藕，不建議縱向分層解藕的。 

再說橫向功能解藕：首先每個人必須承擔足夠大顆粒度的功能模組，不能拆分的太細了。因為rails的一個Controller檔案就代表一大塊功能了。 

例如JavaEye2.0中，整個forum就只有一個controller，整個blog也就只有一個controller。當然你驚歎，整個forum代碼就一個檔案搞定了啊，代碼太少了！但是反過來，你也可以說，論壇這個功能只能交給一個人來做了，沒有辦法再拆分功能了。這就帶來了一個問題，團隊協作變的困難了，如果兩個人同時做論壇模組，就會出現經常性的該controller檔案衝突合并。即使妥協一下，每個人只負責一個大功能塊，但是底層的model代碼都是互相關聯在一起的。又難以避免的並發修改和檔案衝突合并。 

但是Java不存在這個問題，為什麼呢？因為Java把一個Controller分解成為了無數個小Action，把一個Model分解成為了PO，DAO，Service，進行了充分的功能職責的解藕，每個人的工作基本不會互相干擾，那麼團隊協作的問題就好辦了。 

在JavaEye2.0開發過程中，就遇到了這個問題，即使是分出來一小部分任務，也經常性導致檔案衝突合并，最後只能把大部分的程式任務壓到了jerry一個人身上。可敬的jerry同學幾乎以一人之力編寫了整個JavaEye2.0的絕大多數代碼。在驚歎jerry以一個人月的高效率完成整個JavaEye2.0編碼工作的同時，我們也不得不反思，為什麼ruby on rails這樣難以團隊協作開發呢？ 

在我最推崇的《Getting Real》這本書裡面建議一個Team Dev3個人足夠了，一個人設計規劃產品功能，一個人設計介面，一個人編寫代碼。我們現在也是這樣的：robbin設計產品功能，ouspec負責介面，jerry編寫代碼，然後robbin和ouspec負責測試。但並不是所有的項目都可以靠3個人搞定的，大規模應用項目團隊協作進行開發，我們目前還沒有答案。 

jerry有個觀點我非常贊同，他認為目前我們沒有找到合適的團隊協作方法是因為現在的軟體開發方法都不適合ruby on railsTeam Dev。而真正適合ruby on rails的軟體開發方法究竟是什麼樣子，現在還沒有出現，恐怕需要人們的探索了。ruby on rails流行必須伴隨著適合ruby on rails的軟體開發方法一起出現才行。 

因此在人們總結出來這種適合ruby on rails的軟體開發方法之前，ruby on rails仍然會被局限在web2.0開發領域，在這個領域，ruby on rails的所有優點將發揮的淋漓盡致，而缺點將會被迴避開。不過一旦涉及到公司專屬應用程式開發領域，我們將面臨這些問題。 

因此，我的結論就是ruby on rails目前尚且不適合公司專屬應用程式項目的開發。當然如果有適合ruby on rails的軟體開發指導方法的出現，或者公司專屬應用程式本身的定義已經發生了徹底的改變，那麼我的結論也就不複存在了。 

用一句話來總結就是： 

ruby on rails是武林高手的絕世寶劍，卻不是兩軍對壘中士兵使用的常規作戰武器(Java卻是這種常規武器)。

[指令碼_Ruby]ROR為什麼暫時無法成為公司專屬應用程式開發的主流？