业务可读 DSL

DSL 是否能让业务人员无需程序员参与就能编写软件规则？

当人们谈论 DSL 时，通常会提出业务人员自己编写代码的问题。我喜欢将 COBOL 推论应用于这种思路。也就是说，COBOL 的最初目标之一是让人们无需程序员就能编写软件，而我们知道结果如何。因此，每当有人提出无需程序员就能编写代码的方案时，我都会问，这次有什么特别之处，能让它在 COBOL（以及其他许多方案）失败的地方取得成功。

我确实认为编程需要一种特殊的思维方式，既要能够给机器下达精确的指令，又要能够构建大量的指令来编写可理解的程序。这种才能，以及理解和构建程序所需的时间，正是编程长期以来一直难以被取代的原因。这也是为什么许多“非编程”环境最终都会孕育出自己的“事实上的程序员”阶层。

话虽如此，但我确实认为 DSL 最大的潜在好处在于，当业务人员直接参与 DSL 代码的编写时。然而，最佳的切入点是使 DSL 具有业务_可读性_，而不是业务_可写性_。如果业务人员能够查看 DSL 代码并理解其含义，那么我们就可以在软件开发和底层领域之间建立一个深入而丰富的沟通渠道。由于这是软件开发中的“末日深渊”，如果 DSL 能够帮助解决这个问题，那么它们将具有巨大的价值。

使用业务可读的 DSL，程序员编写代码，但他们会经常向能够理解其含义的业务人员展示代码。然后，这些客户可以进行更改，甚至起草一些代码，但最终是由程序员来使其稳固并进行调试和测试。

这并不是说业务可写的 DSL 没有好处。事实上，几年前，我的一些同事构建了一个包含这种 DSL 的系统，并且受到了业务部门的 greatly appreciated。只是创建良好的编辑环境、有意义的错误消息、调试和测试工具的努力会大大增加成本。

虽然我很快就会用 COBOL 的推论来否定许多试图避开程序员的工具，但我也不得不承认一个很大的例外：电子表格。在世界各地，数量惊人的大型业务功能都是在 Excel 的基础上运行的。严肃的程序员往往对这些不屑一顾，但我们需要更加认真地对待它们，并试图理解它们为何会如此成功。这当然是促使许多语言工作台开发者提供不同软件开发愿景的部分原因。