你的代码，整洁还是优秀？
最近我和其他的开发人员讨论了如何编写代码。我总认为一些开发者过分强调代码整洁的重要性。(别误会，当然我也会努力使我的代码整洁。在过去的那些年里我写过很多很多关于代码整洁的文章。)但是在我的编程中，代码整洁始终是第二位的，比他更重要的，是让代码能够正常工作，最好是让它运行得更出色。
很多人喜欢谈论关于整洁代码的话题。他们喜欢强调他们对此的贡献，甚至希望穿着绿色的外套，来时刻提醒他们整洁代码的重要性。据我观察，不幸的是，他们总是认为编写整洁代码的重要性要高于代码功能的实现。有时他们甚至不用心去想他们的ORM在幕后做了什么。或者他们使用像Automapper这样的东西来匹配DTO的实体，尽管与检索工程数据相比那显得可悲得低效。他们一般不考虑并发访问甚至在网络上传输过量的数据。他们不是在编写完美的保龄球游戏，而是在一遍又一遍地访问数据库。
整洁的代码不一定是优秀的代码。对我而言，优秀的代码是运行得很棒的代码，它容易理解而又容易改变。我认为，在第一次读代码时你的理解程度与修改其的难易程度更为重要。然而，不管它有多易读懂或者多易更改，如果它工作得与人们的希望不一致(没有覆盖到所有的可能)或者占用了太多的运行时间，它就不是真正优秀的代码。当然，它也会是整洁的，但绝不是优秀的，不是吗？
这并不意味着你需要沉迷于过早的优化。除非你拥有像《黑客帝国》中的Neo那样的超能力，否则你是不可能提前优化你的代码的。这里有一些帮助你避免常见错误的例子。其他的问题在被证明为瓶颈以前还是最好忽视掉。但是你至少应该清楚你的代码究竟在做些什么，是否没有缺点，是否清洁。在稍微干净的代码与具有更佳含义的代码之间，请不要犹豫。
尽力编写整洁的代码。但是在做出决定之前，一定要再三考虑你是否牺牲了其成为优秀代码的可能。
[原文]
Clean Code Versus Great Code
I've had some interesting discussions with other developers about writing code recently. I often have the impression that some developers put too much emphasis on clean code. Don't get me wrong, i strive for clean code as well, and have written about its importance quite a lot in the past couple of years. But when i'm coding, clean code is my secondary goal and it could never take the place of my primary goal: making it work. And preferably, i want to make it work great.
A lot of people love to talk the talk when it comes to writing clean code. They'll stress their dedication to it, in some cases even wearing Uncle Bob's green band while coding so they'll never lose sight of what's incredibly important to them: writing clean code. Unfortunately, i've noticed on numerous occasions that many of these people don't always put as much emphasis on what the code is doing compared to how it looks. Sometimes they don't really bother to learn what their ORM is doing behind the scenes. Or they'll prefer to use something like Automapper to map entities to DTO's even though it is woefully inefficient compared to simply retrieving projected data. They don't always think about the cost of multiple remote calls or sending way too much data over the wire. And when they're not perfecting the art of writing bowling games over and over again, they just might hit the database in loop.
Clean code is not necessarily great code, nor is great code necessarily clean code. To me, great code is code that works great, performs great, is easy to understand and easy to change. In that order. I know all too well how important it is to easily understand code when you first read it, and to be able to easily and safely make changes to it. But no matter how easy it is to read or change, if it's not doing what it should be doing (including covering all the corner cases) or if it's taking more than its fair share of time to do it, it's not good code. Sure, it might be clean, but it's not great, is it?
That doesn't mean that you should indulge in premature optimization. Unless you have Neo-like skills in this coding Matrix, you're unlikely to be right in even a quarter of all scenarios that you want to optimize prematurely. There are however a few guidelines which will help you avoid most common performance problems. Most other situations are better left ignored until proven by a profiler to be a bottleneck. But you should at least think about what the code is actually doing and whether or not any downsides to that are worth the cleanliness. Don't hesitate to go with the slightly less clean looking code if that code makes more sense from a correctness and performance point of view.
By all means, strive to write clean code. But think twice before you sacrifice its ability to be great.