性能与代码质量

Question

你认为为了代码质量和可维护性而牺牲一些性能值得吗？我记得Jeff Atwood的一篇文章，他说硬件很便宜，开发人员不便宜。我想我想把它改成“硬件便宜，时间不便宜”。

我注意到我最近正在做的一个MVC项目，有时我只是为了从我的应用程序中挤出一点额外的性能而损失几天时间，我开始认为这是不值得的。我刚刚发现自己在设计ASP.NET MVC应用程序时遇到了麻烦。我非常喜欢IQueryable，因为它允许我附加到查询中，这样我就可以获得一些流畅的代码来使用它。但是，能够做这样的事情似乎增加了控制器/BLL的更多责任。

你怎么看？在web应用程序的情况下，你愿意牺牲一些性能来换取可维护/更干净的代码吗？你认为过早地尝试优化你所能做的一切是合适的吗？因为正如我们所看到的，你不能预测所有的需求。

Answer 1

如果性能有问题，请分析并确定问题。如果性能有问题，请修复problem.

• Repeat的步骤1-4如果necessary

• ???

• Profit

，请修复

Answer 2

托尼霍尔爵士说过一句名言：“我们应该忘记小效率，比如说97%的时间:过早优化是一切邪恶的根源。”

这句话的第一部分几乎被遗忘了(它不是那么容易说出来的)，因此许多缺乏经验的工程师在软件项目的设计阶段不会考虑性能。这几乎总是一个致命的错误，因为后来由于基本的设计缺陷，设计糟糕的应用程序很难优化。同时，在性能瓶颈尚不清楚的情况下，尝试使用巧妙的技巧来节省CPU周期是没有意义的。

关于你的问题，我认为一个设计得当的应用程序不需要以一种不可维护或“不干净”的方式进行编码。只有当这些性能瓶颈被发现时(例如，你发现你的应用程序在10%的代码中花费了90%的时间)，你才可能想要考虑在少量的代码中谨慎地使用优化技巧，以便它仍然可维护和易于理解。

许多Web应用程序的伟大之处在于，使用各种缓存技术可以极大地提高性能。当您控制服务器环境时(就像您说的，硬件很便宜)，您可以确保将Web应用程序的那些常用部分缓存到地狱中。如果你使用抽象层，这并不会导致代码不可维护。Facebook就是利用缓存(memcached)优势的Web应用程序的一个很好的例子。

Answer 3

我真的不相信这是非此即彼的选择。如果您编写干净、简单的代码，并且这些代码的处理次数恰好与它应该执行的次数相同，那么您将拥有一些性能最佳的代码。事情真的就这么简单。