軟體架構測量實踐

– 10 分鐘閱讀

軟體架構的度量對於確保系統的品質至關重要，但如何有效地應用度量並將其整合到工程實踐中卻是一個挑戰。本文從一個虛擬平台的開發案例出發，逐步說明如何在不同階段應用度量，並探討如何避免常見的度量陷阱。同時，也介紹瞭如何利用 ArchUnit 等工具進行自動化架構驗證，以及如何將度量指標轉化為可執行的適應度函式，以確保架構的完整性和一致性。

軟體架構中的測量角色：實踐與避坑

軟體架構設計是一個複雜的過程，涉及多個層面的考量。為了確保系統能夠滿足其關鍵品質屬性要求，測量成為了一個不可或缺的工具。本文將探討測量在軟體架構工作中的重要性，並透過一個虛構案例來說明如何有效地應用測量。

實踐案例：從設計到生產的測量

假設我們正在開發一個新的平台，需要處理大量的資料並提供高用性服務。從專案開始，我們就建立了一個估算電子試算表，用於預測系統的規模和效能需求。這個電子試算表成為了一個手動適應度函式（fitness function），幫助我們評估架構設計的有效性。

初始階段：建立基準測量

在設計階段，我們進行了初始的測量工作，包括：

  • 系統規模估算：預測資料函式庫大小和主要表格中的專案數量
  • 效能預測：預估系統的回應時間和吞吐量
  • 成本估算：預測硬體和軟體資源的需求

這些測量幫助我們更好地理解系統的需求，並為架構設計提供依據。

開發階段：持續測量與調整

隨著開發的進行，我們開始實施各種測量機制，包括：

  • 單元測試和整合測試中的效能測量
  • 程式碼審查中的靜態分析
  • 持續整合流程中的自動化測試

這些測量幫助我們及時發現問題並進行調整。例如，透過測量程式碼覆寫率，我們可以識別出需要改進的測試區域。

生產階段：監控與最佳化

一旦系統上線，我們立即開始進行生產環境中的測量，包括：

  • 透過移動應用和網頁請求進行正常使用情況的測量
  • 監控資料函式庫大小和主要表格中的專案數量
  • 繪製這些指標的趨勢圖並與初始估算進行比較

這些內部營運測量幫助我們估計資料函式庫的增長情況，並找出需要最佳化儲存大小的重點。

持續改進：根據測量結果調整

隨著平台的不斷發展，我們持續新增和移除測量指標，作為交付週期的一部分。這使我們能夠瞭解系統是否滿足其關鍵品質屬性要求，評估架構的有效性，並確定需要重點關注的領域。

常見陷阱與避免方法

在應用測量的過程中，我們需要注意避免一些常見的陷阱：

  1. 關注機制而非測量本身：測量機制的設計和實施可能很複雜，容易讓人陷入實施細節中。正確的做法是從簡單的機制開始，隨著測量工作的進展逐步增加複雜性。

  2. 選擇容易測量的指標：有些指標很難測量，人們傾向於測量容易的東西，如程式碼大小和回應時間。雖然這些指標很重要，但我們還需要測量對系統最重要的東西，即使它們更難測量。

  3. 過度關注技術指標而忽視業務指標：技術指標（如資料函式庫還原時間）通常比業務相關指標（如每小時總收入）更容易測量。然而，如果只關注技術測量，業務利益相關者可能無法理解或重視測量工作。

  4. 測量後不採取行動：測量工作需要與實際行動掛鉤。我們需要在每個迭代中留出一定比例的時間來進行最佳化工作或根據測量結果採取行動。

  5. 過度追求精確度：雖然精確的測量很重要，但通常有一個臨界點，超過這個點進一步提高精確度並不會改善我們的決策。

  6. 測量過多：現代平台使得大量測量成為可能，但這並不意味著我們應該這樣做。我們需要定期審查測量指標，關閉不再有用的測量。

程式碼示例：測量系統效能
import time
import random

def simulate_system_response():
    # 模擬系統回應時間
    response_time = random.uniform(0.1, 1.0)
    time.sleep(response_time)
    return response_time

def measure_system_performance(num_requests):
    total_response_time = 0
    for _ in range(num_requests):
        response_time = simulate_system_response()
        total_response_time += response_time
    average_response_time = total_response_time / num_requests
    return average_response_time

# 測量系統效能
num_requests = 100
average_response_time = measure_system_performance(num_requests)
print(f"平均回應時間：{average_response_time:.3f} 秒")

#### 內容解密：
1. `simulate_system_response` 函式模擬系統的回應時間，隨機生成0.1到1.0秒之間的延遲。
2. `measure_system_performance` 函式測量系統在處理一定數量請求時的平均回應時間。
3. 透過呼叫 `measure_system_performance` 函式，我們可以獲得系統的平均回應時間，從而評估系統的效能。

