英文原文：Clean Code Versus Great Code

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

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

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

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

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

it知識(shí)庫(kù)：整潔的代碼 VS 卓越的代碼，轉(zhuǎn)載需保留來(lái)源！

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