以下是Linus Torvalds 2006年的报价 ：

我大力支持围绕数据开发代码，反之亦然，我认为这是git相当成功的原因之一……实际上，我认为，一个糟糕的程序员与一个好的程序员之间的区别在于，他是否认为更多重要的是您的代码或数据结构。 糟糕的程序员会担心代码。 好的程序员会担心数据结构及其关系。

与2003年埃里克·雷蒙德（Eric Raymond）的“提交规则”非常相似：

将知识变成数据，使程序逻辑变得愚蠢可靠。

这只是罗伯·派克（Rob Pike）1989年的思想之类的思想总结：

数据占主导。 如果选择正确的数据结构并妥善组织所有内容，则算法几乎总是不言而喻的。 数据结构而非算法在编程中起着核心作用。

他引用了1975年的弗雷德·布鲁克斯（Fred Brooks）的话 ：

演示是编程的本质

精通的背后是创造力
经济快捷的程序。 这几乎总是结果。
战略突破，不是战术技能。 有时如此战略
一个突破是算法，例如快速傅立叶变换，
由Cooley和Tukey提出，或者在排序时用n log n代替n²比较。

演讲的结果往往是战略突破
数据或表格。 该程序的核心在这里。 仅显示流程图而不显示表格，我将继续迷路。 告诉我你的
表格和流程图很可能不需要：它们将很明显。

因此，在近半个世纪的时间里，聪明人一遍又一遍地说：首先关注数据。 但是有时似乎这是每个人都忘记的最明智的建议。

我将给出一些真实的例子。

高度可扩展的系统发生故障

该系统最初是在对CPU负载很大的情况下具有令人难以置信的可扩展性的期望下创建的。 没有同步。 到处都有回调，队列和工作池。

但是有两个问题。 首先是“处理器负载”不是那么紧张-一个任务最多花费了几毫秒。 因此，大多数架构弊大于利。 第二个问题是“高度可扩展的分布式系统”实际上仅在一台机器上工作。 怎么了 因为异步组件之间的所有通信都是使用本地文件系统中的文件执行的，所以现在已成为任何扩展的瓶颈。 原始设计完全不依赖于数据，只是以“简单性”的名义保护本地文件。 该项目的主要部分致力于所有这些额外的体系结构，这显然是应对CPU上的“沉重负担”所必需的。

仍然面向数据的面向服务的体系结构

该系统遵循具有REST API的单用途应用程序的微服务设计。 组件之一是一个数据库，用于存储文档（主要是对标准表格和其他电子文档的答复）。 自然，她设置了用于保存和检索数据的API，但是很快就需要更复杂的搜索功能。 开发人员认为，将此功能添加到现有的API文档中会违反微服务设计的原理。 由于“搜索”与“获取/放置”本质上不同，因此架构不应将它们组合在一起。 此外，他们计划使用第三方工具来处理索引，因此出于这个原因，创建新服务“搜索”也很有意义。

结果，创建了一个搜索API和搜索索引，它们实际上成为了主数据库中数据的副本。 此数据是动态更新的，因此任何通过主数据库API更改了文档数据的组件也应发送请求，以通过搜索API更新索引。 使用REST API，如果没有竞争条件就无法完成此操作，因此这两个数据集有时会不同步。

尽管该体系结构承诺了什么，但两个API通过它们的数据依赖关系紧密相关。 后来，开发人员意识到搜索索引应该与通用文档服务结合在一起，这使得系统更易于维护。 “做一件事”在数据级别有效，但在动词级别无效。

出色地模块化和可配置的泥块

该系统是一种自动部署管道。 最初的开发团队希望使工具足够灵活，以解决整个公司的部署问题。 他们编写了一组带有配置文件系统的插件组件，这些文件不仅配置了组件，而且还充当了领域专用语言 （DSL），用于对组件如何适应管道进行编程。

快进了几年，该工具变成了“非常程序”。 有一堆已知错误，没人能解决。 没有人愿意触摸代码，因为担心会破坏某些内容。 没有人使用过DSL的灵活性。 所有用户都复制并粘贴了与其他所有人相同的保证的工作配置。

怎么了？ 尽管原始项目文档经常使用诸如“模块化”，“断开连接”，“可扩展”和“自定义”之类的词，但他对数据一无所知。 因此，使用全局通用的JSON Blob以不受管制的方式处理了组件之间的数据依赖关系。 随着时间的流逝，这些组件对JSON blob中包含或不包含的内容的假设越来越多。 当然，DSL允许以任何顺序重新排列组件，但是大多数配置均无效。

上课

我之所以选择这三个项目，是因为可以轻松地用它们的示例来解释一般性论文，而无需涉及其他项目。 一旦我尝试创建一个网站，而是挂在某种甚至无法解决我的数据问题的可使用的XML数据库上。 还有另一个项目变成了make一半功能的破碎外观，同样是因为我没有想到我真正需要的东西。 我已经写过关于创建一个本应在数据中进行编码的无穷尽的OOP类层次结构所花费的时间。

更新：

显然，许多人仍然认为我在试图取笑某人。 我的真正同事知道，我对解决实际问题更感兴趣，而不是指责产生这些问题的人，但是，好吧，这就是我对参与这些项目的开发人员的看法。

坦率地说，第一种情况很明显是因为系统架构师对应用科学工作比对解决实际问题更感兴趣。 我们中的许多人都可以为此受到指责（我也是），但这确实使我们的同事烦恼。 毕竟，当我们厌倦了玩具时，他们将不得不提供支持。 如果您认识到自己，不要生气，请停下来（尽管我更喜欢在一个节点上使用分布式系统，而不是在我的“ XML数据库”上使用任何系统）。

在第二个示例中，没有什么私人的。 有时似乎周围的人都说共享服务真是太好了，但是没有人谈论什么时候最好不要这样做。 人们一直在从自己的痛苦经历中学习。

第三个故事实际上发生在与我合作过的最聪明的人身上。

（更新结束）。

问题“关于数据造成的问题怎么说？” 事实证明，这对于良好的系统设计是一个非常有用的测试。 识别错误的“专家”和他们的建议也非常方便。 复杂，复杂的系统的体系结构问题就是数据问题，因此错误的专家喜欢忽略它们。 他们将为您展示令人惊讶的美丽架构，但不会说什么数据适合，以及（重要的）数据不适合。

例如，一个错误的专家可能会说您应该使用pub / sub系统，因为pub / sub系统是松散耦合的，松散耦合的组件更易于维护。 它听起来很漂亮，并给出了漂亮的图表，但这与思考相反。 Pub / sub不会使您的组件松耦合； pub / sub 本身是松散耦合的，这可能适合也可能不适合您的数据需求。

另一方面，设计良好的面向数据的体系结构非常重要。 函数式编程，服务网格，RPC，设计模式，事件循环等等，每个人都有自己的优点。 但是我个人看到，在无聊的旧DBMS上可以使用更多成功的生产系统。