最近，我与其他开发人员有几次关于编程的有趣讨论。我经常有这样一个感觉，一些开发人员过于注意代码的整洁性。不要误会，我也力图代码整洁，并 在过去的几年写过很多篇关于代码整洁重要性的文章。但是当我在写代码的时候，整洁的代码不是我最重要的目标，它从来不能取代我最重要的目标——使程序运行 起来。最好可以运行得很好。

　　很多人喜欢谈论关于如何写整洁的代码。他们会强调自己在这方面的贡献。他们甚至带着Uncle Bob的绿色图标来写代码，这样他们就不会忽视了写整洁的代码是多么重要。不幸的是，我已经留意到很多情况下这些人并不太留意这些代码在做些什么，他们对 代码整洁的重视甚于代码的运行。有时候他们甚至懒得去了解ORM（对象关系映射）在背后是怎么运行的。或者他们会选择使用如Automapper这样的工 具，将实体映射到DTO（数据传输对象），即使Automapper与简单地搜索映射数据相比，效率低下得多。他们不在乎多个远程调用花费巨大，也不在乎 通过网络发送了太多的数据。如果他们不一遍又一遍的提高自己编写保龄球游戏代码的技巧，他们很可能会让数据库陷入死循环。

　　代码整洁不代表代码出色，这两者也没有必然的联系。对于我来说，卓越的代码能够很好的运行，有很多的性能，并且很容易阅读和很容易修改。我很了 解代码的可读性和易维护性都是很重要的。但是无论代码多么易懂和易修改，如果它不是在做它应该要做的事情（包括覆盖所有的边缘事件（case））或者它需 要更多的时间去完成，那么它就不是一段好的代码。当然，它可能是整洁的，但它不是好的代码，不对吗？

　　这并不代表你应该沉溺于过早的优化。除非你在这编程模型有和Neo一样的技能，否则你不可能成功地过早优化甚至四分之一的场景。但是还是有一些 指南可以帮助你避免最常见的执行问题。大多数的其他情况最好留到被证明是瓶颈时才处理。但是你应该至少思考一下这些代码是做什么的，整洁性带来的负面影响 是否值得。如果那些稍微比较不整洁的代码从正确性和执行来讲更有意义，我们也要毫不犹豫的去选择它们。

　　无论如何，力图保证代码的整洁性。但在牺牲更好的性能之前，要慎重考虑。