名詞解釋一下，標(biāo)題是什么意思。

DRY 是說(shuō) Dont\’ Repeat Yourself，就是看見(jiàn)重復(fù)代碼就要消除重復(fù)。比如說(shuō)我們發(fā)現(xiàn)增刪改查這四個(gè)操作彼此之間是有共同參數(shù)的。我們只需要定義一次就可以獲得四個(gè)界面以及完整的前后端行為

from django.db import models

class AuthorAdmin(admin.ModelAdmin):
exclude = (\'birth_date\',)

這樣的東西，有的時(shí)候被稱作低代碼，有的時(shí)候被稱作 DSL。用過(guò) django 的同學(xué)都知道上面的代碼就是 Django Admin。這些工具的特點(diǎn)就是可以用 1% 的時(shí)間完成 80% 的功能，剛開(kāi)始用的時(shí)候都直呼這就是未來(lái)。然而 Neal Ford 發(fā)現(xiàn)了“#last10%rule\”，就是最后的 10% 會(huì)付出非常大的代價(jià)，而用戶總是需要 100% 的功能。

這是為什么？難道無(wú)腦復(fù)制粘貼代碼，一個(gè)文件寫1000行才是優(yōu)秀程序員的特質(zhì)嗎？我們有理想有追求，難道是錯(cuò)嗎？

理想沒(méi)有錯(cuò)，方式方法錯(cuò)了。

不要誤會(huì)我，我不是站在你們的對(duì)立面。本人絕對(duì)是鐵桿的語(yǔ)法糖制匠。只是有的時(shí)候，人們需要跳出原有的思維習(xí)慣，才能意識(shí)到認(rèn)知的盲點(diǎn)。

誤區(qū)一：一廂情愿的抽象

在 代碼寫得不好，不要總覺(jué)得是自己抽象得不好 中我已經(jīng)說(shuō)過(guò)了。業(yè)務(wù)邏輯，界面長(zhǎng)相，絕大多數(shù)時(shí)候都是產(chǎn)品經(jīng)理說(shuō)了算。不恰當(dāng)?shù)恼f(shuō)，你們程序員不過(guò)是產(chǎn)品經(jīng)理手里的筆。這雖然讓人難以接受，但的確是大部分人的真實(shí)日常。

當(dāng)我們看到兩個(gè)地方差不多的時(shí)候。不要一廂情愿的抽取公共代碼，消除重復(fù)。首先要和產(chǎn)品經(jīng)理達(dá)成一致，這個(gè)在業(yè)務(wù)上就應(yīng)該是保持一致的。當(dāng)一個(gè)產(chǎn)品有一群產(chǎn)品經(jīng)理的時(shí)候，他們或者她們經(jīng)常因?yàn)楸舜瞬焕R想法，同樣的列表篩選功能可能會(huì)搞出五花八門的做法來(lái)。這個(gè)時(shí)候就需要用 UI 設(shè)計(jì)師等角色去橫向拉齊。

總之先要把需求的源頭給按住了。而不是在需求的下游，用可復(fù)用抽象代碼來(lái)兜底。這也是《領(lǐng)域驅(qū)動(dòng)開(kāi)發(fā)》要求客戶，產(chǎn)品經(jīng)理，程序員能夠更多的交流，更多的形成共識(shí)的原因。

誤區(qū)二：在調(diào)用棧上找不到自己的代碼

很多人會(huì)把 Django Admin 這樣的 CRUD 代碼生成，歸咎為代碼是生成的。但其實(shí)問(wèn)題并不是出在代碼是生成的，問(wèn)題出現(xiàn)在“調(diào)用棧上找不到自己的代碼”：當(dāng)我們看到拋出一個(gè)異常，然后在 stack trace 里一行行找，找不到自己寫的代碼。為什么會(huì)出現(xiàn)這樣的現(xiàn)象？

假設(shè)起初我們寫了三個(gè)方法

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);
}


我們可以看到需要用戶寫三個(gè)方法，f1/f2/f3 這就是代碼量。而且每個(gè)地方都要重復(fù)傳 arg1 這個(gè)參數(shù)。那么我們應(yīng)該用 DRY 的名義，把代碼簡(jiǎn)化為

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);
}


這里我們抽取了一個(gè)公共的全局的 theModel 來(lái)定義所有的參數(shù)。然后 f1, f2, f3 的行為都是模型驅(qū)動(dòng)的。那么似乎，用戶也不需要寫什么 f1/f2/f3，他們寫這個(gè)就好了：

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


這樣不但代碼量很小，而且和具體的實(shí)現(xiàn)還“解耦”了。將來(lái)技術(shù)要升級(jí)了，也只需要升級(jí)框架就好了，業(yè)務(wù)邏輯是不需要?jiǎng)拥摹＿@種“讓用戶在調(diào)用棧上找不到自己的代碼”，弊端在哪里？

