英文原文：Your Code is My Hell　　

　　我最近的作為一個Rails程序員的經(jīng)歷可能并不常見。

　　我經(jīng)常被叫去維護一些已經(jīng)做好的Ruby/Rails項目，在力所能及的地方進行改進和完善。這樣，絕大部分我需要接手的項目在我出現(xiàn)前都已經(jīng)開發(fā)完成了。事實上，在我的記憶里，我只參與了一個商業(yè)性質(zhì)的格林菲爾德Ruby項目的開發(fā)。其它的，在我看來，都是歷史遺物，相當(dāng)多的程序代碼在我之前都已經(jīng)出品了。(不包括個人和內(nèi)部項目)。

　　我知道，我的這種經(jīng)歷在Ruby和Rails程序員中并不常見。由于Ruby/Rails的高產(chǎn)和創(chuàng)業(yè)公司為主的用戶環(huán)境，大多數(shù)Ruby愛好者都是在這樣剛成立的公司里開發(fā)全新的項目。而我的工作更多的是基于最初的開發(fā)人員走后留下來的代碼。

　　Rails的讓人不堪的小秘密

　　在受雇寫Ruby程序之前，我也接手過一些歷史程序，它們有的歷史達(dá)數(shù)十年之久，代碼量數(shù)十萬行之多。你很容易在這么多代碼里找出寫的很爛的東西；有時候，這種爛代碼的數(shù)量多的讓人驚訝。

　　但是，在Rails開發(fā)中，你會發(fā)現(xiàn)一個讓人不堪忍受的小秘密；在我的職業(yè)生涯中，我見過的最亂的、最棘手的、最臭的代碼，都是在Ruby on Rails項目里找到的。我所見過的那些Rails項目，它們兩年下來積累的技術(shù)債務(wù)和廢棄物，跟一個10年之久的C/C++程序相比，會讓你覺得后者更干凈和優(yōu)雅。我說的并不是某個項目。我看到這種情況到處都是。

　　有時候我會想，這也顯示了這種語言的強大之處。如果在一個Rails應(yīng)用里有500個錯誤，你可以不停的往里面添加代碼、再添加代碼、點擊reload，一直到它好用為止。從來都不需要寫測試或重構(gòu)代碼。在很多語言和框架里，這種補到它不漏為止的開發(fā)方式顯而易見是行不通的。但Ruby on Rails卻提供了讓你這樣做的平臺。

　　不幸的是，作為它的直接后果，眾多我要處理的項目都可以被看作是一種應(yīng)急產(chǎn)品。從某種角度來看，這種圖省事的做法的后果還是由開發(fā)團隊來承擔(dān)，你這樣做一天把它解決了，可引出的相關(guān)問題和不可預(yù)料的副作用，你花2周都解決不掉。

　　題外話：經(jīng)常的，最初的開發(fā)人員會在完成開發(fā)后轉(zhuǎn)移到新的項目上。同時會有新員工接手這些代碼。管理部門會抱怨，為什么這新接手的團隊修改問題時沒有老團隊迅速呢？而新團隊遇到的問題是，在他們能給這些遺留的代碼上添加新功能前，他們需要讓這些代碼具有更高的測試覆蓋率，有可能還需要把它們分離成更小的模塊；在商業(yè)層面，一個永久不變的聲音是：測試和重構(gòu)就是拖延工期。看來這原創(chuàng)團隊都是比較明智的。

　　好了，牢騷發(fā)完了。

　　Rails的情況更為特殊！

　　Rails程序員有時候會顯得很傲慢和固執(zhí)。我不清楚這個判斷的可信度；我并沒有看到太多的人是這樣，但也許我跟這個社區(qū)太接近了，也許我本身也是傲慢和固執(zhí)的。

　　而我發(fā)現(xiàn)的卻是一種Rails例外主義。還記得第一次互聯(lián)網(wǎng)繁榮的時期嗎，當(dāng)時有幾個經(jīng)濟學(xué)家跳出來說不會的，這次不同，互聯(lián)網(wǎng)改變了游戲規(guī)則，市場會一直走高、走高，本質(zhì)上我感覺很相似，有些人相信，Ruby on Rails開發(fā)是某種不同的東西，不需要跟其它類型的軟件項目一樣。

　　這有一些例子，讓你明白我究竟在說什么：

