为什么不要以DRY之名发明低代码DSL

这篇文章主要讲解了“为什么不要以DRY之名发明低代码DSL”,文中的讲解内容简单清晰,易于学习与理解,下面请大家跟着小编的思路慢慢深入,一起来研究和学习“为什么不要以DRY之名发明低代码DSL”吧!

点军ssl适用于网站、小程序/APP、API接口等需要进行数据传输应用场景,ssl证书未来市场广阔!成为创新互联的ssl证书销售渠道,可以享受市场价格4-6折优惠!如果有意向欢迎电话联系或者加微信:028-86922220(备注:SSL证书合作)期待与您的合作!

DRY 是说 Dont' Repeat Yourself,就是看见重复代码就要消除重复。比如说我们发现增删改查这四个操作彼此之间是有共同参数的。我们只需要定义一次就可以获得四个界面以及完整的前后端行为

from django.db import models  class Author(models.Model):     name = models.CharField(max_length=100)     title = models.CharField(max_length=3)     birth_date = models.DateField(blank=True, null=True)  from django.contrib import admin  class AuthorAdmin(admin.ModelAdmin):     exclude = ('birth_date',)

这样的东西,有的时候被称作低代码,有的时候被称作 DSL。用过 django 的同学都知道上面的代码就是Django Admin。这些工具的特点就是可以用 1% 的时间完成 80% 的功能,刚开始用的时候都直呼这就是未来。然而 Neal Ford 发现了“#last10%rule",就是最后的 10% 会付出非常大的代价,而用户总是需要 100% 的功能。

这是为什么?难道无脑复制粘贴代码,一个文件写1000行才是优秀程序员的特质吗?我们有理想有追求,难道是错吗?

理想没有错, 方式方法 错了。

不要误会我,我不是站在你们的对立面。本人绝对是铁杆的语法糖制匠。只是有的时候,人们需要跳出原有的思维习惯,才能意识到认知的盲点。

误区一:一厢情愿的抽象

在 《代码写得不好,不要总觉得是自己抽象得不好》 中我已经说过了。业务逻辑,界面长相,绝大多数时候都是产品经理说了算。不恰当的说,你们程序员不过是产品经理手里的笔。这虽然让人难以接受,但的确是大部分人的真实日常。

当我们看到两个地方差不多的时候。不要一厢情愿的抽取公共代码,消除重复。首先要和产品经理达成一致,这个在业务上就应该是保持一致的。当一个产品有一群产品经理的时候,他们或者她们经常因为彼此不拉齐想法,同样的列表筛选功能可能会搞出五花八门的做法来。这个时候就需要用 UI 设计师等角色去横向拉齐。

总之先要把需求的源头给按住了。而不是在需求的下游,用可复用抽象代码来兜底。这也是《领域驱动开发》要求客户,产品经理,程序员能够更多的交流,更多的形成共识的原因。

误区二:在调用栈上找不到自己的代码

很多人会把 Django Admin 这样的 CRUD 代码生成,归咎为代码是生成的。但其实问题并不是出在代码是生成的,问题出现在“调用栈上找不到自己的代码”:当我们看到抛出一个异常,然后在 stack trace 里一行行找,找不到自己写的代码。为什么会出现这样的现象?

假设起初我们写了三个方法

import { f1_impl, f2_impl, f3_impl } from 'some-lib'; function f1() {   f1_impl(arg1, arg2); } function f2() {   f2_impl(arg1, arg3); } function f3() {   f3_impl(arg1, arg4); }

我们可以看到需要用户写三个方法,f1/f2/f3 这就是代码量。而且每个地方都要重复传 arg1 这个参数。那么我们应该用 DRY 的名义,把代码简化为

import { f1_impl, f2_impl, f3_impl } from 'some-lib'; const theModel = { arg1, arg2, arg3, arg4 } function f1() {   f1_impl(theModel.arg1, theModel.arg2); } function f2() {   f2_impl(theModel.arg1, theModel.arg3); } function f3() {   f3_impl(theModel.arg1, theModel.arg4); }

这里我们抽取了一个公共的全局的 theModel 来定义所有的参数。然后 f1, f2, f3 的行为都是模型驱动的。那么似乎,用户也不需要写什么 f1/f2/f3,他们写这个就好了:

