ddl保护原理（不要以DRY之名）

名词解释一下，标题是什么意思DRY 是说 Dont' Repeat Yourself，就是看见重复代码就要消除重复比如说我们发现增删改查这四个操作彼此之间是有共同参数的我们只需要定义一次就可以获得四个界面以及完整的前后端行为，下面我们就来聊聊关于ddl保护原理?接下来我们就一起去了解一下吧!

ddl保护原理

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

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

from django.db import modelsclass 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 adminclass 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详解

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

高可用架构

改变互联网的构建方式

,