為什么不要以DRY之名發(fā)明低代碼DSL

這篇文章主要講解了“為什么不要以DRY之名發(fā)明低代碼DSL”，文中的講解內容簡單清晰，易于學習與理解，下面請大家跟著小編的思路慢慢深入，一起來研究和學習“為什么不要以DRY之名發(fā)明低代碼DSL”吧！

點軍ssl適用于網站、小程序/APP、API接口等需要進行數(shù)據傳輸應用場景，ssl證書未來市場廣闊！成為創(chuàng)新互聯(lián)的ssl證書銷售渠道，可以享受市場價格4-6折優(yōu)惠！如果有意向歡迎電話聯(lián)系或者加微信：028-86922220（備注：SSL證書合作）期待與您的合作！

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

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 發(fā)現(xiàn)了“#last10%rule"，就是最后的 10% 會付出非常大的代價，而用戶總是需要 100% 的功能。

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

理想沒有錯， 方式方法 錯了。

不要誤會我，我不是站在你們的對立面。本人絕對是鐵桿的語法糖制匠。只是有的時候，人們需要跳出原有的思維習慣，才能意識到認知的盲點。

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

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

當我們看到兩個地方差不多的時候。不要一廂情愿的抽取公共代碼，消除重復。首先要和產品經理達成一致，這個在業(yè)務上就應該是保持一致的。當一個產品有一群產品經理的時候，他們或者她們經常因為彼此不拉齊想法，同樣的列表篩選功能可能會搞出五花八門的做法來。這個時候就需要用 UI 設計師等角色去橫向拉齊。

總之先要把需求的源頭給按住了。而不是在需求的下游，用可復用抽象代碼來兜底。這也是《領域驅動開發(fā)》要求客戶，產品經理，程序員能夠更多的交流，更多的形成共識的原因。

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

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

假設起初我們寫了三個方法

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 這個參數(shù)。那么我們應該用 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 來定義所有的參數(shù)。然后 f1, f2, f3 的行為都是模型驅動的。那么似乎，用戶也不需要寫什么 f1/f2/f3，他們寫這個就好了：

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

這樣不但代碼量很小，而且和具體的實現(xiàn)還“解耦”了。將來技術要升級了，也只需要升級框架就好了，業(yè)務邏輯是不需要動的。這種“讓用戶在調用棧上找不到自己的代碼”，弊端在哪里？

很容易找不到一個配置項，一個參數(shù)，產生影響的位置?？赡苁窃诳蚣艽a的任何地方。寫代碼的地方，和實際產生行為的地方，之間沒有編譯期可以跟蹤的符號依賴關系了。當然這是所有 mutable data 的問題，所有寫入的地方，都不知道會在哪里讀取，會對讀取的地方產生什么影響。程序員的日常就是搞這些幺蛾子的，當然處理這樣的問題是駕輕就熟。但并不意味著是沒有成本的。這樣的間接性越多，代碼就越難以閱讀。

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

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

當我們讀到了上面的定義的時候，prepopulated_fields 影響了增刪改查的哪個界面上的哪幾個字段，是如何影響的？

有的同學可能會說 Antd 的組件參數(shù)也有幾十個那。但是當我們看到這樣的 React 組件的調用代碼的時候

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

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

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

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

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

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++的拷貝構造函數(shù)，隱式轉換構造函數(shù)。也是類似的問題。在賦值的語法里偷偷塞了行為進去。

也就是框架代碼，DSL的實現(xiàn)，他們是可以通過魔法來修改賦值操作和取值操作的。大部分程序員都很難意識到，一行平凡的代碼，可以發(fā)生很不平凡的事情。這就會導致出問題的時候，真正產生問題的地方被略過，因為那個地方可能不過就是一行取值操作，或者一行賦值操作。

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

要復用之前，先和產品經理或者客戶達成共識。

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

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

不要以 DRY 之名做任何事情?？赡軓钠渌麆訖C，造成的結果是要 DRY。但不要以 DRY 為出發(fā)點做任何事情。

謹以此文批判自己過去犯的一些錯誤，引以為戒。

感謝各位的閱讀，以上就是“為什么不要以DRY之名發(fā)明低代碼DSL”的內容了，經過本文的學習后，相信大家對為什么不要以DRY之名發(fā)明低代碼DSL這一問題有了更深刻的體會，具體使用情況還需要大家實踐驗證。這里是創(chuàng)新互聯(lián)，小編將為大家推送更多相關知識點的文章，歡迎關注！

名稱欄目：為什么不要以DRY之名發(fā)明低代碼DSL
地址分享：http://bm7419.com/article8/pcgdop.html

成都網站建設公司_創(chuàng)新互聯(lián)，為您提供微信公眾號、響應式網站、電子商務、手機網站建設、做網站、網站收錄

廣告

聲明：本網站發(fā)布的內容（圖片、視頻和文字）以用戶投稿、用戶轉載內容為主，如果涉及侵權請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內容未經允許不得轉載，或轉載時需注明來源： 創(chuàng)新互聯(lián)