架構(gòu)設(shè)計：為什么說復(fù)用是邪惡的？

為什么我們喜歡復(fù)用呢？

認(rèn)為復(fù)用可以提高效率的推理邏輯是怎樣的？

你說復(fù)用帶來了這么多問題，那我們平時使用各種框架，基礎(chǔ)算法庫都要自己寫一份嗎？

那我設(shè)計系統(tǒng)時，盡量將我的設(shè)計通用化就好了（例如拆很多個 CRUD 的微服務(wù)），這樣就能更多的進(jìn)行復(fù)用，提高生產(chǎn)效率對嗎？

那系統(tǒng)設(shè)計好的標(biāo)準(zhǔn)是什么？衡量的維度有優(yōu)先級嗎？

總結(jié)

在系統(tǒng)設(shè)計和寫代碼的過程中，我經(jīng)常會聽到「復(fù)用」這個詞，以「復(fù)用」為目的來設(shè)計技術(shù)，業(yè)務(wù)，組織架構(gòu)。例如：

抽象出一個類，函數(shù)，UI 組件，用于不同的場景

抽象出一個微服務(wù)，越細(xì)越好，這樣可以靈活的組合

抽象出一個業(yè)務(wù)中臺，沉淀各種基礎(chǔ)業(yè)務(wù)功能，供全公司使用

組織（管理）架構(gòu)中，抽象出一個職能豎井（后端，前端，QA，財務(wù)），被不同的產(chǎn)品使用

產(chǎn)品設(shè)計中要完成一個性能功能，發(fā)現(xiàn)跟之前一個功能相似，就復(fù)用之前的功能設(shè)計，改改繼續(xù)用

為什么我們喜歡復(fù)用呢？

主要目的：既然一部分功能已經(jīng)存在，為什么還要自己造呢？直接拿來用，這樣我可以做得更少，所以能夠提升個人的生產(chǎn)效率。

接受的教育：一直以來的教育，大部分工程師都學(xué)習(xí)過 DRY principle；《設(shè)計模式》的的英文書名就是 《可復(fù)用面向?qū)ο筌浖幕A(chǔ)》，都在強調(diào)復(fù)用。

編程習(xí)慣：在面向?qū)ο笳Z言里，工程師習(xí)慣了繼承，而繼承對于大部分人來說的目的就是復(fù)用

基于 Spring Boot + MyBatis Plus + Vue & Element 實現(xiàn)的后臺管理系統(tǒng) + 用戶小程序，支持 RBAC 動態(tài)權(quán)限、多租戶、數(shù)據(jù)權(quán)限、工作流、三方登錄、支付、短信、商城等功能

項目地址：https://github.com/YunaiV/ruoyi-vue-pro

視頻教程：https://doc.iocoder.cn/video/

認(rèn)為復(fù)用可以提高效率的推理邏輯是怎樣的？

如果我們要寫一個系統(tǒng)的所有代碼，我們需要寫大量的代碼。

如果我們能從其他地方重用一些以前寫過的代碼，我們就能寫更少的代碼。

我們能重用的代碼越多，我們寫的代碼就越少。

我們寫的代碼越少，我們就會越早完成系統(tǒng)!

這樣的推理邏輯是存在如下誤區(qū)：

所有的代碼（功能）需要相同的時間來寫

寫代碼是完成系統(tǒng)的最主要工作

如果你要寫得代碼依賴很多其他的「復(fù)用」模塊，你就要去理解不同的「復(fù)用」模塊提供的接口，很多時候只看文檔都不行；如果「復(fù)用模塊」的接口不是正好是適用你的場景，你就必須在講究使用接口和對方排期之間進(jìn)行選擇。

此外對于如何抽象出一個公共業(yè)務(wù)模塊，大部分人都沒什么標(biāo)準(zhǔn)，公共業(yè)務(wù)模塊的負(fù)責(zé)人成了業(yè)務(wù)的外包，效率更低。

另一點是任何維護(hù)生產(chǎn)環(huán)境系統(tǒng)的人都知道寫代碼只是整個工作中一小步，而且是確定性最高的一步，之后維護(hù)才是最占用時間的。我們需要不斷地進(jìn)行調(diào)試，部署，再調(diào)試，部署。一個用于很多依賴的模塊相對依賴少的模塊做這些工作的難度是高很多的。

基于 Spring Cloud Alibaba + Gateway + Nacos + RocketMQ + Vue & Element 實現(xiàn)的后臺管理系統(tǒng) + 用戶小程序，支持 RBAC 動態(tài)權(quán)限、多租戶、數(shù)據(jù)權(quán)限、工作流、三方登錄、支付、短信、商城等功能