• 設(shè)計模式是Java上的東西。Ruby里只管寫你的代碼就是了。
• Ruby里拋出的警告都是無聊的，禁止掉就行了。
• 的確沒有單元測試，而且對象隔離做起來了很難，沒有人這樣做。
• 到處打補丁對于其它語言來說是不贊成的，但Ruby沒問題。目前還沒有出現(xiàn)問題。
• 像Demeter定律這樣的東西在Ruby里并不是這么重要。
• 把方法分成私有和公有，這是變態(tài)控制，Ruby里不需要這樣做
• Java代碼里才會有代碼異味(code smell)。
• 只有在大項目里才會有這樣的問題(暗示這個項目永遠(yuǎn)不會變大)

　　我還看到了很多項目和子系統(tǒng)例外主義者：我知道一個類不應(yīng)該搞的太大，但是對這個類是有意義的，它是為了把所有的東西放到一個地方。

　　歡迎來到小人國

　　事實上，Ruby on Rails項目確實有一點很例外：都是小項目。上周在James Gray在Lone Star Ruby Conf大會上有個極好主題，他提到的巨型項目有4萬多行代碼。這讓我微微一笑，因為我被雇來做的頭兩個項目分別有5萬行和7萬行。這看起來不少，但根據(jù)行業(yè)標(biāo)準(zhǔn)，它們很小。

　　造成這種現(xiàn)象的原因有不少。Ruby是一種比Java更富有表達(dá)性的語言，所以，從某種程度上說，Rails項目，在相同的情況下，總是比那些更講究的語言顯得更小。

　　而且，Rails程序員很喜歡接受把系統(tǒng)分割成很多很小的、相互聯(lián)系的小應(yīng)用。但是經(jīng)驗告訴我們，這種策略是有問題的。

不，我想這導(dǎo)致Rails應(yīng)用體格較小的最大的原因是，顯而易見的：這個框架還很年輕。這個領(lǐng)域里有大量不成熟的產(chǎn)品。一個Rails應(yīng)用如果有3年的歷史，那就可以算是古老了。

　　我可以很有信心的說，這種情況不會一直持續(xù)下去。我們會看到越來越大的程序項目。我不需要鼓起勇氣就可以做下面的預(yù)言：很多項目將會遭遇像Lisp, Smalltalk, C++, Java等語言曾經(jīng)遭遇過的相同的架構(gòu)瓶頸。

　　你并不特殊

　　《programming literature from the 80s》這個作品讀起來非常的有趣。動態(tài)，面向?qū)ο蟮南到y(tǒng)引導(dǎo)了從小規(guī)模到中等規(guī)模的過渡。聽起來耳熟，是吧？

　　每一次的革命都會堅稱這次是與眾不同的，不會造成上次革命后出現(xiàn)的政黨紛爭和官僚腐敗。起初你很容易被這些宣傳感染。每個人都很興奮，熱情的去幫助；這時出現(xiàn)的問題還比較小；然而這只是市場的大機器還沒有注意到這場運動。

　　事實上，你要解決的問題也許并不是你想像的那樣例外。你思想里的這種拜占庭模式只是遠(yuǎn)古時代那些使用跟Ruby類似語言的人留下來的遺產(chǎn)。

　　不要驚慌

　　放松。我這里要說的并不是告訴你過去的幾年只是一場可愛的夢，Ruby實際上一直處在它應(yīng)有的地位上。

　　Ruby仍然是一種奇妙的語言，它令人驚異的地方就是它在付出微小的約束代價下能輕松的接納大型系統(tǒng)的設(shè)計模式。注入依賴？兒戲。對象委托和組合？小菜一碟。跟你的錯覺正好相反，Ruby并不拒絕嚴(yán)謹(jǐn)?shù)脑O(shè)計模式和SOLID編程原則；Ruby能做到的事是讓它們更容易的表達(dá)出來。事實上，Ruby強大的富于表達(dá)的架構(gòu)風(fēng)格是讓很多人第一眼就喜歡上它的原因。

　　拜托：請在你告訴我Ruby和Rails不需要任何的約束之前，請跟那些仍然在維護你當(dāng)初開發(fā)的Rails應(yīng)用的兄弟們聊一聊。

it知識庫：Rails程序員：你的代碼是我的地獄，轉(zhuǎn)載需保留來源！

鄭重聲明：本文版權(quán)歸原作者所有，轉(zhuǎn)載文章僅為傳播更多信息之目的，如作者信息標(biāo)記有誤，請第一時間聯(lián)系我們修改或刪除，多謝。