停止那个DSL！小小书 XXshu

是的，把它放在那里 。

但是，这是来自Ruby爱好者的奇怪说法。那怎么会

在某个时候，Ruby社区的一部分决定我们需要DSL来完成所有工作。我可能会专注于提高Ruby的速度或垃圾收集，而不是DSL，但毕竟我只是该语言的狂热用户，而不是整个社区的狂热用户。

公平地说，在Ruby中（尤其是在Rails中）构建或使用DSL真的很容易。逻辑上，许多开发人员在他们的项目中使用其中的一些。我一直对同一件事感到内,，所以不用担心。

但是在学习了4241种新的半语言的最初冲击之后（“ 如何在这里再次转换为机器可读的数字？ ”和“ 哇，我不能在这里访问哈希的内部值 ”），我开始怀疑是否所有这些DSL实际上有用。

因此，我拥有这种图灵完整的编程语言，因此可以切换到这种受限语言。我必须学习。虽然我有一种已经可以做到的语言。我所有的开发人员都知道。

在inventid，我们首先针对测试套件开发API。结果，我们为用户（以及PDF和电子邮件）生成了大量的JSON数据，例如非常自己的前端。既然有一个库，我们曾经使用jbuilder为我们生成这个json。

不要被愚弄了，您需要手动编写jbuilder文件，这些文件将挂接到您的控制器中，以根据在方法中定义的实例变量生成输出。因此，可以说不是真正的免费午餐。

过了一会儿不处理json响应（我为我们的付款网关进行了开发），我突然不得不解决一些小问题。具有讽刺意味的是，我发现（突然之间）jbuilder语法非常烦人。

我没有一个真正有趣的一天。

除此之外，我意识到了解DSL的作用很小。您作为开发人员的工作是（按此顺序）：

因此，总而言之，知道DSL不是一项技能，而是您可能偶尔需要的一些东西。

让我向您介绍Ruby开发人员，这是Ruby开发人员。这是一种图灵完整的，对开发人员友好的，非常快速的（#justKidding）编程语言。它非常有能力处理数据转换。因此，您应该真正检查Ruby！

听起来有些la 脚，但最好的工具可能只是您手中的工具 。如果该工具足够，那么您此时可能不需要更专业的工具（谁没有使用电压测试仪作为螺丝刀？！）。例如，jbuilder是您不需要的工具！

inventid经常使用jbuilder。我们（我）觉得很烦。

因此，我们（I）决定使用简单的Ruby代码运行测试。我们真的需要它们吗？还是我们可以简单地使用实际的Ruby和Rails代码创建JSON响应？

实际测试很简单。以我尝试的慢速端点为例，将其实现从jbuilder切换到Ruby。怎么样？使用基本的变压器！

让我向您展示必须修改的代码。首先，我对控制器做了一些小的更改：

其次，我添加了几行Ruby：

最后，我放弃了一些jbuilder代码。

因此，要进行评估，不需要进行太多的代码更改（请注意，由于这是一个后代模型，因此我不得不添加很多转换器）。奇怪的是，这几分钟的测试产生了一些惊人的结果：

作为测试的一部分，此代码已交付生产，以检查性能改进是否也在其中体现出来。

我不想告诉你结论。让我为您显示图形，该图形显示指定端点的视图性能！我很确定您可以确定何时进行生产部署。

这就提出了一个问题：我们是否应该继续使用这种依赖关系？在办公室内进行的快速检查显示，没有人特别喜欢jbuilder语法。没有人对它的速度印象深刻。没有人承认他们认为这使他们能够更快地发展。

因此，在几天之内，我们开始将许多jbuilder代码迁移到纯Ruby。此外，我们还迁移了可以修改为同一文件的属性。

总而言之，这种迁移成功了！它使我们的API响应时间减少了70％以上。绝对值得在一个星期上花费🙂其他人也报告了类似的改进。

为什么我们在简单的变压器上选择这些DSL？这实际上值得慢一点的代码，并学习另一种语言来简单地操纵吗？

老实说，我觉得社区可能会经常选择使用普通语言的DSL。通常，没有充分的理由。

随着时间的流逝，inventid也遭受了多个图书馆的废弃。我们使用squeel使我们的AR语法更好。然后，我们遇到了一个错误（未修复）。最后图书馆被废弃了。

总而言之，选择任何库（或DSL）都会带来未来的可维护性风险。这些库可能会出问题，而您将被这些库困住或承担巨大的重构成本。每个人也必须学习每一个DSL。甚至可能知道并认识到陷阱。

可能是，但一定要先检查通俗易懂的语言！没有DSL是可以拯救您的万灵药。如有疑问，请不要去那里。坦白，无聊并最终保持稳定。