Torvalds关于优秀程序员的报价[关闭]

偶然地，我偶然发现了Linus Torvalds的以下引用：

“糟糕的程序员会担心代码。好的程序员会担心数据结构及其关系。”

最近几天我一直在考虑这个问题，但我仍然感到困惑（这可能不是一个好兆头），因此我想讨论以下内容：

• 对这种可能/合理的解释是什么？
• 从中可以学到什么？

考虑一下Torvalds在那之前所说的话可能会有所帮助：

git实际上具有简单的设计，具有稳定且记录良好的数据结构。实际上，我非常支持围绕数据设计代码，而不是相反地设计代码，并且我认为这是git相当成功的原因之一[...]实际上，我将声称两者之间的差异一个糟糕的程序员和一个好的程序员之间的关系是，他是否认为自己的代码或数据结构更重要。

他的意思是，好的数据结构使代码非常易于设计和维护，而最好的代码无法弥补不良的数据结构。

如果您想了解git示例，许多版本控制系统会相对定期地更改其数据格式，以支持新功能。升级以获得新功能时，通常还必须运行某种工具来转换数据库。

例如，当DVCS首次流行时，很多人都无法弄清楚分布式模型对合并的影响比集中版本控制要干净得多。答案是绝对没有，除非分布式数据结构必须要好得多才能完全有希望工作。我相信集中式合并算法已经赶上了，但是花了很长时间，因为它们的旧数据结构限制了它们可以使用的算法种类，而新的数据结构破坏了很多现有代码。

相比之下，尽管git中的功能大增，但其基础数据结构几乎没有改变。首先担心数据结构，您的代码自然会变得更干净。

算法+数据结构=程序

代码只是表达算法和数据结构的方式。

这句话对“ Unix编程的艺术”中的规则之一非常熟悉，这是Torvalds的强项，他是Linux的创造者。这本书在这里在线

这本书中的以下引文阐述了托瓦尔兹所说的话。

表示法则：将知识整合到数据中，因此程序逻辑可以是愚蠢且健壮的。

即使是最简单的过程逻辑，人类也很难验证，但是相当复杂的数据结构也很容易建模和推理。要看到这一点，请将（例如）五十节点指针树的图与五十行程序的流程图的表现力和解释力进行比较。或者，将表示转换表的数组初始化程序与等效的switch语句进行比较。透明度和清晰度上的差异是巨大的。参见Rob Pike的规则5。

数据比程序逻辑更容易处理。因此，如果您在数据结构的复杂性和代码的复杂性之间做出选择，请选择前者。更多：在进行设计时，您应该积极寻求将复杂性从代码转换为数据的方法。

Unix社区并没有产生这种见解，但是许多Unix代码显示了它的影响力。特别是C语言在处理指针方面的便利性鼓励从内核开始在所有编码级别上使用动态修改的引用结构。这种结构中的简单指针追逐经常会执行职责，而其他语言的实现则必须体现在更复杂的过程中。

代码很简单，这是复杂代码背后的逻辑。

如果您担心代码，这意味着您还没有掌握这些基础知识，并且很可能会迷失在复杂的代码（即数据结构及其关系）上。

为了进一步扩展Morons的答案，我们的想法是理解代码的细节（语法，在较小程度上，结构/布局）非常容易，因此我们构建了可以做到的工具。编译器可以理解所有有关代码的知识，以便将其转变为可运行的程序/库。但是编译器实际上无法解决程序员所遇到的问题。

您可以将参数更进一步，说“但是我们确实有生成代码的程序”，但是它生成的代码是基于几乎总是手动构建的某种输入的。

因此，无论采用哪种途径获取代码：通过某种配置或其他输入，然后通过工具生成代码，或者如果您是从头开始编写的，则无关紧要的代码。至关重要的是对获得该代码所需的所有部分的批判性思考。在Linus的世界中，主要是数据结构和关系，尽管在其他领域可能是其他部分。但是在这种情况下，Linus只是说“我不在乎您是否可以编写代码，我在乎您能够理解可以解决我正在处理的问题的事物”。

Linus的意思是：

向我展示您的流程图[代码]，并隐藏您的表格[模式]，我将继续感到困惑；给我看你的表[模式]，我通常不需要你的流程图[代码]：它们很明显。

-弗雷德·布鲁克斯（Fred Brooks），《神话人月》，第9章。

我认为他是说总体高层设计（数据结构及其关系）比实现细节（代码）重要得多。我认为他重视那些可以设计系统的程序员，而不是那些只关注系统细节的程序员。

两者都很重要，但是我同意，总体上来说，与细节相关的问题要比其他方法要好得多。这与我试图表达的关于将大功能分解为小功能密切相关。