很容易找不到一個(gè)配置項(xiàng)，一個(gè)參數(shù)，產(chǎn)生影響的位置。可能是在框架代碼的任何地方。寫代碼的地方，和實(shí)際產(chǎn)生行為的地方，之間沒(méi)有編譯期可以跟蹤的符號(hào)依賴關(guān)系了。當(dāng)然這是所有 mutable data 的問(wèn)題，所有寫入的地方，都不知道會(huì)在哪里讀取，會(huì)對(duì)讀取的地方產(chǎn)生什么影響。程序員的日常就是搞這些幺蛾子的，當(dāng)然處理這樣的問(wèn)題是駕輕就熟。但并不意味著是沒(méi)有成本的。這樣的間接性越多，代碼就越難以閱讀。

這里還有第二個(gè)問(wèn)題就是 theModel 包含了 f1, f2, f3 的參數(shù)的集合。當(dāng)把所有參數(shù)都打平了混一起之后，雖然可以使得 arg1 這樣的重復(fù)參數(shù)被消除，但也使得哪個(gè)參數(shù)是給誰(shuí)用的更模糊了。比如

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

當(dāng)我們讀到了上面的定義的時(shí)候，prepopulated_fields 影響了增刪改查的哪個(gè)界面上的哪幾個(gè)字段，是如何影響的？

有的同學(xué)可能會(huì)說(shuō) Antd 的組件參數(shù)也有幾十個(gè)那。但是當(dāng)我們看到這樣的 React 組件的調(diào)用代碼的時(shí)候

return <EditorForm prepopulatedFields={{\"slug\":[\"title\"]}}/>


我們是可以點(diǎn)進(jìn) EditorForm 的代碼里去看 EditorForm 的實(shí)現(xiàn)的?？梢哉夷睦镉昧?prepopulatedFields 這個(gè)傳入的參數(shù)了。但是把代碼寫成 Django Admin 這樣的聲明式的時(shí)候，你是無(wú)法輕易找到哪里讀了 prepopulated_fields 的。最大的可能是開(kāi)始做全局文本搜索框架的代碼。

DSL 作者們是不認(rèn)為這是一個(gè)問(wèn)題的。每個(gè)參數(shù)都是他們親手添加的，在 DSL 被發(fā)明后的三個(gè)月之內(nèi)，他們是不需要去查文檔的（如果有文檔的話）。但是他們的同事就沒(méi)這么幸運(yùn)了。

誤區(qū)三：在意想不到的地方修改語(yǔ)言的默認(rèn)行為

特別是賦值和取值這兩個(gè)操作。例如下面這樣的代碼

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


請(qǐng)問(wèn) console 上輸出的是什么？應(yīng)該是 hello 對(duì)不對(duì)？

那么，如果傳入的 a 是這樣的呢？

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

const a = {};
Object.defineProperty(a, \'b\', { value: \'world\' });
doSomething(a);


這個(gè)時(shí)候 console 上輸出的是 world 而不是 hello。

C 的拷貝構(gòu)造函數(shù)，隱式轉(zhuǎn)換構(gòu)造函數(shù)。也是類似的問(wèn)題。在賦值的語(yǔ)法里偷偷塞了行為進(jìn)去。

也就是框架代碼，DSL的實(shí)現(xiàn)，他們是可以通過(guò)魔法來(lái)修改賦值操作和取值操作的。大部分程序員都很難意識(shí)到，一行平凡的代碼，可以發(fā)生很不平凡的事情。這就會(huì)導(dǎo)致出問(wèn)題的時(shí)候，真正產(chǎn)生問(wèn)題的地方被略過(guò)，因?yàn)槟莻€(gè)地方可能不過(guò)就是一行取值操作，或者一行賦值操作。

好好寫代碼，而不是玩弄技巧

要復(fù)用之前，先和產(chǎn)品經(jīng)理或者客戶達(dá)成共識(shí)。

別想著省那么多的代碼。該有一個(gè)界面的時(shí)候，就要定義一個(gè)界面。該有一個(gè)后端 API 的時(shí)候，就要定義一個(gè) API。哪怕只有一行代碼呢。讓用戶去 call library，而不是定義個(gè) framework，要求用戶給一堆 config。

不要修改賦值和取值的行為，不要制造驚喜。

不要以 DRY 之名做任何事情?？赡軓钠渌麆?dòng)機(jī)，造成的結(jié)果是要 DRY。但不要以 DRY 為出發(fā)點(diǎn)做任何事情。

謹(jǐn)以此文批判自己過(guò)去犯的一些錯(cuò)誤，引以為戒。

參考閱讀

• 如何編寫 C 20 協(xié)程(Coroutines)

• 領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)(DDD)在愛(ài)奇藝打賞業(yè)務(wù)的實(shí)踐

• Redis 日志篇：無(wú)畏宕機(jī)實(shí)現(xiàn)高可用的殺手锏

• 喜馬拉雅自研網(wǎng)關(guān)架構(gòu)演進(jìn)過(guò)程

• 如何從0到1構(gòu)建穩(wěn)定、高性能Redis集群？

• 流量洪峰中如何設(shè)計(jì)彈性微服務(wù)架構(gòu)

• 美團(tuán)基于Service Mesh的服務(wù)治理系統(tǒng)OCTO 2.0詳解

技術(shù)原創(chuàng)及架構(gòu)實(shí)踐文章，歡迎通過(guò)公眾號(hào)菜單「聯(lián)系我們」進(jìn)行投稿。

高可用架構(gòu)

改變互聯(lián)網(wǎng)的構(gòu)建方式