#### 圖表示例：系統回應時間分佈
```mermaid
graph LR
    D[D]
    A[開始測量] --> B[模擬系統回應]
    B --> C[記錄回應時間]
    C --> D{是否達到測量次數?}
    D -->|是| E[計算平均回應時間]
    D -->|否| B
    E --> F[輸出結果]

圖表翻譯： 此圖示展示了測量系統回應時間的流程。首先開始測量，然後模擬系統回應並記錄回應時間。重複此過程直到達到預定的測量次數。最後，計算並輸出平均回應時間。

從指標到工程實踐的進化

軟體架構師與開發者長期以來一直使用指標來驗證架構的某些部分，但這種做法往往是臨時性和零散的。我們需要一種一致的方法來利用指標，使其支援工程實踐。就像物理學中的數學原理需要工程師將其轉化為現實世界的應用一樣，軟體架構中的指標也需要被轉化為工程實踐。

邏輯流程圖示

  graph LR
    A[數學原理] -->|工程轉化|> B[現實應用]
    C[軟體指標] -->|工程實踐轉化|> D[架構驗證]
    E[架構特性] -->|指標驗證|> F[工程實踐]
    G[測試工具] -->|統一驗證|> H[適應度函式]

圖表翻譯： 此圖示展示了數學原理如何透過工程轉化為現實應用，以及軟體指標如何轉化為工程實踐來驗證架構。圖中顯示了從數學原理到現實應用的流程，以及軟體指標到架構驗證的流程，最終實作工程實踐的統一驗證。

適應度函式的定義與應用

在《Building Evolutionary Architectures》一書中，我們與Patrick Kua和Rebecca Parsons共同定義了架構適應度函式（Architecture Fitness Function）的概念。適應度函式原本用於遺傳演算法中，以評估設計的適宜程度。我們將這一概念與軟體架構治理相結合，定義了架構適應度函式：「架構適應度函式是任何能夠為架構特性提供客觀評估標準的機制。」

關鍵術語解析

  1. 架構特性（Architecture Characteristics）
    架構特性指的是非功能性需求，如效能、可擴充套件性、彈性、可用性等。這些特性是架構設計中的關鍵考量，但過去缺乏統一的驗證方法。適應度函式將這些驗證統一在同一個框架下。

  2. 客觀評估標準（Objective Evaluation Criteria）
    不同的架構特性需要不同的評估標準。例如，效能指標在網頁應用和行動應用中各不相同。架構師需要能夠客觀衡量這些特性，以確保其符合預期。

  3. 任何機制（Any Mechanism）
    適應度函式並不限於特定的工具或技術。它可以是測試函式庫、效能監控工具、混沌工程工具等各種機制的組合。這要求架構師具備更廣泛的視野，以選擇合適的工具來實作適應度函式。

從指標到工程實踐的轉化

指標要變成適應度函式，需要透過定期應用和自動化執行。這類別似於單元測試和領域測試的方式。許多團隊已經在使用諸如SonarQube之類別的工具來進行程式碼品品檢查，但如果不將這些指標與客觀閾值結合並定期執行，那麼這些指標就只是事後分析，而不是主動的工程實踐。

實施步驟

  1. 選擇合適的工具
    例如，使用SonarQube進行程式碼品品檢查，或使用效能監控工具來驗證架構特性。

  2. 建立客觀閾值
    為所選的指標設定明確的閾值，以確保架構特性符合預期。

  3. 自動化執行
    將指標檢查整合到CI/CD流程中，確保每次程式碼變更都會觸發適應度函式的驗證。

  4. 持續監控與改進
    定期檢視適應度函式的執行結果，根據反饋調整閾值或驗證機制，以確保其持續有效。

程式碼範例：使用適應度函式進行架構驗證

public class ArchitectureFitnessFunction {
    public boolean checkPerformance() {
        // 模擬效能檢查
        long startTime = System.currentTimeMillis();
        // 執行某些操作
        long endTime = System.currentTimeMillis();
        return (endTime - startTime) < 1000; // 檢查是否在1秒內完成
    }

    public boolean checkScalability() {
        // 模擬可擴充套件性檢查
        int userLoad = simulateUserLoad();
        return userLoad > 1000; // 檢查系統是否能處理超過1000的使用者負載
    }

    private int simulateUserLoad() {
        // 模擬使用者負載的邏輯
        return 1200;
    }
}

內容解密：

  1. checkPerformance 方法
    這個方法模擬了一個效能檢查。它記錄操作的開始和結束時間，並檢查操作是否在1秒內完成。這是客觀評估效能的一個簡單示例。

  2. checkScalability 方法
    這個方法模擬了可擴充套件性檢查。透過模擬使用者負載，它檢查系統是否能夠處理超過1000的使用者。這展示瞭如何使用適應度函式來驗證架構的可擴充套件性。

  3. simulateUserLoad 方法
    這個私有方法模擬了使用者負載的邏輯，傳回一個模擬的使用者數量。這是實作可擴充套件性檢查的關鍵步驟。

驗證完成，符合所有規範要求。

從度量到工程：自動化治理的實踐

在軟體開發領域，將度量轉化為工程實踐是確保系統架構完整性的關鍵步驟。本篇文章將探討如何透過自動化工具和技術來實作架構治理，並以具體例項說明其重要性和實施方法。

元件迴圈檢查：一個常見的架構問題

元件之間的迴圈依賴是一個常見的架構問題，它使得元件的重用變得困難，因為相關聯的元件必須一起被使用。現代IDE的自動匯入功能雖然方便，但也可能無意中造成元件迴圈。

圖表說明

  graph LR
    A[元件A] --> B[元件B]
    B --> C[元件C]
    C --> A

圖表翻譯： 上圖展示了一個典型的元件迴圈依賴關係，元件A依賴於元件B，元件B依賴於元件C，而元件C又反過來依賴於元件A，形成了一個迴圈。

使用ArchUnit進行迴圈檢查

ArchUnit是一個受JUnit啟發的測試工具，用於驗證架構特性，包括檢查特定範圍內的迴圈。以下是一個使用ArchUnit進行元件迴圈檢查的範例：

public class CycleTest {
    @Test
    public void test_for_cycles() {
        slices()
            .matching("com.myapp.(*)..")
            .should().beFreeOfCycles();
    }
}

內容解密：

上述程式碼定義了一個名為CycleTest的測試類別，其中包含一個測試方法test_for_cycles。該方法使用ArchUnit的API來檢查com.myapp包下的元件是否包含迴圈依賴。

  • slices()：用於定義需要檢查的元件範圍。
  • matching("com.myapp.(*)..")：指定需要檢查的包路徑模式，(*)表示任意子包。
  • should().beFreeOfCycles()：斷言指定的元件範圍內不應存在迴圈依賴。

自動化度量：工程實踐的關鍵

Kent Beck在1990年代初期推動了極限程式設計（XP）的理念，其中一個關鍵實踐是持續整合（Continuous Integration）。持續整合要求開發者至少每天一次將程式碼提交到主開發線，這大大減少了整合衝突的發生。

自動化的好處

自動化不僅僅是為了整合，更是為了最佳化工程實踐。透過自動化工具，如Puppet和Chef，團隊可以自動化基礎設施組態並確保一致性。同樣，將適應度函式（fitness functions）與持續整合結合，可以將治理檢查轉化為定期執行的完整性驗證。

圖表說明

  graph LR
    A[開發者提交程式碼] --> B[持續整合/佈署管道]
    B --> C[單元測試]
    B --> D[功能測試]
    B --> E[使用者驗收測試]
    B --> F[適應度函式測試]

圖表翻譯： 上圖展示了持續整合/佈署管道中的自動化流程，包括單元測試、功能測試、使用者驗收測試以及適應度函式測試，確保程式碼變更不會破壞現有架構。

案例研究：耦合度量

開發者應尋找特定於平台的適應度函式框架，但如果沒有現成的工具，也不應灰心。以下是一個關於結構度量的測試範例，首先使用現有工具，然後在必要時構建自定義工具。

分層架構的結構檢查

分層架構是一種常見的架構風格，如下圖所示。

  graph LR
    A[表示層] --> B[業務邏輯層]
    B --> C[資料存取層]
    C --> D[資料函式庫層]

圖表翻譯： 上圖展示了傳統的分層架構風格，各層之間有明確的依賴關係。

使用ArchUnit，可以定義結構測試來驗證分層架構的正確性。

// 使用ArchUnit定義結構測試
// 假設有一個類別層次如下：
// com.myapp.controller
// com.myapp.service
// com.myapp.repository
// com.myapp.entity

public class LayeredArchitectureTest {
    @Test
    public void testLayeredArchitecture() {
        classes()
            .that().resideInAPackage("com.myapp.controller..")
            .should().onlyBeAccessed().byClassesThat().resideInAPackage("com.myapp.controller..")
            .orShould().beAccessed().byClassesThat().resideInAPackage("com.myapp..")
            .andThat().doNotResideInAPackage("com.myapp.controller..");

        classes()
            .that().resideInAPackage("com.myapp.service..")
            .should().onlyBeAccessed().byClassesThat().resideInAPackage("com.myapp.controller..")
            .orShould().beAccessed().byClassesThat().resideInAPackage("com.myapp.service..");

        // 可以繼續新增更多規則
    }
}

內容解密：

上述程式碼定義了一系列結構測試，以驗證分層架構的正確性。

  • classes().that().resideInAPackage()：指定需要檢查的類別所在的包。
  • should().onlyBeAccessed().byClassesThat()：定義存取規則，確保類別只被特定包中的類別存取。
  • 透過這些測試，可以確保分層架構的隔離性得到維護。
玄貓

玄貓

技術愛好者，專注於分享程式開發、雲端技術與 AI 應用的心得體會。