Sitemap" content="www.duozhankeji.com">
全國免費熱線:
優秀程序員眼中的整潔代碼
作者:admin 点击:18034次 日期:2015-06-18
字號::T | T

  有多少程序員,就有多少定義。所以我只詢問了一些非常知名且經驗豐富的程序員。

  Bjarne Stroustrup,C++语言发明者,C++ Programming Language(中译版《C++程序设计语言》)一书作者。
  我喜歡優雅和高效的代碼。代碼邏輯應當直截了當,叫缺陷難以隱藏;盡量減少依賴關系,使之便于維護;依據某種分層戰略完善錯誤處理代碼;性能調至最優,省得引誘別人做沒規矩的優化,搞出一堆混亂來。整潔的代碼只做好一件事。
  Bjarne用了“優雅”一詞。說得好!我MacBook上的詞典提供了如下定義:外表或舉止上令人愉悅的優美和雅觀;令人愉悅的精致和簡單。注意對“愉悅”一詞的強調。Bjarne顯然認爲整潔的代碼讀起來令人愉悅。讀這種代碼,就像見到手工精美的音樂盒或者設計精良的汽車一般,讓你會心一笑。
  Bjarne也提到效率——而且兩次提及。這話出自C++發明者之口,或許並不出奇;不過我認爲並非是在單純追求速度。被浪費掉的運算周期並不雅觀,並不令人愉悅。留意Bjarne怎麽描述那種不雅觀的結果。他用了“引誘”這個詞。誠哉斯言。糟糕的代碼引發混亂!別人修改糟糕的代碼時,往往會越改越爛。
  务实的Dave Thomas和Andy Hunt从另一角度阐述了这种情况。他们提到破窗理论4。窗户破损了的建築让人觉得似乎无人照管。于是别人也再不关心。他们放任窗户继续破损。最终自己也参加破坏活动,在外墙上涂鸦,任垃圾堆积。一扇破损的窗户开辟了大厦走向倾颓的道路。
  Bjarne也提到完善錯誤處理代碼。往深處說就是在細節上花心思。敷衍了事的錯誤處理代碼只是程序員忽視細節的一種表現。此外還有內存泄漏,還有競態條件代碼。還有前後不一致的命名方式。結果就是凸現出整潔代碼對細節的重視。
  Bjarne以“整潔的代碼只做好一件事”結束論斷。毋庸置疑,軟件設計的許多原則最終都會歸結爲這句警語。有那麽多人發表過類似的言論。糟糕的代碼想做太多事,它意圖混亂、目的含混。整潔的代碼力求集中。每個函數、每個類和每個模塊都全神貫注于一事,完全不受四周細節的幹擾和汙染。

  Grady Booch,Object Oriented Analysis and Design with Applications(中译版《面向对象分析与设计》)一书作者。
  整潔的代碼簡單直接。整潔的代碼如同優美的散文。整潔的代碼從不隱藏設計者的意圖,充滿了幹淨利落的抽象和直截了當的控制語句。
  Grady的觀點與Bjarne的觀點有類似之處,但他從可讀性的角度來定義。我特別喜歡“整潔的代碼如同優美的散文”這種看法。想想你讀過的某本好書。回憶一下,那些文字是如何在腦中形成影像!就像是看了場電影,對吧?還不止!你還看到那些人物,聽到那些聲音,體驗到那些喜怒哀樂。
  阅读整洁的代码和阅读Lord of the Rings(中译版《指环王》)自然不同。不过,仍有可类比之处。如同一本好的小说般,整洁的代码应当明确地展现出要解决问题的张力。它应当将这种张力推至高潮,以某种显而易见的方案解决问题和张力,使读者发出“啊哈!本当如此!”的感叹。
  窃以为Grady所谓“干净利落的抽象”(crisp abstraction),乃是绝妙的矛盾修辞法。毕竟crisp几乎就是“具体”(concrete)的同义词。我MacBook上的词典这样定义crisp一词:果断决绝,就事论事,没有犹豫或不必要的细节。尽管有两种不同的定义,该词还是承载了有力的信息。代码应当讲述事实,不引人猜测。它只该包含必需之物。读者应当感受到我们的果断决绝。

  “老大”Dave Thomas,OTI公司创始人,Eclipse战略教父。
  整洁的代码应可由作者之外的開發者阅读和增补。它应当有单元测试和验收测试。它使用有意义的命名。它只提供一种而非多种做一件事的途径。它只有尽量少的依赖关系,而且要明确地定义和提供清晰、尽量少的API。代码应通过其字面表达含义,因为不同的语言导致并非所有必需信息均可通过代码自身清晰表达。
  Dave老大在可讀性上和Grady持相同觀點,但有一個重要的不同之處。Dave斷言,整潔的代碼便于其他人加以增補。這看似顯而易見,但亦不可過分強調。畢竟易讀的代碼和易修改的代碼之間還是有區別的。
  Dave将整洁系于测试之上!要在十年之前,这会让人大跌眼镜。但测试驱动開發(Test Driven Development)已在行業中造成了深远影响,成为基础规程之一。Dave说得对。没有测试的代码不干净。不管它有多优雅,不管有多可读、多易理解,微乎测试,其不洁亦可知也。
  Dave兩次提及“盡量少”。顯然,他推崇小塊的代碼。實際上,從有軟件起人們就在反複強調這一點。越小越好。
  Dave也提到,代码应在字面上表达其含义。这一观点源自Knuth的“字面编程”(literate programming)5。结论就是应当用人类可读的方式来写代码。

  Michael Feathers,Working Effectively with Legacy Code(中译版《修改代码的艺术》)一书作者。
  我可以列出我留意到的整潔代碼的所有特點,但其中有一條是根本性的。整潔的代碼總是看起來像是某位特別在意它的人寫的。幾乎沒有改進的余地。代碼作者什麽都想到了,如果你企圖改進它,總會回到原點,贊歎某人留給你的代碼——全心投入的某人留下的代碼。
  一言以蔽之:在意。這就是本書的題旨所在。或許該加個副標題,如何在意代碼。
  Michael一針見血。整潔代碼就是作者著力照料的代碼。有人曾花時間讓它保持簡單有序。他們適當地關注到了細節。他們在意過。

  Ron Jeffries,Extreme Programming Installed(中译版《极限编程实施》)以及Extreme Programming Adventures in C#(中译版《C#极限编程探险》)作者。
  Ron初入行就在战略空军司令部(Strategic Air Command)编写Fortran程序,此后几乎在每种机器上编写过每种语言的代码。他的言论值得咀嚼。
  近年來,我開始研究貝克的簡單代碼規則,差不多也都琢磨透了。簡單代碼,依其重要順序:
  能通過所有測試;
  沒有重複代碼;
  体现系統中的全部设计理念;
  包括盡量少的實體,比如類、方法、函數等。
  在以上諸項中,我最在意代碼重複。如果同一段代碼反複出現,就表示某種想法未在代碼中得到良好的體現。我盡力去找出到底那是什麽,然後再盡力更清晰地表達出來。
  在我看来,有意义的命名是体现表达力的一种方式,我往往会修改好几次才会定下名字来。借助Eclipse这样的现代编码工具,重命名代价极低,所以我无所顾忌。然而,表达力还不只体现在命名上。我也会检查对象或方法是否想做的事太多。如果对象功能太多,最好是切分为两个或多个对象。如果方法功能太多,我总是使用抽取手段(Extract Method)重构之,从而得到一个能较为清晰地说明自身功能的方法,以及另外数个说明如何实现这些功能的方法。
  消除重複和提高表達力讓我在整潔代碼方面獲益良多,只要銘記這兩點,改進髒代碼時就會大有不同。不過,我時常關注的另一規則就不太好解釋了。
  這麽多年下來,我發現所有程序都由極爲相似的元素構成。例如“在集合中查找某物”。不管是雇員記錄數據庫還是名-值對哈希表,或者某類條目的數組,我們都會發現自己想要從集合中找到某一特定條目。一旦出現這種情況,我通常會把實現手段封裝到更抽象的方法或類中。這樣做好處多多。
  可以先用某種簡單的手段,比如哈希表來實現這一功能,由于對搜索功能的引用指向了我那個小小的抽象,就能隨需應變,修改實現手段。這樣就既能快速前進,又能爲未來的修改預留余地。
  另外,該集合抽象常常提醒我留意“真正”在發生的事,避免隨意實現集合行爲,因爲我真正需要的不過是某種簡單的查找手段。
  減少重複代碼,提高表達力,提早構建簡單抽象。這就是我寫整潔代碼的方法。
  Ron以寥寥數段文字概括了本書的全部內容。不要重複代碼,只做一件事,表達力,小規模抽象。該有的都有了。

  Ward Cunningham,Wiki发明者,eXtreme Programming(极限编程)的创始人之一,Smalltalk语言和面向对象的思想领袖。所有在意代码者的教父。
  如果每個例程都讓你感到深合己意,那就是整潔代碼。如果代碼讓編程語言看起來像是專爲解決那個問題而存在,就可以稱之爲漂亮的代碼。
  這種說法很Ward。它教你聽了之後就點頭,然後繼續聽下去。如此在理,如此淺顯,絕不故作高深。你大概以爲此言深合己意吧。再走近點看看。
  “……深合己意”。你最近一次看到深合己意的模块是什么时候?模块多半都繁复难解吧?难道没有触犯规则吗?你不是也曾挣扎着想抓住些从整个系統中散落而出的线索,编织进你在读的那个模块吗?你最近一次读到某段代码、并且如同对Ward的说法点头一般对这段代码点头,是什么时候的事了?
  Ward期望你不會爲整潔代碼所震驚。你無需花太多力氣。那代碼就是深合你意。它明確、簡單、有力。每個模塊都爲下一個模塊做好准備。每個模塊都告訴你下一個模塊會是怎樣的。整潔的程序好到你根本不會注意到它。設計者把它做得像一切其他設計般簡單。
  那Ward有關“美”的說法又如何呢?我們都曾面臨語言不是爲要解決的問題所設計的困境。但Ward的說法又把球踢回我們這邊。他說,漂亮的代碼讓編程語言像是專爲解決那個問題而存在!所以,讓語言變得簡單的責任就在我們身上了!當心,語言是冥頑不化的!是程序員讓語言顯得簡單。

發表評論

昵稱 * 驗證碼 * 驗證碼
上一篇: 評點六種Java異常處理的陋習
下一篇: Java的故事:Oracle和Google針對Java的對決

資質證書

CMMI Ⅲ APPRAISAL ID:30062
ISO9001:08915Q20090ROS
ISO27001:04817I20037R0S
高新技術企業:GR201753000141
網站问题免费诊断

电子商务三位一体發展戰略

技術研發

業務培训

實戰運營

戰略布局