export const theModel = { arg1, arg2, arg3, arg4 }

这样不但代码量很小,而且和具体的实现还“解耦”了。将来技术要升级了,也只需要升级框架就好了,业务逻辑是不需要动的。这种“让用户在调用栈上找不到自己的代码”,弊端在哪里?

很容易找不到一个配置项,一个参数,产生影响的位置。可能是在框架代码的任何地方。写代码的地方,和实际产生行为的地方,之间没有编译期可以跟踪的符号依赖关系了。当然这是所有 mutable data 的问题,所有写入的地方,都不知道会在哪里读取,会对读取的地方产生什么影响。程序员的日常就是搞这些幺蛾子的,当然处理这样的问题是驾轻就熟。但并不意味着是没有成本的。这样的间接性越多,代码就越难以阅读。

这里还有第二个问题就是 theModel 包含了 f1, f2, f3 的参数的集合。当把所有参数都打平了混一起之后,虽然可以使得 arg1 这样的重复参数被消除,但也使得哪个参数是给谁用的更模糊了。比如

class ArticleAdmin(admin.ModelAdmin):     prepopulated_fields = {"slug": ("title",)}

当我们读到了上面的定义的时候,prepopulated_fields 影响了增删改查的哪个界面上的哪几个字段,是如何影响的?

有的同学可能会说 Antd 的组件参数也有几十个那。但是当我们看到这样的 React 组件的调用代码的时候

return 

我们是可以点进 EditorForm 的代码里去看 EditorForm 的实现的。可以找哪里用了 prepopulatedFields 这个传入的参数了。但是把代码写成 Django Admin 这样的声明式的时候,你是无法轻易找到哪里读了 prepopulated_fields 的。最大的可能是开始做全局文本搜索框架的代码。

DSL 作者们是不认为这是一个问题的。每个参数都是他们亲手添加的,在 DSL 被发明后的三个月之内,他们是不需要去查文档的(如果有文档的话)。但是他们的同事就没这么幸运了。

误区三:在意想不到的地方修改语言的默认行为

特别是赋值和取值这两个操作。例如下面这样的代码

function doSomething(a) {   a.b = 'hello';   console.log(a.b); }

请问 console 上输出的是什么?应该是 hello 对不对?

那么,如果传入的 a 是这样的呢?

function doSomething(a) {   a.b = 'hello';   console.log(a.b); }  const a = {}; Object.defineProperty(a, 'b', { value: 'world' }); doSomething(a);

这个时候 console 上输出的是 world 而不是 hello。

C++的拷贝构造函数,隐式转换构造函数。也是类似的问题。在赋值的语法里偷偷塞了行为进去。

也就是框架代码,DSL的实现,他们是可以通过魔法来修改赋值操作和取值操作的。大部分程序员都很难意识到,一行平凡的代码,可以发生很不平凡的事情。这就会导致出问题的时候,真正产生问题的地方被略过,因为那个地方可能不过就是一行取值操作,或者一行赋值操作。

好好写代码,而不是玩弄技巧

要复用之前,先和产品经理或者客户达成共识。

别想着省那么多的代码。该有一个界面的时候,就要定义一个界面。该有一个后端 API 的时候,就要定义一个 API。哪怕只有一行代码呢。让用户去 call library,而不是定义个 framework,要求用户给一堆 config。

不要修改赋值和取值的行为,不要制造惊喜。

不要以 DRY 之名做任何事情。可能从其他动机,造成的结果是要 DRY。但不要以 DRY 为出发点做任何事情。

谨以此文批判自己过去犯的一些错误,引以为戒。

感谢各位的阅读,以上就是“为什么不要以DRY之名发明低代码DSL”的内容了,经过本文的学习后,相信大家对为什么不要以DRY之名发明低代码DSL这一问题有了更深刻的体会,具体使用情况还需要大家实践验证。这里是创新互联,小编将为大家推送更多相关知识点的文章,欢迎关注!


分享标题:为什么不要以DRY之名发明低代码DSL
文章分享:http://scyanting.com/article/pcgdop.html