什么时候“优化代码” ==“构造数据”？

ycombinator最近发表的一篇文章列出了关于优秀程序员原理的评论。

#7.优秀的程序员：我优化代码。更好的程序员：我构造数据。最佳程序员：有什么区别？

承认主观和有争议的概念-有人对这意味着什么有立场吗？是的，但是我以后想根据自己的想法编辑这个问题，以免预先回答这些问题。

在十分之九的情况下，当您很好地构建代码/模型时，优化将变得显而易见。您见过多少次黄蜂的巢，发现它完全不是最理想的，在进行重组时，很多冗余变得非常明显。

设计师知道他实现了完美，而不是什么都没有添加，而是什么都没有带走。 -圣艾修伯里·安托万

一个结构良好的系统本质上将是最少的，并且由于其本质是最少的，因此将对其进行优化，因为与它几乎没有关系到它为实现其目标所做的努力。

编辑：为了阐明其他人从中获得的要点，将语句视为标识代码和数据之间的关系也是完全准确的。因此，这种关系是：如果更改数据的结构，则需要更改代码以遵守更改后的结构。如果您希望优化代码，则可能需要更改数据的结构，以使您的代码能够更优化地处理数据。

就是说，这里有一个完全独立的可能性被避免了，那就是与YCombinator有关系的这个家伙可能是在LISP谐音传统中指代AS数据。在我看来，将其理解为含义很困难，但这是YCombinator，因此我不排除引述只是说LISPers是“最佳程序员”。

我认为作者暗示任何数据重组都会导致代码重组。因此，以优化系统为目标的数据重组也会迫使您也优化代码，从而提示“有什么区别？” 响应。

请注意，“超级优秀的程序员”可能会回答“有什么区别？” 那里还有一些区别：一旦您尝试优化以提高CPU缓存的使用率，就可以保持数据结构的布局相同，但是更改访问它们的顺序可能会产生很大的变化。区别。

考虑一下最明显的例子-“搜索用户数据太慢！”

如果您的用户数据未建立索引或至少未排序，则重组数据将快速提高代码性能。如果数据结构正确，而您只是遍历集合（而不是使用索引或执行类似二进制搜索的操作），那么修改代码将提高代码性能。

程序员是解决问题的人。尽管区分算法和数据结构很有用，但它们通常不能孤立存在。最好的程序员都知道这一点，不要不必要地孤立自己。

我不同意上述说法，至少在没有解释的情况下是不同意的。我看到编码是涉及利用某些数据结构的活动。数据结构通常会影响编码。因此，我认为两者之间是有区别的。

我认为作者应该把最后一部分写成“最佳程序员：我俩都优化”。

有一本很棒的书（至少在出版时就已出版）叫做：Algorithms + Data Structures = Programs。

优化代码有时可以将速度提高两倍，有时甚至可以提高十倍甚至二十倍，但仅此而已。这听起来可能很多，而且如果将程序执行时间的75％用于五行例程（其速度很容易加倍），那么这样的优化就值得进行。另一方面，数据结构的选择可能会影响执行速度许多数量级。运行超优化代码以按键查找存储在RAM中的10,000,000项线性链表中的数据的现代超优化多线程处理器比运行简单编码的嵌套哈希表的处理器慢得多。确实，如果有人正确地布置了数据，即使是1980年代

话虽如此，设计有效的数据结构通常需要比优化代码更复杂的权衡。例如，在许多情况下，允许最有效访问数据的数据结构的更新效率（有时是数量级）比允许快速更新的数据结构低，而允许最快更新的数据结构可能允许最慢的访问。此外，在许多情况下，对于大数据集而言最佳的数据结构对于小数据集而言可能效率相对较低。一个好的程序员应该努力在实现这些竞争因素与实现和维护各种数据结构所需的程序员时间之间取得平衡，并在它们之间取得不错的平衡。

数据结构驱动着很多与性能有关的事情。我认为我们可以用关于理想数据结构的先入为主的思想来长期研究问题，并且在这种思考的背景下，甚至可以创建最优性的证明（通常是归纳法）。例如，如果我们将排序后的列表放入数组中并评估诸如插入元素的成本之类的事情，那么我们可能平均决定，我们每次插入都需要将数组的1/2移位。对于每个二分查找，我们都可以在log n个步骤中找到（或没有）匹配项。

另外，如果我们推迟对数据结构的决策（避免过早优化），然后研究传入的数据以及使用它的上下文，它的大小，发生的延迟以及哪些对用户重要，我们拥有多少内存vs.将与我们已知或可以设计的数据表示形式一起使用。

在诸如排序和搜索之类的领域中，有很多事情要知道。真正优秀的程序员已经为此工作了很长时间。很好地理解这些问题很有用，而且如果您知道比完成本科数据结构类更多的方法，那将是一件很棒的事情。 二叉树可以为插入提供更高的性能，以换取更高的内存使用量。 哈希表提供了更大的改进，但仍然需要更多的内存。基数树和基数排序可以进一步改进。

数据的创造性结构可以帮助重新构造问题，并为新算法打开大门，这些新算法可以加快硬应用程序的执行速度，有时甚至可以完成无法完成的任务。

为了阐明在文章的意思我最好的猜测，我会认为一个心照不宣的潜台词（这似乎在文章中丢失），其任何程序员都应该理解有关优化：

• 只有在程序启动并正确运行后，优化才会出现：
  • 使它正确运行，然后使其快速运行
  • 这个原则是Knuth准则的重点，“过早的优化是万恶之源”
• 如果并且当您确定优化还不成熟时，则必须首先对其进行适当的测量，以确定实际需要优化的内容，然后在优化过程中一次又一次地告诉您您进行优化的尝试会产生什么影响。
  • 如果您的代码在开发中运行，那么分析器就是您的朋友。
  • 如果您的代码在生产中运行，则必须对代码进行检测，并与日志记录系统成为朋友。

那么，现在：您的测量结果将告诉您机器在代码中哪个位置燃烧了最多的周期。一个“优秀”的程序员将专注于优化代码的那些部分，而不是浪费时间来优化不相关的部分。

但是，您通常可以从整体上看系统，并找到某种方法使机器减少工作量，从而获得更大的收益。通常，这些更改需要重新整理数据的组织；因此，“更好”的程序员会发现自己经常在构造数据。

“最佳程序员”将具有关于机器如何工作的透彻的思维模型，算法设计的良好基础以及对它们如何交互的实际理解。这使他可以将系统视为一个集成的整体-他将看不到优化代码和数据之间的区别，因为他在体系结构级别对其进行了评估。

最佳程序员：有什么区别？

最好的程序员？不，糟糕的程序员。我假设“优化”一词意味着程序员通常尝试优化的那些事情，内存或CPU时间。从这个意义上讲，优化几乎与其他所有软件指标背道而驰。可理解性，可维护性，可测试性等：当以优化为目标时，所有这些都会花费很短的时间-除非人们试图优化的是人类的可理解性，可维护性，可测试性等。更不用说成本了。就开发时间而言，编写速度/空间最佳算法的成本要比仅对某些文本或日记中的算法进行天真的编码要高得多。一个糟糕的程序员不知道区别。一个好人。最好的程序员知道如何准确确定需要优化的内容，并明智地这样做。