如何在为未知情况设计时避免优化的危险？

Question

两位伙伴：

1)假设您正在设计一种新型应用程序，并且正在提出新的算法来表达概念和内容-尝试在那个阶段不考虑优化技术是否有意义，即使在你的脑海中你担心它最终会变成O(N!)上百万的元素？

2)如果是这样的话，如果是这样的话，为了避免限制您的可能会在概念验证运行后能够优化的酷功能--您如何阻止自己摆脱这种一生中的程序员习惯？我一直在尝试脑力练习，纸笔记，但我长大了，基本上计数时钟周期的汇编程序，我不断发现自己否决了潜在的解决方案太浪费，然后才充分考虑功能的价值。

编辑：--这是关于设计的--以前还没有做过的事情(未知的)，当你甚至不确定理论上是否可以做到的时候，更不用说有无限的计算能力了。因此，按照“当然，在您有一个原型之前，您必须进行优化，因为是一个既定的计算原则”的回答并不特别有用。

Answer 1

我这么说并不是因为我认为你还不知道，而是要在压制内心批判的同时提供精神上的支持：)

关键是保持理智。

如果你发现自己在写一个Theta(N!)算法，这是预期的规模，然后你疯了。你必须扔掉它，所以你最好现在就开始寻找一个更好的算法，你可以实际使用。

如果您发现自己担心的是，每个用户按下一次精确执行的奔腾代码是否会占用10个周期或10K周期，那么您就疯了。CPU为95%空闲。给它一万次小小的循环。如果必须的话，请举起一张增强票据，但是要慢慢地离开汇编程序。

一旦要决定项目是“编写一个研究原型，然后将其进化成一个真正的产品”，还是“编写一个研究原型”。很明显，如果研究成功，还会有另一个相关的项目。

在后一种情况下(从注释中听起来很像您所拥有的)，您可以编写一些只适用于N<=7的东西，甚至还会导致从这里到辛辛那提的浏览器。但你还是不确定你能做什么。一旦你对问题有了感觉，你就会对性能问题有更好的了解。

你现在所做的，是在浪费时间(基于你的研究证明不相关的考虑因素)和后来的浪费时间之间取得平衡(因为你现在没有考虑到一些事实证明是重要的事情)。你的研究风险越大，你就越应该为做某事而感到高兴，并为你以后所做的事情感到担忧。

Answer 2

我最大的答案是测试驱动开发。通过预先编写所有的测试，您就会强迫自己只编写足够的代码来实现您想要的行为。如果定时和时钟周期成为一个要求，那么您可以编写测试来覆盖该场景，然后重构您的代码以满足这些需求。

Answer 3

优化并不完全是一种危险；在编写代码时考虑速度在某种程度上是好的，因为它阻止您在更简单、更快的解决方案中实现缓慢和混乱的解决方案。它也会让你在脑海中检查某件事是否可行。

可能发生的最糟糕的事情是，您设计一个大型程序时显式地忽略了优化，结果却发现您的整个设计是完全无用的，因为如果不完全重写它，就无法对其进行优化。如果你在写它的时候考虑了所有的事情，这种情况就不会发生--“一切”的一部分是潜在的性能问题。

“过早优化是万恶之源”是万恶之源。我见过一些项目因过度使用这个概念而瘫痪。在我的公司，我们有一个软件程序，可以在网络上广播来自磁盘的传输流。它最初是为测试目的而创建的(因此我们一次只需要几个流)，但它总是在程序的规范要求中为更多的流工作，以便以后可以按需使用视频。

因为它是完全忽略速度的，所以它是一团糟；它有大量的内存，尽管它们根本不应该是必需的，它的TS处理代码非常慢(实际上它多次解析了每个TS数据包)，等等。它一次只处理了40条溪流，而不是原来应该处理的数千条。当它真正用于视频点播的时候，我们不得不回去花大量的时间来清理和重写它的大部分内容。