我解决了许多问题,其中大部分来自Top Coder。我会得到很多答案,但大多数情况下,我都会得到效率低下的解决方案。
在实际的实现中-有效解决问题真的重要吗?如果可以,我该如何改善呢?
我解决了许多问题,其中大部分来自Top Coder。我会得到很多答案,但大多数情况下,我都会得到效率低下的解决方案。
在实际的实现中-有效解决问题真的重要吗?如果可以,我该如何改善呢?
Answers:
最好的解决方案是(按重要性增加的顺序)高效,可维护和可行的解决方案。
^^^这是您从此答案中真正需要做的唯一事情。^^^
效率很重要。由于我们拥有丰富的硬件,因此可能比以前少一些,但是Performance是一项功能。在比赛中,效率显然很重要。您应该知道如何编写有效的代码。更重要的是,您应该了解最佳实践,这些最佳实践将在不牺牲应用程序的及时性或可维护性的情况下生成高效,性能良好的代码。实际上,这是使用平台和语言的丰富经验可以带来很多收益的地方。
不过,更重要的是(在95%的情况下)有一个完整的,可维护的解决方案。没有最终产品,解决方案的效率或可维护性无关紧要。如果您花费大量时间来跟踪和修复错误或添加新功能,则解决方案的效率无关紧要。但是,无论任何人说什么,效率和性能无疑都是重要的。
我同意Mike Cellini的观点,我要补充的一件事是。
有足够的效率吗?例如,从用户的角度来看,即使一个功能比另一个效率高得多,在0.00001秒内完成的功能与在0.1秒内完成的功能之间也没有太大差异。在10分钟内完成的功能(对于用户)与在12分钟内完成的功能没有太大不同。在这两种情况下,用户都会喝杯咖啡或继续进行其他任务。
我已经将效率视为“有效用户”,而不是有效算法。
通常,问题的最重要解决方案将是实际存在的解决方案,对于因您的问题而存在的情况有效。换句话说,请避免过早优化,直到您真正知道自己的代码效率低下或需要更快的高效代码。
另外,请不要忘记针对您的应用程序的最佳解决方案可能不是一般情况下的解决方案。案例和观点,几年前,一位教授给我们班上的一个问题,就是我们要打印给定类型的前10个数字(对不起,我记不清该类型,但这是比较少见的数字之一类),我们接受了一项测试,以确保该数字是给定的类型。这就是我们所遇到问题的严重程度,并且被告知该问题将在第二天到期,最有效的解决方案将获得满分。教授在以下演讲中总结了结果:
教授认为最终解决方案最有效。事实证明,该问题实际上是在充分理解问题的过程中进行的练习,而不仅仅是解决并找到最有效的解决方案。
上面的观点是,要找到有效的解决方案,通常最好花一些时间以确保在开始编写代码或尝试优化代码之前真正了解问题所在。如果您可以将一组参考值存储在一个常量数组中,那么从性能的角度来看,最好不要尝试编写一些奇特的算法。
同样,请不要忘记,对于大多数应用程序来说,唯一倾向于看到低效率代码的人(当它不是不必要地低效率时!)就是开发人员自己。如果您编写的纯代码仅能完全完成所需的工作,那么很可能是用户在大多数情况下不会在使用程序时以及在确实优化他们提到的部分时注意到性能问题。您。
这取决于比赛的结构,但总的来说是这样:根据他们的 文档,性能通常是大多数时间的考虑因素。有时,如后面的链接中所述,您必须狩猎,但要引用:
编写干净,清晰,高效的代码。即使没有专门用于此目的的审阅订单项,审阅者仍可能对易于阅读和理解的代码做出更好的反应。借助高效的代码,您可以在压力测试和基准测试中获得潜在的性能优势,并获得审阅者的荣誉(以及一些其他几点)。
改善此问题的最佳方法是编写高效的代码,而您已经在这样做。即使您完成了工作,也要花一些时间提高工作效率-即使在比赛之后-也会有所收获。
您可能还希望在理论上进行投资,例如有关算法的书籍,它可以给您带来两件事:用于解决特定问题的更有效的工具,以及用于识别您要解决的问题的更有效的机制。
解决方案所需的效率取决于许多因素。最大的事情就是知道您的用户想要什么。这里有几个例子。
如何提高代码效率:
有一个完整的领域需要优化,但是以上两个技巧至少应该使您入门。
对于竞赛,您需要了解谁是法官以及法官的身份-如果他们正在寻找优秀的编码人员,仅此而已,那么您将获得更有效的编码的荣誉。
通常,在现实世界中,这并不重要。软件开发的主要思想之一是“不要优化您不知道的需要优化的东西”,然后是“仅在证明需要时才进行优化”。
许多从业人员会辩称,这会导致膨胀肿,效率低下的代码,无法轻易修复,在某些情况下(他们会大声疾呼,就像大多数编码员每天都在做的那样),它们是正确的。但是,没有多少软件开发项目可以衡量结果“性能:比需要的速度更快,成本:谁在乎,交货时间:这十年的某个时候”,在现实世界中,通常是“我想要便宜,昨天想要,我想要它可以正常工作”。