如何評價一個架構(gòu)的好壞？

最近設(shè)計了幾個架構(gòu)，每次設(shè)計完成后，心里都會想，這個架構(gòu)到底是好是壞？我會不會把組內(nèi)的人給坑了？有沒有一個標(biāo)準(zhǔn)來衡量，這個架構(gòu)目前就是好的？簡單的講，我們設(shè)計了一個架構(gòu)，我們怎么敢說這個架構(gòu)是好的？

一個好的架構(gòu)

總結(jié)下來，一個好的架構(gòu)可以從下面幾個方面去評估：

包括：形式，效果和實施三個維度。

形式

評價一個架構(gòu)形式，第一個原則就是：高內(nèi)聚，低耦合。這里面的關(guān)鍵在于：內(nèi)聚的邊界在哪兒？耦合的邊界在哪兒？，什么樣的內(nèi)聚才算高內(nèi)聚？什么樣的耦合才是低耦合？有點難以把握，所以，我加了一點：職責(zé)明確，關(guān)系清晰，跟高內(nèi)聚，低耦合配合起來一起看一個架構(gòu)形式。

職責(zé)明確

分析一個架構(gòu)的時候，首先看每個模塊的職責(zé)，那怎么才算一個“職責(zé)”呢？

職責(zé)：業(yè)務(wù)上不可分割的原子操作

在判斷是不是高內(nèi)聚，是不是職責(zé)明確的時候，第一步就是先分析職責(zé)。我把職責(zé)定義為上面的形式，在業(yè)務(wù)上不可分割的原子操作。例如，共享單車的開始訂單操作是一個職責(zé)，包括了：創(chuàng)建訂單，開始計費，開鎖等操作，他們在業(yè)務(wù)上是一個整體，其中只拿出一項而言，對業(yè)務(wù)都沒有意義。另外，這個地方的業(yè)務(wù)，不一定是面向用戶的業(yè)務(wù)，像一些中間件系統(tǒng)，這個時候的業(yè)務(wù)就是對系統(tǒng)功能而言。

接下來，就是把模塊的這些職責(zé)列出來，看看是不是明確的，進(jìn)而看看是不是內(nèi)聚的。其實，這幾個詞還是沒法客觀的給一個標(biāo)準(zhǔn)，就像計算1+1一樣，如果等于2就是對的。這里面很大程度還是依賴于一個主管的判斷。這個主管的判斷我覺得可以借助于費曼學(xué)習(xí)法，就是：把這個系統(tǒng)的職責(zé)，講給一個不熟悉這個系統(tǒng)的人聽，看看能不能用最簡潔的語言描述清楚。另外，還可以從另外一個視角去看，內(nèi)聚的背后驅(qū)動力其實是領(lǐng)域化和分工的不同，所以，如果一個人要掌握這個系統(tǒng)，需要具備不同領(lǐng)域的知識，那么就一定是內(nèi)聚了太多的職責(zé)。

關(guān)系清晰

如果職責(zé)明確，高內(nèi)聚不好客觀的評價，但是，關(guān)系清晰和低耦合確實有辦法來衡量：那就是畫關(guān)系依賴圖。,所以，一個好的架構(gòu)師，一定能夠?qū)φ麄€系統(tǒng)的職責(zé)有明確的認(rèn)知，然后畫出一張清晰的關(guān)系依賴圖，然后從這張圖里面，發(fā)現(xiàn)問題，找出優(yōu)化的方向。

看一個最簡單的例子，在關(guān)系1中，是比較好也是比較理想的情況：模塊A單向依賴模塊B，如果一個系統(tǒng)所以的模塊都是單向依賴，并且不存在循環(huán)依賴的話，整個系統(tǒng)就是分層的樹,層次清晰。

然后，往往存在大量如關(guān)系2中的依賴關(guān)系，造成這種關(guān)系基本上都是職責(zé)不明確所致：要么把依賴的職責(zé)抽離出來放到模塊C或者模塊D上，要么單獨抽取一個底層模塊，供上層C和D使用。

總的來說，從形式上，本質(zhì)上關(guān)注職責(zé)明確和職責(zé)內(nèi)聚，但是，往往有的時候我們很難給一個客觀的標(biāo)準(zhǔn)去衡量，所以，更多的時候，我們要梳理清楚依賴關(guān)系，把關(guān)系理順，發(fā)現(xiàn)模塊之間的問題，降低耦合，進(jìn)行抽取或者內(nèi)聚，整體上實現(xiàn)分層的樹狀結(jié)構(gòu)。

效果

一個架構(gòu)，不管如何設(shè)計，都可以當(dāng)作黑盒，從效果上去評估：

首要的是，能夠解決問題

這里面隱含了一個前提，就是識別問題。其實我在很長的一段時間內(nèi)，以為識別問題是架構(gòu)師的難點，但根據(jù)最近的實踐發(fā)現(xiàn)，其實問題還是比較容易識別的，因為現(xiàn)在基本上不是從0到1，或者是你一個人在工作，基本上一個團隊已經(jīng)折騰了一段時間，這個時候，痛點，問題大家都知道。只是缺少解決的方案。甚至有的時候解決的方案大家也都知道的大概，只是缺少實施的方案。

其次，能夠提效降本。

解決問題只是第一步，接下來就是體現(xiàn)一個好的架構(gòu)師的能力：提效降本，提高解決問題的效率，降低解決問題的成本。要實現(xiàn)提效降本，難點不在于如何衡量：畢竟這一點還是很容易衡量的，就看投入的資源有多少就好了；難點在于設(shè)計出一套提效降本的方案，本文重點不是講設(shè)計，所以大概列一些點：

• 模型設(shè)計和優(yōu)化

• 技術(shù)引進(jìn)

• 技術(shù)創(chuàng)新：很難。

其實，架構(gòu)從直接效果上看是增加了負(fù)責(zé)度，就好比蓋樓，蓋一座大廈肯定比蓋一間草屋復(fù)雜度高，但是，前者卻能住更多的人。所以，好的架構(gòu)一定是平衡了復(fù)雜度和收益，最大化提高效率降低成本。

實施

一個架構(gòu)，如果不能落地就不算架構(gòu)，所以在評價的時候，還需要評價實施方案，這一塊的標(biāo)準(zhǔn)也好制定，主要從兩個方面：

• 時間/人力成本：就看要投入多久，多少人來實現(xiàn)

• 維護(hù)成本：好不容拉一票人開放完成，結(jié)構(gòu)后面很難維護(hù)，也算一個失敗的架構(gòu)。

總結(jié)

這么看，整體上除了內(nèi)聚和職責(zé)明確，這一塊不好衡量之外，其他的都是可以衡量的：

• 依賴關(guān)系清晰：畫一個系統(tǒng)依賴關(guān)系圖，越細(xì)越好，另外，既然是關(guān)系，就要有強弱依賴，也要理清楚

• 效果也可以衡量：給別人清楚你設(shè)計這套架構(gòu)能帶來的收益，要講清楚不要模模糊糊

• 實施成本也盡可能衡量：有的時候?qū)嵤┏杀静荒芤幌略u估準(zhǔn)確，而是在開發(fā)的過程中發(fā)現(xiàn)一些問題，這個時候要主動拉更多的人討論，看看有沒有潛在的坑，尤其是對遺留系統(tǒng)的重構(gòu)。

source: https://lishoubo.github.io/2019/05/03/如何評價一個架構(gòu)的好壞？/

喜歡，在看