名词解释一下，标题是什么意思。
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 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 为出发点做任何事情。
谨以此文批判自己过去犯的一些错误，引以为戒。
