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

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

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

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

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

總結(jié)

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

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

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

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

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

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

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

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

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

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

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

項(xiàng)目地址：https://github.com/YunaiV/ruoyi-vue-pro

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

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

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

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

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

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

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

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

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

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

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

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

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

項(xiàng)目地址：https://github.com/YunaiV/yudao-cloud

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

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

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

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

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

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

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

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

如果有一個(gè)好的設(shè)計(jì)，我們需要謹(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è)計(jì)好的標(biāo)準(zhǔn)是什么？衡量的維度有優(yōu)先級(jí)嗎？

兩個(gè)評(píng)價(jià)標(biāo)準(zhǔn)自治性和一致性：

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

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

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

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

總結(jié)

大部分情況下系統(tǒng)的核心復(fù)雜度不會(huì)減少， 只是轉(zhuǎn)移；不會(huì)因?yàn)樗写a一個(gè)人寫，會(huì)比分成兩個(gè)人寫更快，分工是應(yīng)該且必須的。但是請(qǐng)注意的是：

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

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

審核編輯 ：李倩