我喜欢的那种开发

我明年就要 40 岁了（真可怕！），尽管我已经制作网站超过 25 年了，但我感觉我终于开始了解我喜欢的那种开发。不出所料，这些并不是新的发现，我的观点可以用两个早于我职业生涯的旧的计算机科学格言来概括。

1. 组合优于继承
2. 约定优于配置

请允许我带您踏上一次短途旅行。在现代组件驱动的 Web 开发中，我经常会遇到或看到这样的结构

<ComponentA>
  <ComponentB>
    <ComponentC />
  </ComponentB>
</ComponentA>

走这条路是一个系统，其中所有内容都是嵌套的子组件，并且属性或数据从父组件向下传递。它有效，但对我来说，它消除了编程的乐趣。它感觉更像管道工而不是编程。

看到 Mozilla 的新 ECSY 框架 针对 2D 游戏和 3D 虚拟现实场景，我立即发现自己被其编程模型所吸引，该模型在其中组件将其行为链接到称为实体的对象上。

EntityA
  .addComponent('ComponentA')
  .addComponent('ComponentB')

嘿！看起来像一个链式 jQuery 方法。我喜欢这个，不仅仅是为了怀旧。我喜欢功能的“组合”。我知道 CSS 充满了继承问题，但这让我想起了添加格式良好的 CSS 类。我被它吸引。知道我个人更喜欢组合实际上帮助我解决了一些奇怪的不一致的感觉，即为什么我真正喜欢 React Hooks（组合），即使我不太喜欢更大的 React 生态系统（继承）。

我想我必须承认并为我对 React 的许多 misplaced anger 道歉。作为组件系统，它很棒。我在几个项目中使用过它，但从未真正与它建立联系。我想我感到羞愧，因为我不喜欢这种非常流行的抽象，并且感觉与大众意见不一致。现在我认为我更了解其中的原因。

我应该向 webpack 道歉。作为捆绑和树摇工具，它做得很好。当所有配置都隐藏在 Angular CLI 和 Nuxt 等工具中时，它会更好。我的挫折是真实的，但当我更多地了解自己时，我意识到可能还有其他原因……

我对现代 Web 开发的挫折感在抽象级别上不断下降。我现在思考 npm 并想知道它是否在一定程度上要对当今现代 Web 开发的一些痛点负责。事实上，npm 是一种服务器端技术，我们在客户端上使用它，我认为我们在浏览器中感受到了这些影响。

Unix 哲学鼓励我们编写小的微库，这些库只做一件事并把它做好。Node.js 生态系统在这方面做得很好。这在服务器上效果很好，因为导入一个小文件会产生非常小的成本。然而，在客户端上，这会产生巨大的成本。因此，我们构建流程和工具来将这 46,000 个脚本捆绑在一起。但这会模糊最终产品。一个站点可能同时使用 fetch、axios 和 bluebird，以及 lodash 来编写一个 forEach 循环，这并不罕见。

在“npm install 解决你的问题”的世界里，我觉得我们做的编程越来越少，而从互联网上安装的东西的配置越来越多了。随着依赖项在功能上增长并变得更加灵活，它们允许你配置一些选项标志。作为一次性配置，配置文件是一个很棒的功能。但累积起来，即使在一个“简单”的项目中，我发现自己也会管理和处理大约六个配置文件。有一天，当我沉浸在 JSON 配置的海洋中时，我突然意识到：我不喜欢配置。

“约定优于配置” 是一套由 David Heinemeier Hansson (@DHH) 推广的理念，它指导了 Ruby on Rails 的许多设计。虽然这句话已经不再流行，但我认为它总结了我喜欢的开发类型，尤其是在涉及框架时。框架应该尝试成为最佳实践的集合，以防止其他人过度思考决策。我已经说过，但我认为 我认为 Nuxt 做得很好。当我进入一个预定义约定和少量配置的系统时，我会比相反的系统（没有约定和大量配置）更快乐。

在 40 岁的时候才发现我每天做的工作中有很多事情，这有点奇怪。但很高兴找到了一些词汇和原则来表达我对开发的喜好。你喜欢的清单可能与我的不同，这是一件好事。我很想知道你喜欢的开发类型。你喜欢构建什么？你在优化什么？你对成功的定义是什么？