英文原文：Clean Code Versus Great Code

　　最近，我與其他開發(fā)人員有幾次關(guān)于編程的有趣討論。我經(jīng)常有這樣一個感覺，一些開發(fā)人員過于注意代碼的整潔性。不要誤會，我也力圖代碼整潔，并在過去的幾年寫過很多篇關(guān)于代碼整潔重要性的文章。但是當(dāng)我在寫代碼的時候，整潔的代碼不是我最重要的目標(biāo)，它從來不能取代我最重要的目標(biāo)——使程序運(yùn)行起來。最好可以運(yùn)行得很好。

　　很多人喜歡談?wù)撽P(guān)于如何寫整潔的代碼。他們會強(qiáng)調(diào)自己在這方面的貢獻(xiàn)。他們甚至帶著Uncle Bob的綠色圖標(biāo)來寫代碼，這樣他們就不會忽視了寫整潔的代碼是多么重要。不幸的是，我已經(jīng)留意到很多情況下這些人并不太留意這些代碼在做些什么，他們對代碼整潔的重視甚于代碼的運(yùn)行。有時候他們甚至懶得去了解ORM（對象關(guān)系映射）在背后是怎么運(yùn)行的。或者他們會選擇使用如Automapper這樣的工具，將實(shí)體映射到DTO（數(shù)據(jù)傳輸對象），即使Automapper與簡單地搜索映射數(shù)據(jù)相比，效率低下得多。他們不在乎多個遠(yuǎn)程調(diào)用花費(fèi)巨大，也不在乎通過網(wǎng)絡(luò)發(fā)送了太多的數(shù)據(jù)。如果他們不一遍又一遍的提高自己編寫保齡球游戲代碼的技巧，他們很可能會讓數(shù)據(jù)庫陷入死循環(huán)。

　　代碼整潔不代表代碼出色，這兩者也沒有必然的聯(lián)系。對于我來說，卓越的代碼能夠很好的運(yùn)行，有很多的性能，并且很容易閱讀和很容易修改。我很了解代碼的可讀性和易維護(hù)性都是很重要的。但是無論代碼多么易懂和易修改，如果它不是在做它應(yīng)該要做的事情（包括覆蓋所有的邊緣事件（case））或者它需要更多的時間去完成，那么它就不是一段好的代碼。當(dāng)然，它可能是整潔的，但它不是好的代碼，不對嗎？

　　這并不代表你應(yīng)該沉溺于過早的優(yōu)化。除非你在這編程模型有和Neo一樣的技能，否則你不可能成功地過早優(yōu)化甚至四分之一的場景。但是還是有一些指南可以幫助你避免最常見的執(zhí)行問題。大多數(shù)的其他情況最好留到被證明是瓶頸時才處理。但是你應(yīng)該至少思考一下這些代碼是做什么的，整潔性帶來的負(fù)面影響是否值得。如果那些稍微比較不整潔的代碼從正確性和執(zhí)行來講更有意義，我們也要毫不猶豫的去選擇它們。

　　無論如何，力圖保證代碼的整潔性。但在犧牲更好的性能之前，要慎重考慮。

it知識庫：整潔的代碼 VS 卓越的代碼，轉(zhuǎn)載需保留來源！

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