項目地址：https://github.com/YunaiV/yudao-cloud

視頻教程：https://doc.iocoder.cn/video/

你說復(fù)用帶來了這么多問題，那我們平時使用各種框架，基礎(chǔ)算法庫都要自己寫一份嗎？

肯定不需要自己再寫一份，我們平時會使用各種編程語言（Java，Go），框架，庫。我們使用這些沒有任何問題，因為這是共識和標(biāo)準(zhǔn)，他們是足夠「通用，一般化」，并不是為了某個業(yè)務(wù)或者某個公司定制的。先有「共識，標(biāo)準(zhǔn)」，再談復(fù)用，絕對不是隨意的拿過來用。

那我設(shè)計系統(tǒng)時，盡量將我的設(shè)計通用化就好了（例如拆很多個 CRUD 的微服務(wù)），這樣就能更多的進(jìn)行復(fù)用，提高生產(chǎn)效率對嗎？

復(fù)用不是系統(tǒng)要追求的目標(biāo)。很多人認(rèn)為更多模塊的「復(fù)用」，就可以做到像樂高一樣快速搭建系統(tǒng)，但是很多復(fù)用并不是樂高，而是器官移植，不僅不能提高效率，要不斷面對各種各樣的排異反應(yīng)，降低了速度和穩(wěn)定性。很多創(chuàng)業(yè)公司快速發(fā)展時系統(tǒng)腐化的主要問題就出現(xiàn)在了強行復(fù)用上。強行復(fù)用的案例很常見，例如：

上百個字段的數(shù)據(jù)表（例如訂單表，數(shù)據(jù)表），不清楚哪個字段在哪個場景下有效

根據(jù)名詞來設(shè)計系統(tǒng)，出現(xiàn)業(yè)務(wù)中臺，例如訂單中臺，電商中臺，各部門之間不斷地扯皮

出來無數(shù)個小的微服務(wù)，然后搞個統(tǒng)一的業(yè)務(wù)編排調(diào)度層（所謂的 gateaway）來處理業(yè)務(wù)，可能還抽象 DSL；上線十分復(fù)雜，需要發(fā)布 N 各模塊；調(diào)度模塊是系統(tǒng)大單點，穩(wěn)定性迭代速度都是問題

如果有一個好的設(shè)計，我們需要謹(jǐn)記《Hints for Computer System Design》中的「Use a good idea again instead of generalizing it. A specialized implementation of the idea may be much more effective than a general one.」

那系統(tǒng)設(shè)計好的標(biāo)準(zhǔn)是什么？衡量的維度有優(yōu)先級嗎？

兩個評價標(biāo)準(zhǔn)自治性和一致性：

自治性：受其他模塊的影響程度，觀測模塊的接口是否穩(wěn)定。可以使用AutonomyMetrics[1] 進(jìn)行衡量

一致性：應(yīng)該使用一個模塊的地方使用一個模塊的程度，也可以衡量是否過早，過度抽象了?？梢允褂?ConsistencyMetrics[2]

在業(yè)務(wù)層次是否要從多個業(yè)務(wù)模塊中抽象出一個底層模塊，可以通過多個業(yè)務(wù)模塊的這部分公共邏輯部分是否要一起進(jìn)行改變進(jìn)行判斷，如果不是需要一起變化的就不要抽象出公共模塊。

根據(jù)個人經(jīng)驗如果你在要從各個業(yè)務(wù)模塊進(jìn)行抽象出一個模塊保持一致與保持在模塊保持自治之間猶豫時，要毫不猶豫優(yōu)先選擇「自治」。

總結(jié)

大部分情況下系統(tǒng)的核心復(fù)雜度不會減少， 只是轉(zhuǎn)移；不會因為所有代碼一個人寫，會比分成兩個人寫更快，分工是應(yīng)該且必須的。但是請注意的是：

不要為了復(fù)用隨意通用化，抽象化，復(fù)用不是目的。如果要通用化就拿ConsistencyMetrics[2] 來判斷是否是抽象合理的。

不要隨意復(fù)用其他的模塊，自治優(yōu)先，用 AutonomyMetrics[1] 衡量；如果要復(fù)用一定要確保共識和標(biāo)準(zhǔn)優(yōu)先，形不成共識和標(biāo)準(zhǔn)就不用復(fù)用。

審核編輯 ：李倩