您认为值得为代码质量和可维护性取舍一些性能吗？我记得Jeff Atwood发表的一篇文章说硬件价格便宜，开发者不是。我想我想将其改为“硬件便宜，时间不对。”性能与代码质量对比
我注意到最近我一直在努力的MVC项目，有时候我失去了DAYS只是试图从我的应用程序中挤出一点额外的性能，我开始认为它不值得。我刚刚发现自己在设计ASP.NET MVC应用程序时遇到了麻烦。我喜欢IQueryable到死亡事实，它允许我追加到查询，所以我可以得到一些流利的代码使用它。但能够做到这样的事情似乎在控制器/ BLL上增加了更多的责任。
那么你怎么看？在网络应用程序的情况下，你可以将一些性能换算成可维护/更清晰的代码吗？你是否认为过早尝试优化你所能做的一切？因为我们已经看到你无法预测所有要求。
我真的不相信这是一个/或。如果你编写干净而简单的代码，只处理所有处理的次数，你就可以得到一些性能最好的代码。这真的很简单。
显而易见的答案是它取决于。如果您的应用程序足够慢以至于很大程度上影响可用性，并且您有测量结果来证明您的优化实际上有所帮助，那么牺牲可维护性可能是一个合理的折衷。另一方面，如果您没有测量或应用程序速度不够快而损害可用性，请务必阅读易读性，可维护性和灵活性。这只是归结为过早优化是所有邪恶的根源。
注：设计时间算法和架构优化不一定是件坏事，如果你知道性能这件事情影响你的应用程序，但在你的问题的情况下，你清晰地出现在谈论微 -optimization，以上适用。
另外，在您的具体情况中，如果您无法判断您的应用程序是否足够慢以至于无法使用可用性，那么为时过早。如果你可以，那么它不是。
我想这是我编辑的问题的根源。过早优化。 – 2009-02-14 22:35:41
我绝对不珍惜我自己对应用程序性能的时间在服务器端。如果我注意到我的网站在数据库请求等方面表现不佳，那么升级服务器硬件是另一种解决方案，可以（至少是短期的）解决我的问题，而无需查看代码。
但是，如果应用程序是非常网络 -inefficient，我会花很长一段时间试图改善的部分。发送大量数据会影响我的用户，无论我使用自己的服务器和上行链路 - 如果他们不喜欢性能，他们将不会回来。
但随着其他几个人说，这不是任何一个问题/或 - 这取决于情况很多，性能问题是多么沉重，在应用中等等
无论是质量（意为容易阅读）也不是最重要的表现 - 正确性是！
托尼霍尔爵士有句名言：“我们应该忘记小效率，约97％的时间：过早优化是万恶之源。”
报价的第一部分已经被人们遗忘了（它并不容易），因此许多没有经验的工程师在软件项目的设计阶段没有考虑性能。这几乎总是一个致命的错误，因为后来设计糟糕的应用程序由于基本的设计缺陷而难以优化。同时，当性能瓶颈还不知道时，通过巧妙的技巧尝试节省CPU周期毫无意义。
至于你的问题，我认为一个设计合理的应用程序是为了应付其特定的性能要求而不需要以不可维护或“不洁净”的方式进行编码。只有当发现这些性能瓶颈时（例如，您发现您的应用程序在其代码的10％中花费了90％的时间），您可能需要谨慎考虑在少量代码中使用优化技巧，以便它仍然存在可维护且易于理解。
很多Web应用程序的优点是可以使用各种缓存技术大幅提升性能。当你控制服务器环境（就像你说的那样，硬件很便宜），你可以确保将你的Web应用程序的常用部分放在地狱之外。如果您使用抽象层，这并不能真正保留不可维护的代码。 Facebook是Web应用程序的一个很好的例子，着名的是它利用缓存（memcached）的优势。
在某种程度上同意这一点。开发人员的时间是昂贵的，分析和优化代码是一个非常昂贵的方式来获得可能没有太多的性能增益。说到这取决于应用程序的类型和您所处的环境。
如果您正在开发一个Web应用程序，那么您可以通过修复一些简单的问题（主要在客户端-侧）。诸如通过连接CSS/JS文件，构建映像精灵等来减少HTTP请求......与实际分析代码相比将带来巨大的收益，并且对开发人员时间非常有用。
我不知道我同意'硬件比开发人员报价便宜。当然，硬件可以帮助您扩展您的应用程序，并赋予它更多性能优势，但您最不想做的事情依赖于强健的硬件。如果您的软件与您的硬件紧密耦合，那么在迁移到新的数据中心，升级服务器等方面失去了很大的灵活性，而从长远来看，如果没有这种灵活性，成本可能会很高。假设您决定有效扩展应用程序的方式是转向亚马逊的EC2基础架构。如果您的应用程序需要 32GB内存在每台服务器上，您将发现这样的移动可能需要重新写入。
所有很好的答案。速度和干净的代码之间的选择是错误的二分法。
我还没有看到你的工作，但我看过别人，它总是同一个故事：
“这不是足够快，我认为这个问题是在XXX的代码。我想我会调整这一点，看看是否有帮助。”
你不知道的问题是存在的。
你猜测。
决不做任何事根据猜测。
（当然你绝不会那样做，你会吗？但大多数人做的。）
您可以剖析代码。
我最喜欢的方法是在缓慢的时候停下来几次，问问它在做什么。
这通常是一个人不可能猜到的惊喜。
质量的标准定义是“符合客户期望（要求）”。如果你已经完成了很好的需求收集，那么你已经同意了某些性能标准。如果你的应用符合这个标准，那么你就是在浪费你或者客户的时间和金钱，试图做得更好。
编写松散耦合，内聚和易读的代码只是降低了与错误和需求变化相关的风险和成本。如果你准备接受“泥巴球”编码的风险，那么继续。我，我喜欢赚钱。
在谈论性能之前，您应该真正了解大O符号，您可以在有关算法或维基百科的任何书籍中查看。
Big O表示法说明了函数需要多少时间。例如。从0到100的列表有O（N）。无论O符号的数量多少都保持不变。此函数具有线性运行时间，无法以任何方式进行改进。
现在，如果你有一个从0到100的列表，并且对于列表中的每个项目，你做了另一个从0到100的列表，你得到O（N^2），这是工作的两倍，运行时间差得多比O（N）。
在编写必须具有良好性能的应用程序时，我们讨论如何获得用O表示法编写的良好运行时。无论窗口是否使用< 0.1秒或大于1秒，使用相同的算法无关紧要。
这意味着，你做的秒的剃须可能没有一个不同的O符号，所以你没有以任何方式真正优化你的代码 - 所以对你来说，在asp.net中编写MVC我会建议你专注于编写干净可读的代码:)
当您了解了O符号后，您将能够以最少的方式知道要选择哪些算法（如何对列表进行排序，填充它们，检索数据）在O表示法中运行时间，并且这种知识可以使代码快得多，而不是通过缩短代码的秒数来写出紧密循环所能做到的。
Makach ^^
好的设计往往牺牲改善总体方案的一些性能。例如，编写代码层有成本，但我们仍然这样做，因为它使得长期更容易地更改代码。我们远程使用应用程序服务器，并不是因为它是最有效的方式，而是因为它的规模。
我记得Code Complete 2，麦康奈尔给出了一个例子，使代码非常难以阅读是必要的优化。这个特殊的例子是一种加密算法。该程序被制作成一种方法来消除调用函数的开销。所以，这确实是一个时间和地点，但我认为这很少见。
至于解决性能问题，在大多数情况下，我发现性能问题是数据库/ IO相关或a（内存泄漏）。正如其他人所建议的那样，剖析是一条可行的路线，但追踪许多错误仍然很棘手。
至于硬件问题，硬件放松了，但并没有消除对优化代码的需求。速度更快的硬件只能让我们使用不太理想的语言，并且可以做出非常棒的图形用户界面。
这是经典的折衷表现与支持性之一。在编写COBOL结构化代码时（在20世纪80年代早期），我首先遇到了这种交易。很明显，通过将所有内容分离成可重复使用的模块，创建额外的分支和堆栈指针管理，并在早期的计算机上降低性能。答案是将函数组合在一起（并复制某些函数），以减少用于调用模块的代码交换和堆栈指针操作。这导致了一个支持性问题。
接下来，最近，我不得不对数据库取消规范化，以创建可以缓存的大对象。这里的问题是阅读CRM系统导航期间的角色和责任访问权限。长话短说，规范化的版本花了很长时间来处理和加载每个屏幕，所以30年来我仍然参与这个经典的折衷。
我不怀疑你不能同时拥有这两个事实。这个问题的确是针对你认为值得为其他人进行一些表现交换等。对不起，我说错了。 – 2009-02-14 22:38:57
我总是假装我是我自己的客户，我正在为...设计一个应用程序...只要它工作正常，并且没有其他人正在关注那些关心它是多么干净的代码......只要它作品 – dswatik 2009-02-14 22:45:46
Touche业务员。 – 2009-02-14 22:48:00