站長工具,就用查一把!
收錄查詢  關鍵詞排名  Alexa排名  PR檢測  友情檢測  IP反查  WHOIS查詢    更多查詢  
  收藏  最近查詢 查一把
信息分類 首頁 » 資訊信息

好站推薦

IT新聞

  業界猜想

  名人名企

建站推廣

  站長創業

  運營推廣

設計編程

  美工設計

  開發編程

你的代碼是我的地獄
信息來源:cnblogs 發布時間:2011/9/15

本文是從 Your Code is My Hell 這篇文章翻譯而來。

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

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

  我知道,我的這種經歷在Ruby和Rails程序員中并不常見。由于Ruby/Rails的高產和創業公司為主的用戶環境,大多數Ruby愛好者都是在這樣剛成立的公司里開發全新的項目。而我的工作更多的是基于最初的開發人員走后留下來的代碼。

  Rails的讓人不堪的小秘密

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

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

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

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

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

  好了,牢騷發完了。

  Rails的情況更為特殊!

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

  而我發現的卻是一種“Rails例外主義“。還記得第一次互聯網繁榮的時期嗎,當時有幾個經濟學家跳出來說”不會的,這次不同,互聯網改變了游戲規則,市場會一直走高、走高“,本質上我感覺很相似,有些人相信,Ruby on Rails開發是某種不同的東西,不需要跟其它類型的軟件項目一樣。

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

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

  我還看到了很多項目和子系統例外主義者:“我知道一個類不應該搞的太大,但是對這個類是有意義的,它是為了把所有的東西放到一個地方“。

  歡迎來到小人國

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

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

  而且,Rails程序員很喜歡接受把系統分割成很多很小的、相互聯系的小應用。但是經驗告訴我們,這種策略是有問題的。

  不,我想這導致Rails應用體格較小的最大的原因是,顯而易見的:這個框架還很年輕。這個領域里有大量不成熟的產品。一個Rails應用如果有3年的歷史,那就可以算是古老了。

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

  你并不特殊

  《programming literature from the 80s》這個作品讀起來非常的有趣。動態,面向對象的系統引導了從“小規模“到”中等規模“的過度。聽起來耳熟,是吧?

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

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

  不要驚慌

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

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

  拜托:請在你告訴我Ruby和Rails不需要任何的約束之前,請跟那些仍然在維護你當初開發的Rails應用的兄弟們聊一聊。

轉載請注明出處:站長工具 信息來源:http://news.cnblogs.com/n/115197/
網友點評
b北京赛车视频