绩效与代码质量

您是否认为值得在代码质量和可维护性方面进行一些性能折衷？我记得杰夫阿特伍德的一篇文章说硬件很便宜,开发人员不是.我想我想把它改成"硬件便宜,时间不是."

我注意到我最近一直在努力的一个MVC项目,有时我会失去DAYS只是试图从我的应用程序中挤出一点额外的性能,我开始认为它不值得.我刚刚发现自己在设计ASP.NET MVC应用程序时遇到了麻烦.我喜欢IQueryable to death,因为它允许我附加到查询,所以我可以得到一些流利的代码来使用它.但是能够做这样的事情似乎在控制器/ BLL上增加了更多的责任.

所以你怎么看？在Web应用程序的情况下,你可以为可维护/更清洁的代码折衷一些性能吗？您是否认为过早地尝试优化您可以做的一切？因为正如我们所见,你无法预测所有要求.

让它起作用

如果性能有问题,请查看并确定问题

解决问题.

如有必要,请重复步骤1-4

???

利润

托尼·霍尔爵士说:"我们应该忘记效率低下,大约97%的时间说:过早的优化是所有邪恶的根源."

报价的第一部分几乎被遗忘了(它不会轻易说不出口),因此许多缺乏经验的工程师在软件项目的设计阶段都没有考虑性能.这几乎总是一个致命的错误,因为后来由于基本的设计缺陷,设计糟糕的应用程序很难优化.同时,当尚未知道性能瓶颈时,使用巧妙的技巧试图节省CPU周期是没有意义的.

至于你的问题,我认为设计适当的应用程序旨在应对其特定的性能要求,不需要以不可维护或"不干净"的方式编码.只有当发现这些性能瓶颈时(例如,您发现您的应用程序将90%的时间花在10%的代码中),您可能需要谨慎地考虑在少量代码中使用优化技巧,以便它仍然可维护,容易明白.

许多Web应用程序的优点在于可以使用各种缓存技术大幅提高性能.当您控制服务器环境时(并且,就像您说的那样,硬件很便宜),您可以确保从Web应用程序的常用部分缓存出来.如果使用抽象层,这实际上不会产生不可维护的代码.Facebook是一个很好的Web应用程序示例,它以其优势利用缓存(memcached)而闻名.

我真的不相信这是一个/或者.如果您编写干净,简单的代码,只执行所有处理的次数,那么您将拥有一些性能最佳的代码.这真的很简单.