不要以 DRY 之名,发明低代码 DSL 去残害你的同事

名词解释一下,标题是什么意思。

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, =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 prepopulatedFields={{\"slug\":[\"title\"]}}/>

我们是可以点进 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 为出发点做任何事情。

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

参考阅读

  • 如何编写 C 20 协程(Coroutines)

  • 领域驱动设计(DDD)在爱奇艺打赏业务的实践

  • Redis 日志篇:无畏宕机实现高可用的杀手锏

  • 喜马拉雅自研网关架构演进过程

  • 如何从0到1构建稳定、高性能Redis集群?

  • 流量洪峰中如何设计弹性微服务架构

  • 美团基于Service Mesh的服务治理系统OCTO 2.0详解

技术原创及架构实践文章,欢迎通过公众号菜单「联系我们」进行投稿。

高可用架构

改变互联网的构建方式

相关新闻

联系我们
联系我们
公众号
公众号
在线咨询
分享本页
返回顶部