在 SDTConf 2009論壇上，Corey Haines和我共同主持了一個叫做“最臭的臭彈”的研討會。會議上，我們試圖去尋找下面兩個（不同的）問題的答案：

• 作為一個經驗豐富的開發(fā)人員，回顧往事，最臭的讓你最受折磨的代碼是什么樣的？也就是說，請指出一種代碼，如果你能根除掉這種很臭的代碼，那么在你的程序中的大部分設計問題都會迎刃而解
• 我們有如此多的不同的原則和指導來幫助我們去實現(xiàn)好的設計。對于一個新手來說，他應該從哪里開始？哪種代碼風味（code smell）或原則，對于一個新手來說，可以最大程度的幫助他們做出好的設計（節(jié)省好幾年去總結經驗）？

　　盡管字面上這兩個問題很相似，但我認為這第二個問題更具有廣泛的意義，跟第一個有很大的不同。

　　不管怎樣，這次研討會都能稱得上是一個熱鬧的會議。我們有不少很厲害的辯手來批判所謂的最臭的代碼的味道（最臭的臭彈）：

• Corey Haines的觀點：重復的代碼
• 我的觀點：Primitive Obsession(總是使用底層的數(shù)據(jù)結構/原始的數(shù)據(jù)類型，而使用經過更高層抽象過的數(shù)據(jù)機構或其它可以n倍的減少復雜性。這并不只針對面向對象的編程。這指的是缺乏在應該進行抽象的數(shù)據(jù)層面上進行抽象)
• Matt Van Vleet 的觀點：單一功能原則
• Venkat Subramaniam 的觀點：避免寫代碼
• Jim Weirich (他并沒有出席這次會議)的觀點： 共生性

　　我們都認為避免寫代碼（只有在沒有其它辦法的時候才去寫新代碼）是最重要的需要讓每個開發(fā)人員都認識到的問題。大量的重復的代碼，劣質的代碼（存在于各種項目中）積累到今天已經無法統(tǒng)計了。在很多情況中程序員根本不喜歡去搜尋一下可以利用的程序，他們只知道自己去寫。這就是為什么我們要去以代碼行數(shù)(LoC)來作為評審代碼效率和性能的原因。一般來講，好的程序員的開發(fā)速度會比一般的程序員的速度快20倍以上，因為他們對重復利用現(xiàn)有代碼的認識完全不在一個層次上。

　　很多人對;Not Invented Here Syndrome（簡單解釋為開發(fā)團隊不喜歡使用不是自己寫的程序，縮寫為NIHS）“這個說法感到困惑。我個人認為NIHS對于我們這個領域里的進步有很重要的意義。NIHS體現(xiàn)在設計和解決方案層面。Joel 寫了一篇很有趣的博客，題為 In Defense of Not-Invented-Here Syndrome，大家可以參考看看。

　　然而，如果當大家都認為項目里我們必須自己寫點自己的代碼時候，那么我們最應該提防的一件事情是什么呢？SRP 和 Connascence 真的可以幫你實現(xiàn)高內斂的設計。如果程序不是高內斂的，我們應該很容易可以在里面發(fā)現(xiàn)重復的代碼（至少是概念上的重復），你也會發(fā)現(xiàn)只要在設計上選擇正確的方式進行抽象提取就能很好的解決這種問題。所以代碼重復和Primitive Obsession實際是相互因果的關系。

　　據(jù)我的經驗，我要補充一下，我曾看到過有程序并沒有多少的重復，但卻非常讓人難以理解，這是為什么？所以我要提出，只要是代碼進行了較好的抽象，它就會很容易讓人理解和易于推理出其功能。同樣，如果你試圖去消除重復的代碼，在某一程度上，這里并沒有字面上的重復，但是這里卻存在一個概念上的重復，那么只有對它進行更高一級的抽象就能有效的解決這個問題。因此我的結論是：回顧往日經歷， Primitive Obsession 才是針對低質量設計最大的難題，也就是所說的最臭的臭蛋。

　　【英文出處】： Biggest Stinkers

it知識庫：最臭的臭彈（Biggest Stinkers），轉載需保留來源！

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