Rails的讓人不堪的噩夢
本文是從 Your Code is My Hell 這篇文章翻譯而來。
我最近的作為一個Rails程序員的經(jīng)歷可能并不常見。
我經(jīng)常被叫去維護一些已經(jīng)做好的Ruby/Rails項目，在力所能及的地方進行改進和完善。這樣，絕大部分我需要接手的項目在我出現(xiàn)前都已經(jīng)開發(fā)完成了。事實上，在我的記憶里，我只參與了一個商業(yè)性質(zhì)的格林菲爾德Ruby項目的開發(fā)。其它的，在我看來，都是“歷史遺物“，相當多的程序代碼在我之前都已經(jīng)出品了。(不包括個人和內(nèi)部項目)。
我知道，我的這種經(jīng)歷在Ruby和Rails程序員中并不常見。由于Ruby/Rails的高產(chǎn)和創(chuàng)業(yè)公司為主的用戶環(huán)境，大多數(shù)Ruby愛好者都是在這樣剛成立的公司里開發(fā)全新的項目。而我的工作更多的是基于最初的開發(fā)人員走后留下來的代碼。
Rails的讓人不堪的小秘密
在受雇寫Ruby程序之前，我也接手過一些歷史程序，它們有的歷史達數(shù)十年之久，代碼量數(shù)十萬行之多。你很容易在這么多代碼里找出寫的很爛的東西;有時候，這種爛代碼的數(shù)量多的讓人驚訝。
但是，在Rails開發(fā)中，你會發(fā)現(xiàn)一個讓人不堪忍受的小秘密;在我的職業(yè)生涯中，我見過的最亂的、最棘手的、最臭的代碼，都是在Ruby on Rails項目里找到的。我所見過的那些Rails項目，它們兩年下來積累的技術債務和廢棄物，跟一個10年之久的C/C++程序相比，會讓你覺得后者更干凈和優(yōu)雅。我說的并不是某個項目。我看到這種情況到處都是。
有時候我會想，這也顯示了這種語言的強大之處。如果在一個Rails應用里有500個錯誤，你可以不停的往里面添加代碼、再添加代碼、點擊“reload“，一直到它好用為止。從來都不需要寫測試或重構代碼。在很多語言和框架里，這種”補到它不漏為止“的開發(fā)方式顯而易見是行不通的。但Ruby on Rails卻提供了讓你這樣做的平臺。
不幸的是，作為它的直接后果，眾多我要處理的項目都可以被看作是一種應急產(chǎn)品。從某種角度來看，這種圖省事的做法的后果還是由開發(fā)團隊來承擔，你這樣做一天把它解決了，可引出的相關問題和不可預料的副作用，你花2周都解決不掉。
題外話：經(jīng)常的，最初的開發(fā)人員會在完成開發(fā)后轉移到新的項目上。同時會有新員工接手這些代碼。管理部門會抱怨，為什么這新接手的團隊修改問題時沒有老團隊迅速呢?而新團隊遇到的問題是，在他們能給這些遺留的代碼上添加新功能前，他們需要讓這些代碼具有更高的測試覆蓋率，有可能還需要把它們分離成更小的模塊;在商業(yè)層面，一個永久不變的聲音是：測試和重構就是拖延工期。看來這原創(chuàng)團隊都是比較明智的。
好了，牢騷發(fā)完了。
Rails的情況更為特殊!
Rails程序員有時候會顯得很傲慢和固執(zhí)。我不清楚這個判斷的可信度;我并沒有看到太多的人是這樣，但也許我跟這個社區(qū)太接近了，也許我本身也是傲慢和固執(zhí)的。
而我發(fā)現(xiàn)的卻是一種“Rails例外主義“。還記得第一次互聯(lián)網(wǎng)繁榮的時期嗎，當時有幾個經(jīng)濟學家跳出來說”不會的，這次不同，互聯(lián)網(wǎng)改變了游戲規(guī)則，市場會一直走高、走高“，本質(zhì)上我感覺很相似，有些人相信，Ruby on Rails開發(fā)是某種不同的東西，不需要跟其它類型的軟件項目一樣。
這有一些例子，讓你明白我究竟在說什么：
◆ “設計模式是Java上的東西。Ruby里只管寫你的代碼就是了。“
◆ “Ruby里拋出的警告都是無聊的，禁止掉就行了。“
◆ “的確沒有單元測試，而且對象隔離做起來很難，沒有人這樣做。“
◆ “到處打補丁對于其它語言來說是不贊成的，但Ruby沒問題。目前還沒有出現(xiàn)問題。”
◆ “像Demeter定律這樣的東西在Ruby里并不是這么重要。“
◆ “把方法分成私有和公有，這是變態(tài)控制，Ruby里不需要這樣做“
◆ “Java代碼里才會有代碼異味(code smell)。“
◆ “只有在大項目里才會有這樣的問題“(暗示這個項目永遠不會變大)
我還看到了很多項目和子系統(tǒng)例外主義者：“我知道一個類不應該搞的太大，但是對這個類是有意義的，它是為了把所有的東西放到一個地方“。
歡迎來到小人國
事實上，Ruby on Rails項目確實有一點很例外：都是小項目。上周在James Gray在Lone Star Ruby Conf大會上有個極好主題，他提到的“巨型“項目有4萬多行代碼。這讓我微微一笑，因為我被雇來做的頭兩個項目分別有5萬行和7萬行。這看起來不少，但根據(jù)行業(yè)標準，它們很小。
造成這種現(xiàn)象的原因有不少。Ruby是一種比Java更富有表達性的語言，所以，從某種程度上說，Rails項目，在相同的情況下，總是比那些更講究的語言顯得更小。
而且，Rails程序員很喜歡接受把系統(tǒng)分割成很多很小的、相互聯(lián)系的小應用。但是經(jīng)驗告訴我們，這種策略是有問題的。
不，我想這導致Rails應用體格較小的最大的原因是，顯而易見的：這個框架還很年輕。這個領域里有大量不成熟的產(chǎn)品。一個Rails應用如果有3年的歷史，那就可以算是古老了。
我可以很有信心的說，這種情況不會一直持續(xù)下去。我們會看到越來越大的程序項目。我不需要鼓起勇氣就可以做下面的預言：很多項目將遭遇像Lisp, Smalltalk, C++, Java等語言曾經(jīng)遭遇過的相同的架構瓶頸。
你并不特殊
《programming literature from the 80s》這個作品讀起來非常的有趣。動態(tài)，面向對象的系統(tǒng)引導了從“小規(guī)模“到”中等規(guī)模“的過度。聽起來耳熟，是吧?
每一次的革命都會堅稱這次是與眾不同的，不會造成上次革命后出現(xiàn)的政黨紛爭和官僚腐敗。起初你很容易被這些宣傳感染。每個人都很興奮，熱情的去幫助;這時出現(xiàn)的問題還比較小;然而這只是市場的大機器還沒有注意到這場運動。
事實上，你要解決的問題也許并不是你想像的那樣例外。你思想里的這種拜占庭模式只是遠古時代那些使用跟Ruby類似語言的人留下來的遺產(chǎn)。
不要驚慌
放松。我這里要說的并不是告訴你過去的幾年只是一場可愛的夢，Ruby實際上一直處在它應有的地位上。
Ruby仍然是一種奇妙的語言，它令人驚異的地方就是它在付出微小的約束代價下能輕松的接納大型系統(tǒng)的設計模式。注入依賴?兒戲。對象委托和組合?小菜一碟。跟你的錯覺正好相反，Ruby并不拒絕嚴謹?shù)脑O計模式和SOLID編程原則;Ruby能做到的事是讓它們更容易的表達出來。事實上，Ruby強大的富于表達的架構風格是讓很多人第一眼就喜歡上它的原因。
拜托：請在你告訴我Ruby和Rails不需要任何的約束之前，請跟那些仍然在維護你當初開發(fā)的Rails應用的兄弟們聊一聊。
原文：http://www.aqee.net/your-code-is-my-hell/
【編輯推薦】
