系統(tǒng)設計的核心作用是在業(yè)務現(xiàn)實世界和抽象的IT實現(xiàn)之間建立起一道橋梁。
與其他行業(yè)被物理特性限制所束縛不同，軟件世界可以變得無限龐大，而限制軟件發(fā)展的其實是人的認知能力。所有軟件設計服務的目標其實都是管理人的認知，是關(guān)于人有限的精力如何學習軟件中無限多的知識（Knowledge）的問題。
(資料圖片僅供參考)
軟件行業(yè)從傳統(tǒng)的瀑布開發(fā)模式，過渡到了敏捷開發(fā)模式，對于文檔，敏捷宣言中說的是“工作的軟件高于詳盡的文檔”，但實際工作中開發(fā)人員寫的文檔是越來越少，或者是能不寫就不寫；流程上，更是恨不得需求還沒有出來就直接擼代碼，擼完代碼就直接上線。
缺乏整體系統(tǒng)設計，設計出來的系統(tǒng)就不夠完善，再加上快速的系統(tǒng)迭代，導致系統(tǒng)越來越難以維護，開發(fā)成本越來越高，一個項目需要參與的人越來越多，最終沒有人能夠說明清楚，這個系統(tǒng)具體是如何運行的了。隨著團隊人員的更替，加上每個人的設計思路又不一樣，更加加重了系統(tǒng)的復雜性。
上面也就引入了兩個問題：
缺乏文檔問題：不清楚系統(tǒng)長什么樣？軟件復雜度高的問題：迭代修改系統(tǒng)的成本高。上面兩個問題在MTDD都有相應的解法，后面我們會詳細講述，接下來我還是再詳談一下軟件復雜度。
2、軟件復雜度2.1 軟件復雜度的癥狀和原因《軟件設計哲學》這本書中提到，軟件復雜度的三種癥狀：
變化放大：需要修改一個地方，卻發(fā)現(xiàn)改動的點涉及全站，導致難度倍增；認知負荷：開發(fā)者需要完成一項任務的知識量；未知：開發(fā)者在修改代碼后，不知道它的實際影響面。為了從源頭上解決這些問題，John Ousterhout教授提出：從項目一開始就要嚴格遵循進行軟件設計的原則，那些為了趕工期而沒有經(jīng)過良好設計的代碼，最終經(jīng)過多次迭代后，都會變得越來越臃腫，繼而變得再也無法維護了。
我非常認可John Ousterhout的觀點，但
實際操作中發(fā)現(xiàn)基本不具有可行性，原因：
.從瀑布模式到敏捷開發(fā)，已經(jīng)很難回去了。是否遵循良好的軟件設計原則很難衡量。沒有這么多的時間來檢查（代碼review，設計renview）是否有按照這些原則來設計和編碼。我的觀點
對于“簡化模塊依賴”，“減少模糊性”，“高內(nèi)聚低耦合”這些原則的話術(shù)，知道的人就知道怎么做，不知道的人還是不知道怎么做。這些術(shù)語缺少實際的指導性。
2.2 軟件復雜度是怎么引入的（另外一個角度）2.2.1 我們來看一個例子圖片
2.2.2 系統(tǒng)到底是誰做出來的一個有意思的現(xiàn)象：
圖片
那系統(tǒng)到底是誰做出來的呢？（這里主要說的是業(yè)務系統(tǒng)。一些中間件之類的系統(tǒng)，基本都都由研發(fā)來完成的。）
圖片
系統(tǒng)設計離不開，業(yè)務人員、產(chǎn)品經(jīng)理以及技術(shù)研發(fā)的合作，業(yè)務和產(chǎn)品的需求沒有理清楚，同樣會導致系統(tǒng)復雜度提升。
2.2.3 另外一種系統(tǒng)復雜度引入環(huán)節(jié)圖片
系統(tǒng)各主要相關(guān)方缺乏對系統(tǒng)設計的信息拉齊，給系統(tǒng)復雜度的提升同樣有重要的貢獻。
那么如何讓各角色更好的進行信息對齊，這就引入了MTDD。
3、一種新型的系統(tǒng)設計解決方案：MTDD前面提到了《軟件設計哲學》作者提出了一些系統(tǒng)設計總結(jié)，也有些人提出了一些方法論，比如領(lǐng)域驅(qū)動設計（DDD），測試驅(qū)動開發(fā)（TDD），行為驅(qū)動開發(fā)（BDD）；但是這些模式，都是從設計方法論上給與指導，戰(zhàn)術(shù)上指導偏少。下面我們來介紹我自己沉淀的一個方法論，和戰(zhàn)術(shù)指導MTDD&MTDP。
3.1 MTDD是什么MTDD的全稱是：Module Tree Drive Design, 模塊樹驅(qū)動設計，也可以叫做能力樹驅(qū)動設計。MTDD是一種系統(tǒng)設計模式，并同時提供了戰(zhàn)術(shù)層的SDK。
MTDD主要思想是讓業(yè)務，產(chǎn)品、研發(fā)共同對復雜業(yè)務系統(tǒng)中的模塊進行分析，并對這些業(yè)務模塊做好分層分類，最終形成各方達成一致的一棵模塊樹；研發(fā)人員開發(fā)可以通過給定的SDK，將系統(tǒng)中的代碼按照模塊的方式進行打標分類，系統(tǒng)根據(jù)代碼中打標分類，自動生成一顆可視化的模塊樹。通過這個方式，讓系統(tǒng)與業(yè)務保持高度一致。
MTDD從某個方面說也是DDD領(lǐng)域驅(qū)動設計中所宣導的統(tǒng)一語言一種實現(xiàn)方式。 |
MTDD思想主要體現(xiàn)在：
當業(yè)務和產(chǎn)品需要對系統(tǒng)能力進行新增、修改、或者擴展時，可以對照系統(tǒng)這顆可視化的模塊樹進行溝通，然后進行思考和設計具體的哪個或者哪些模塊需要進行修改或者擴展，并產(chǎn)出修改后的最終結(jié)果。研發(fā)人員接到接到需求后開發(fā)完成后，新開發(fā)的功能就會自動的在系統(tǒng)的模塊樹上進行呈現(xiàn)。產(chǎn)品和業(yè)務驗收時，就可以對照系統(tǒng)上的模塊樹，進行功能驗收。3.2 MTDD的特點3.2.1 模塊化在系統(tǒng)設計中，模塊是指一組相互依賴的程序元素，通常是在模塊內(nèi)部完成特定的工作。模塊也可以被組合以形成更大的、更復雜的系統(tǒng)。子模塊則是模塊的一部分，通常是實現(xiàn)特定的功能。
在MTDD中， 模塊化更多的是從業(yè)務的角度上來說的，比如一個營銷觸達模塊，比如倉儲系統(tǒng)中的入庫模塊；模塊下面還可以有子模塊，子模塊也可以有子子模塊， 這個可以根據(jù)一定的顆粒度進行靈活拆分，重點是業(yè)務，產(chǎn)品、研發(fā)三方達成一致，并且明確模塊的關(guān)系（父子關(guān)系）。
3.2.2 分類與分層將模塊化的模板進行分層分類。
在系統(tǒng)設計中，分層和分類是非常重要的，這有助于提高系統(tǒng)的可擴展性和可維護性，也能很好的降低人的認知負荷。
OOD（面對對象設計）本質(zhì)就是一種分類思想。DDD（領(lǐng)域驅(qū)動設計）本質(zhì)也是一種分類思想。分層設計：
在現(xiàn)實世界中，所有我們見到的事物，人類都自然的對其給與了分層，比如：
圖片
再比如在倉儲管理中，也會有天然的分層：
圖片
分層分類-復雜度分解：
我們的目標是將一些同類型的提高一個抽象層次，將大腦比較難處理的9個概念簡化成3個，這樣就無需記憶其中的每個概念，另外由于較高層次的思想總是能夠提示下面一個層次的思想，所以記憶起來會更方便。所有的思維過程（思考、記憶、解決問題）都應該使用這樣的分組和概括的方法，將大腦中的無序信息組成一個相關(guān)關(guān)聯(lián)的金字塔結(jié)構(gòu)。
每個模塊下又可以有多個子模塊。
總而言之，設計人員對模塊進行分層分類后，可以大大降低思考復雜度， 這個很好理解。
圖片
3.2.3可視化分層分類的模塊以樹狀接口進行可視化呈現(xiàn)。
右邊的圖是：研發(fā)實現(xiàn)產(chǎn)品需求后，系統(tǒng)自動生成的能力樹的樣子。
3.2.4 強大的配置化能力所有的業(yè)務配置，都是業(yè)務相關(guān)的，系統(tǒng)用來控制業(yè)務的邏輯，本質(zhì)就是業(yè)務的一部分。在傳統(tǒng)的業(yè)務系統(tǒng)中一般有兩種方式來實現(xiàn)：
使用需要一個配置中心，配置中心一般都使用key-value的方式來存儲。業(yè)務系統(tǒng)根據(jù)配置的key到配置中心來獲取value，并解析value的值。業(yè)務人員直接在配置中心來做配置值的修改。每個配置單獨開發(fā)配置頁面，業(yè)務人員在配置頁面上進行值修改。這兩種方式都存在一些問題：
使用配置中心，雖然將所有的配置都進行了統(tǒng)一，但是面對一些負責配置時，需要采用類似json這種格式來存儲，修改的時候只能修改json的值，無法通過頁面富樣式頁面來修改。每個頁面單獨開發(fā)配置頁面，對配置友好，但是開發(fā)工作量大，因為每個配置都需要前端開發(fā)。使用MTDD配置化能力時，就可以解決上面兩個問題
業(yè)務配置一定屬于具體的業(yè)務模塊，因為配置是用戶控制某個具體的模塊邏輯，所以配置盡量掛在模塊下面是一個非常自然的做法。
我的觀點
業(yè)務配置一定屬于具體的業(yè)務模塊，因為配置是用戶控制某個具體的模塊邏輯，所以配置盡量掛在模塊下面是一個非常自然的做法。
3.2.5 其他優(yōu)勢讓業(yè)務，產(chǎn)品，在提需求的時候，就能夠以系統(tǒng)能力的方式去思考。在有新需求時，產(chǎn)研可以方便的在能力樹上找到需要改動的模塊。測試的影響范圍也很容易確定。對修改友好，影響范圍可控。讓程序員天然的進行開閉原則，對新增開放，對修改改封閉。3.3 MTDD作用與總結(jié)系統(tǒng)設計的核心作用是在業(yè)務現(xiàn)實世界和抽象的IT實現(xiàn)之間建立起一道橋梁。而業(yè)務系統(tǒng)本身就是現(xiàn)實世界在計算機系統(tǒng)中的映射。
現(xiàn)實世界是一個模塊化的，層次化的樹狀結(jié)構(gòu)，所以業(yè)務系統(tǒng)就應該自然的通過模塊化的樹狀結(jié)構(gòu)來進行映射。
MTDD正是基于此，通過一個可視化的能力樹，這顆能力樹作為實實在在，可以看得見的橋梁，來拉齊業(yè)務、產(chǎn)品和系統(tǒng)研發(fā)。并最終做到讓業(yè)務和產(chǎn)品，可以真正以產(chǎn)品能力搭建的視角來規(guī)劃，設計系統(tǒng)模塊和系統(tǒng)功能?？梢宰屜到y(tǒng)架構(gòu)人員自然而然的進行高內(nèi)聚，低耦合的系統(tǒng)設計，可以讓一線研發(fā)自然而然的進行模塊化編程。
模塊樹驅(qū)動設計閉環(huán)
圖片
4、MTDD實戰(zhàn)4.1 MTDD戰(zhàn)略層4.1.1 統(tǒng)一語言DDD中也有統(tǒng)一語言，或者叫做“通用語言（Ubiquitous Language ）”
當團隊成員不能享用一個公共語言來討論領(lǐng)域時，項目會面臨嚴重的問題。領(lǐng)域?qū)＜沂褂米约旱男性?，技術(shù)團隊成員在設計中也用自己的語言討論領(lǐng)域。
代碼可能是一個軟件項目中最重要的產(chǎn)物，但每天用來討論的術(shù)語卻與代碼中使用的術(shù)語脫節(jié)了。即使是同一個人都需要使用不同的 語言來交談和書寫，所以要想完成對領(lǐng)域的深刻表達通常需要產(chǎn)生 一種臨時形式，但這種形式不會出現(xiàn)在代碼甚至是書寫的內(nèi)容中。
在交流的過程中，需要做翻譯才能讓其他的人理解這些概念。開發(fā) 人員可能會努力使用外行人的語言來解析一些設計模式，但這并一定都能成功奏效。領(lǐng)域?qū)＜乙部赡軙?chuàng)建一種新的行話以努力表達 他們的這些想法。在這個痛苦的交流過程中，這種類型的翻譯并不能對知識的構(gòu)建過程產(chǎn)生幫助。
上面這段是話是摘自《領(lǐng)域驅(qū)動設計精簡版 》
Eric Evans 早就意識到，需要在領(lǐng)域?qū)＜液脱邪l(fā)之間共用一套通用語言，并且Eric Evans也做了大量的舉例說明，來說明什么是通用語言，以及統(tǒng)一通用語言可以更好的服務于系統(tǒng)設計。
MTDD更也是站在巨人的肩膀上，提供了一個方法論：讓業(yè)務，產(chǎn)品，技術(shù)在系統(tǒng)設計之前，一起對照系統(tǒng)模塊樹來進行溝通；對于一個新功能，一起思考是在某個模塊下新增模塊，還是修改貨擴展模塊內(nèi)部的邏輯；在對齊后，就可以進行開發(fā)了，并且研發(fā)有一定的范式開做開發(fā)，開發(fā)后，系統(tǒng)的模塊樹就能夠自動可視化的呈現(xiàn)出來；業(yè)務和產(chǎn)品也可以通過可視化的方式進行驗收；
4.1.2 按定制規(guī)范來做設計和開發(fā)上面說了在業(yè)務方、產(chǎn)品、技術(shù)在參照能力樹根據(jù)需求并對齊需要開發(fā)的模塊后，研發(fā)可以按照一定的范式做系統(tǒng)開發(fā)；這是因為我們提供了一套開發(fā)的SDK，以及SDK的使用文檔，來幫助研發(fā)人員來進行基于能力樹功能的開發(fā)。系統(tǒng)功能開發(fā)完成后，相應的模塊信息就可以自動在模塊樹頁面上進行呈現(xiàn)。當然想要在頁面上進行呈現(xiàn)，需要有前端來支持。
這個規(guī)范主要由幾個主要的java注解來實現(xiàn)：
@Module@ModuleConfig@ConfigItem4.1.3系統(tǒng)的模塊化以及分層分類
使用上面的java注解，對代碼中模塊進行打標。
業(yè)務模塊化，并且做了分層與分類，那么系統(tǒng)中的代碼需要根據(jù)業(yè)務中的分層分類進行進行分類打標，使其與業(yè)務分層分類保持一致。
4.1.4 持續(xù)重構(gòu)（Continue Refactor）我們這個世界夠復雜了吧，如果讓你設計一個IT系統(tǒng)來實現(xiàn)刻畫這個世界的方方面面，我打賭一定沒有人搞得定；但現(xiàn)實中的這個世界還是能夠有條不紊的發(fā)展演進，沒有需要出現(xiàn)“推倒重來”的現(xiàn)象，為什么呢， 我認為是我們的世界一直在用各種方式不停的重構(gòu)。
“物競天擇，適者生存”出自達爾文的進化論，達爾文在1859年出版的《物種起源》一書中系統(tǒng)地闡述了他的進化學說。物競天擇，適者生存是指物種之間及生物內(nèi)部之間相互競爭，物種與自然之間的抗爭，能適應自然者被選擇存留下來的一種叢林法則。
對于軟件系統(tǒng)也是這樣，業(yè)務是在不停的發(fā)展， 我們的認知也是一直不斷的更新，當“我們”通過可視化的能力樹發(fā)現(xiàn)一些突兀時，那肯定是某個或者某些模塊拆分不正確，或者模塊提供的能力不合適，這時，我們就可以考慮對模塊樹進行重構(gòu)了，要么是拆分模塊，要么是調(diào)整模塊的關(guān)系，要么是修改模塊的職責。
4.1.5關(guān)于產(chǎn)品需求如果產(chǎn)品了解MTDD，那么就會提出更加符合產(chǎn)品化的需求了
如果研發(fā)對MTDD理解深入，那么當產(chǎn)品的需求不符合產(chǎn)品化，能力化時，就會與產(chǎn)品進行溝通，產(chǎn)品修改需求，以便更好的設計出產(chǎn)品化，系統(tǒng)能力化的需求。
?好的產(chǎn)品需求 | ×不好的產(chǎn)品需求 |
| 對現(xiàn)有系統(tǒng)能力的擴展增加新的系統(tǒng)能力 | 針對特定的業(yè)務需求 定制系統(tǒng)能力 |
MTDP的全稱是Module Tree Drive Programing, 領(lǐng)域樹驅(qū)動編程。
4.2.1模塊注解@Module的定義
/** * * 模塊注解，打在一個服務類上，Module注解是繼承了Component注解，因此它注解的類可以被實例化到Spring中去 * 服務啟動時會掃碼所有Module類，將他們組裝成樹進行持久化。 */@Target({ElementType.TYPE, ElementType.ANNOTATION_TYPE})@Retention(RetentionPolicy.RUNTIME)@Component@Documentedpublic @interface Module { /** * 該模塊的key * 在設置模塊的key的時候，在同一個服務里面（同一個根節(jié)點），如果兩個類設置的key是一樣，最后會被去重為一個模塊，無論是單體服務還是分布式工程。 * moduleKey全局唯一，就算它們歸屬不同的根節(jié)點，也不能設置一樣的moduleKey， * 不同根節(jié)點的模塊，如果設置了同一個moduleKey，后部署的服務將無法能力樹的變更情況進行持久化。 * @return */ String moduleKey(); /** * 用于指定該模塊的父模塊， * 根節(jié)點的parentModule指定為 {@link Void}.class。 * 每個模塊指定他們的夫模塊，直到可達根節(jié)點，最后生成一顆樹。 * 指定parentModule時一定要注意，不能循環(huán)依賴了，循環(huán)依賴的情況下，服務將拋出異常無法啟動， * @return */ Class parentModule(); /** * 該模塊名稱 * @return */ String moduleName(); /** * 模塊描述，一個該模塊詳細的描述 * @return */ String moduleRemark() default ""; /** * 能否被剪枝，你是可以設置模塊能不能被剪枝，默認是不可以的（后續(xù)會根據(jù)數(shù)量對比情況進行調(diào)整默認值）。 * 我們應該將系統(tǒng)中必要的功能設置為無法裁減，將那些加強性的能力，智能化的能力，衍生化的能力，非基本的能力設置為可以裁減 * @return */ boolean cutAble() default false;}模塊的具體例子：
@Module(moduleKey = "scm.wms", moduleName = "WMS", parentModule = NULL)public class WmsModule { //業(yè)務邏輯}@Module(moduleKey = "scm.wms.inner.test1", moduleName = "測試模塊1", parentModule = WmsModule.class)public class InnerTestModule1 { //業(yè)務邏輯}@Module(moduleKey = "scm.wms.inner.test2", moduleName = "測試模塊2", parentModule = WmsModule.class)public class InnerTestModule2 { //業(yè)務邏輯}每個模塊都有父模塊ParentModule，跟模塊的父模塊為NULL，模塊樹則是由所有模塊組成的一個樹狀結(jié)構(gòu)的樹。
圖片
4.2.3 裁剪與恢復圖片
4.2.4 模塊配置找到模塊上的配置，點擊展開配置
圖片
展開配置如下：
圖片
上面的配置，是無需前端進行開發(fā)，只需要后端實現(xiàn)就好，后端代碼：
@Data@ModuleConfig(configKey = "scm.wms.inbound.receive.oneBarcodeMuliSku", configName = "收貨一碼多品配置", module="scm.wms.inbound.receive")public class ReceiveScanOneCodeMoreSkuModuleConfig { @ConfigItem(itemName = "是否開啟一碼多品的攔截" , itemRemark = "如果關(guān)閉, 一碼多品的商品在收貨時, 不會收到\"該條碼對應多個商品，請打印商品標簽\"的提醒, prd:https://poizon.feishu.cn/wiki/wikcnstRj3Qfbn4fXDrmvBk6R0d" , defaultValue = "true") private Boolean isOpen; @ConfigItem(itemName = "攔截方式" , itemRemark = "如果配置強攔截，則必須打印商品標簽, 阻斷收貨流程。如果配置弱攔截, 只是提醒一下, 不阻斷收貨流程" , scopeClass = InterceptType.class , defaultValue = "WEAK") private String interceptType; @ConfigItem(itemName = "攔截規(guī)則" , scopeClass = InterceptRuleType.class , defaultValue = "ARBITRARY") private String interceptRule;}配置的幾個java注解：
ModuleConfig/** * 業(yè)務配置注解，業(yè)務配置是Module的字段 */@Target({ElementType.TYPE})@Retention(RetentionPolicy.RUNTIME)@Documentedpublic @interface ModuleConfig { /** * 配置的key */ String configKey(); /** * 配置名稱 * @return */ String configName(); /** * 配置描述，鼠標懸浮時的氣泡提示 * @return */ String configRemark() default ""; /** * 是否必要，必要的不可以被剪枝 * @return */ boolean cutAble() default false;}@Target({ElementType.FIELD})@Retention(RetentionPolicy.RUNTIME)@Documentedpublic @interface ConfigItem { /** * 配置名稱 * @return */ String itemName(); /** * 配置描述，鼠標懸浮時的氣泡提示 * @return */ String itemRemark() default ""; /** * 默認值 * @return */ String defaultValue() default ""; /** * 如果你的取值范圍是枚舉指定枚舉的全路徑類名, * 如果你的取值范圍是一種策略，指定策略的interfaces的全路徑名稱 * @return */ Class scopeClass() default Void.class; /** * 范圍，默認通用，當你需要定制時才需要指定 * @return */ ScopeType scopeType() default ScopeType.COMMON; /** * 自定義組件，需要前端參與開發(fā)，非特殊組件，無需設置，DSK會自動給你尋找組件 * @return */ String customScopeType() default ""; /** * 對位文本類型的配置，min則為文本長度限制的最小值 * 對于數(shù)字類型的配置，min則為數(shù)字的最小值。 */ int min() default Integer.MIN_VALUE; /** * 對位文本類型的配置，min則為文本長度限制的最大值 * 對于數(shù)字類型的配置，min則為數(shù)字的最大值。 */ int max() default Integer.MAX_VALUE;}TMF 是 Trade Modularization Framework 的全稱，即交易模塊化框架，最初是交易系統(tǒng)中的一個代碼模塊，后來剔除業(yè)務耦合部分，獨立出來成為一個實現(xiàn)業(yè)務與平臺分離的業(yè)務框架。
5.2TMF架構(gòu)圖片
（圖片來源：https://www.cnblogs.com/shoshana-kong/p/14957739.html）
5.3 TMF2在架構(gòu)設計上主要的思想業(yè)務包與平臺分離的插件化架構(gòu)：平臺提供插件包注冊機制，實現(xiàn)業(yè)務方插件包在運行期的注冊。業(yè)務代碼只允許存在于插件包中，與平臺代碼嚴格分離。業(yè)務包的代碼配置庫也與平臺的代碼庫分離，通過二方包的方式，提供給容器加載。全鏈路統(tǒng)一的業(yè)務身份：平臺需要能有按“業(yè)務身份”進行業(yè)務與業(yè)務之間邏輯隔離的能力，而不是傳統(tǒng)SPI架構(gòu)不區(qū)分業(yè)務身份，簡單過濾的方式。如何設計這個業(yè)務身份，也成為業(yè)務間隔離架構(gòu)的關(guān)鍵。管理域與運行域分離：業(yè)務邏輯不能依靠運行期動態(tài)計算，要能在靜態(tài)期進行定義并可視化呈現(xiàn)。業(yè)務定義中出現(xiàn)的規(guī)則疊加沖突，也在靜態(tài)器進行沖突決策。在運行期，嚴格按照靜態(tài)器定義的業(yè)務規(guī)則、沖突決策策略執(zhí)行。圖片
（圖片來源：https://www.infoq.cn/article/w3ztwqs9q4astbksd0mj）
5.4MTDD VS TMF圖片
6、MTDD 展望6.1 將模塊間的耦合度進行量化前面有提到“持續(xù)重構(gòu)”這個概念；但是持續(xù)重構(gòu)提出來很容易，但是做起來，就沒有這么簡單；
What：首先是如何發(fā)現(xiàn)需要重構(gòu)的點，為什么是這個點要重構(gòu)，而不是那個點要重構(gòu)。
When：其實是什么時候需要進行重構(gòu)。
為了更好的回答上面兩個問題，個人認為最重要的是能夠量化兩個模塊的復雜度。
?：高內(nèi)聚低耦合，但是耦合度到底高還是低，如何衡量。想要衡量，就需要做到數(shù)據(jù)化，指標化。
6.2 將模塊間的耦合度進行可視化圖片
標簽：
