英文原文：Clean Code Versus Great Code

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

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

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

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

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