好吧，我不能完全同意，因为您必须担心所有这些。就此而言，我最喜欢编程的一件事就是通过不同级别的抽象和大小进行切换，这些切换从思考纳秒到思考数月迅速跳跃，然后又回来了。

但是，更高的东西更重要。

如果我在几行问题中都存在缺陷，导致行为不正确，则修复起来可能不太困难。如果它导致其表现不佳，那可能甚至没有关系。

如果我在子系统的数据结构选择方面存在缺陷，这会导致错误的行为，那么这将是一个更大的问题，而且更难解决。如果它导致其表现不佳，则可能会很严重，甚至可以忍受，但仍然比竞争对手的方法差很多。

如果我在应用程序中最重要的数据结构之间的关系中存在缺陷，这会导致错误的行为，那么我就要进行大量的重新设计。如果它导致其性能不佳，则可能会很糟糕，以至于如果表现不佳，它将几乎更好。

而且它会是什么让那些寻找较低级别的问题难以（固定低级别的错误通常是容易的，而是找到他们是很难）。

低级的东西很重要，而其剩余的重要性常常被低估了，但是与大的东西相比，它的确显得苍白。

知道代码的人会看到“树”。但是了解数据结构的人会看到“森林”。因此，优秀的程序员将更多地关注数据结构而不是代码。

知道数据将如何流动非常重要。了解流程要求您设计良好的数据结构。

如果回溯二十年，这是使用SmallTalk，C ++或Java的面向对象方法的最大卖点之一。至少在C ++中，因为这是我首先学到的，这是我设计的最大基调，是设计类和方法，然后其他所有东西都放到位。

Linus无疑是在用更广泛的术语进行讨论，但是设计不良的数据结构通常需要额外的代码重做，这也可能导致其他问题。

从中可以学到什么？

如果可以的话，我过去几周的经验。前面的讨论澄清了我的问题的答案：“我学到了什么？”

我重写了一些代码，并反思了我不断看到的结果，并说“结构，结构...”就是为什么存在如此巨大的差异。现在，我看到是数据结构使一切有所不同。我的确是全部。

• 测试我的原始交付后，业务分析师告诉我它不起作用。我们说：“加30日”，但我们的意思（WAS的“添加月份” 一天中生成的日期不会更改）。添加离散的年，月，日；而不是18个月的540天。

• 解决方法：在数据结构中，将一个整数替换为包含多个整数的类，将其构造更改限制为一种方法。更改实际的日期算术语句-全部两个。

回报

• 新的实现具有更多的功能，但是算法代码更短并且明显更简单。

在修复代码行为/结果中：

• 我更改了数据结构，而不是算法。
• 代码中的任何地方都没有触及控制逻辑。
• 没有更改API。
• 数据结构工厂类完全没有改变。

我想想象一个非常聪明的图书馆员团队，在一个精美的图书馆中，拥有一百万本随机且精采的书籍，这真是愚蠢。

我完全不同意莱纳斯。关注数据有助于极大地提炼出针对给定问题的简单而灵活的解决方案。Git本身就是一个证明性的例子-在多年的开发中提供了如此多的功能支持，核心数据结构在很大程度上保持不变。太神奇了！--2分

我已经看到了很多领域。

考虑业务分析...假设您正在分析像高露洁这样的消费品公司支持市场营销的最佳方法。如果您从花哨的窗口或最新技术入手，那么您对企业的帮助就不会比您首先考虑企业的数据需求，然后再考虑展示时所提供的帮助大。数据模型比演示软件更耐用。

考虑做一个网页。最好先考虑要显示的内容（HTML），然后再考虑样式（CSS）和脚本（选择工具），这要好得多。

这并不是说编码也不重要。您需要编程技巧才能最终获得所需的东西。数据是基础。不良的数据模型反映了过于复杂或未考虑的业务模型。

我发现自己编写新功能和更新现有功能的频率要比向我的数据库模式添加新的列或表要多得多。对于所有精心设计的系统，这可能都是正确的。如果您每次需要更改代码时都需要更改架构，那么这显然是一个非常糟糕的开发人员的信号。

代码质量指标= [代码更改] / [数据库架构更改]

“向我展示您的流程图并隐藏您的表，我将继续感到困惑。向我展示您的表，我通常不需要您的流程图；它们将显而易见。” （弗雷德·布鲁克斯）

似乎这个想法在各种类型的编程中都有各种解释。它适用于系统开发，也适用于企业开发。例如，有人可能会争辩说，在域驱动设计中，对领域的关注发生了急剧变化，就像对数据结构和关系的关注一样。

这是我对此的解释：您使用代码创建数据结构，因此重点应放在后者上。这就像建造一座桥梁-您应该着手设计一种坚固的结构，而不是看起来很有吸引力的结构。碰巧的是，由于其高效的设计，编写良好的数据结构和桥看起来都很不错。