軟體重構與技術債務管理策略

– 15 分鐘閱讀

軟體系統的長期維護和發展仰賴穩固的程式碼基礎和良好的設計原則。本文將探討如何透過重構和技術債務管理來提升系統的健康度。首先，從移除死程式碼和抽象化實作開始，逐步重構程式碼，並搭配單元測試確保程式碼品質。接著，探討軟體設計原則，如單一職責原則、開放封閉原則等，並說明如何應用於資料科學專案，建立低耦合、高內聚的系統架構。此外，本文也將深入探討技術債務管理的策略，包含技術債務的視覺化、80/20 規則的應用，以及如何降低償還技術債務的成本。最後，將討論系統健康度評估指標，涵蓋可維護性、可擴充套件性、可靠性、安全性和效能等導向，並提供建立系統健康評估指標的步驟，以協助團隊持續提升軟體系統的品質。

第一步：移除死程式碼

首先，我們來移除一些死程式碼。死程式碼是指那些不會被執行的程式碼，通常是因為程式碼的邏輯已經改變，或者某些功能已經被移除。移除死程式碼可以使程式碼更簡潔、更容易維護。

# 移除死程式碼
def prepare_data_and_train_model():
    # ...
    # 移除以下死程式碼
    # model1 = ...
    # model2 = ...
    # ...
    return best_model, X_test, y_test

第二步：抽象化實作

接下來，我們來抽象化實作。抽象化是指將具體的實作細節隱藏起來，暴露出一個簡單的介面。這樣可以使程式碼更模組化、更容易維護。

# 抽象化實作
class ModelTrainer:
    def __init__(self, model):
        self.model = model

    def train(self, X_train, y_train):
        # ...
        return self.model

def prepare_data_and_train_model():
    # ...
    trainer = ModelTrainer(best_model)
    trainer.train(X_train, y_train)
    return best_model, X_test, y_test

第三步：重構迭代

重構迭代是指反覆地重構程式碼，直到它達到我們想要的標準。這個過程涉及到多個步驟，包括測試、重構、測試、重構，直到程式碼達到我們想要的標準。

  flowchart TD
    A[測試] --> B[重構]
    B --> C[測試]
    C --> D[重構]
    D --> E[測試]
    E --> F[完成]

圖表翻譯：

這個流程圖表現了重構迭代的過程。首先，我們進行測試，然後進行重構，接下來又進行測試，然後又進行重構，直到程式碼達到我們想要的標準。

重構程式碼：抽取函式以提高可讀性和可測試性

在進行重構之前，我們先來看看原始的程式碼。這段程式碼負責從姓名欄位中抽取頭銜（如 Mr、Miss、Mrs 等）並將其存入一個新的欄位中。

df['Title'] = df['Name'].str.extract(' ([A-Za-z]+)\.', expand=False)
df['Title'] = df['Title'].replace(['Lady', 'Countess', 'Capt', 'Col',
'Don', 'Dr', 'Major', 'Rev', 'Sir',
'Jonkheer', 'Dona'], 'Rare')
df['Title'] = df['Title'].replace(['Ms', 'Mlle'], 'Miss')
df['Title'] = df['Title'].replace(['Mme'], 'Mrs')

這段程式碼有一個問題：它直接修改了原始的 DataFrame，且邏輯複雜，難以理解和測試。為瞭解決這個問題，我們可以抽取一個函式來封裝這段邏輯。

抽取函式

def extract_title(name):
    title = name.str.extract(' ([A-Za-z]+)\.', expand=False)
    title = title.replace(['Lady', 'Countess', 'Capt', 'Col',
                           'Don', 'Dr', 'Major', 'Rev', 'Sir',
                           'Jonkheer', 'Dona'], 'Rare')
    title = title.replace(['Ms', 'Mlle'], 'Miss')
    title = title.replace(['Mme'], 'Mrs')
    return title

測試函式

為了確保這個函式的正確性，我們可以寫一個測試。

import pandas as pd
from pandas.testing import assert_frame_equal

def test_extract_title():
    df = pd.DataFrame({
        'Name': ['Smith, Mr. Owen Harris ',
                 'Heikkinen, Miss. Laina ',
                 'Allen, Mlle. Maisie',
                 'Allen, Ms. Maisie',
                 'Allen, Mme. Maisie',
                 'Smith, Lady. Owen Harris '],
    })

    expected = pd.DataFrame({
        'Name': ['Smith, Mr. Owen Harris ',
                 'Heikkinen, Miss. Laina ',
                 'Allen, Mlle. Maisie',
                 'Allen, Ms. Maisie',
                 'Allen, Mme. Maisie',
                 'Smith, Lady. Owen Harris '],
        'Title': ['Mr',
                  'Miss',
                  'Miss',
                  'Miss',
                  'Mrs',
                  'Rare']
    })

    result = extract_title(df['Name']).to_frame('Title')
    result['Name'] = df['Name']
    assert_frame_equal(expected, result)

重構後的程式碼

現在，我們可以使用這個函式來抽取頭銜了。

df['Title'] = extract_title(df['Name'])

這樣的重構不僅提高了程式碼的可讀性，也使得它更容易被測試和維護。接下來，我們可以繼續進行其他的重構，例如抽取函式來計算家庭大小和是否孤獨等。

資料前處理與模型訓練的重構

在進行資料科學專案時，保持程式碼的清晰和模組化是非常重要的。這不僅有助於其他開發者理解你的程式碼，也使得維護和擴充程式碼變得更加容易。讓我們來探討一下如何將一個龐大的Jupyter Notebook重構為一個模組化、可測試的Python指令碼。

問題：龐大的Jupyter Notebook

最初，我們可能有一個龐大的Jupyter Notebook，包含了從資料載入、前處理、特徵工程到模型訓練等所有步驟。這種方式雖然方便快速原型設計，但對於大型專案來說，維護和合作都存在挑戰。

解決方案：重構為模組化程式碼

為瞭解決這個問題，我們可以將程式碼重構為多個小的、模組化的函式，每個函式負責一個特定的任務。例如，資料前處理、特徵工程和模型訓練可以分別放在不同的函式中。

步驟1：定義函式

首先，我們定義一個函式 add_is_alone_column，用於新增一列指示乘客是否孤獨（即沒有家庭成員）的欄位。

def add_is_alone_column(df):
    df.loc[df['FamilySize'] == 1, 'IsAlone'] = 1
    df = df.drop(['Parch', 'SibSp', 'FamilySize'], axis=1)
    return df

步驟2：撰寫單元測試

接下來，我們為這個函式撰寫單元測試，以確保它的正確性。

import pandas as pd
from pandas.testing import assert_frame_equal

def test_add_is_alone_column():
    df = pd.DataFrame({
        'SibSp': [0, 1, 2, 0, 0],
        'Parch': [0, 0, 5, 0, 1]
    })
    
    expected = pd.DataFrame({
        'SibSp': [0, 1, 2, 0, 0],
        'Parch': [0, 0, 5, 0, 1],
        'IsAlone': [1, 0, 0, 1, 0]
    })
    
    assert_frame_equal(expected, add_is_alone_column(df))

步驟3：整合函式到主程式

最後，我們將這個函式整合到我們的主程式中，作為資料前處理的一部分。

def prepare_data_and_train_model():
    passengers = pd.read_csv("./input/train.csv")
    passengers = impute_nans(passengers, 
                               categorical_columns=["Embarked"], 
                               continuous_columns=["Fare", "Age"])
    passengers = add_derived_title(passengers)
    passengers = add_is_alone_column(passengers)
    passengers = add_categorical_columns(passengers)
    passengers = passengers.drop(["Parch", "SibSp", "Name", 
                                "PassengerId", "Ticket", "Cabin"], axis=1)
    y = passengers["Survived"]
    # ... 其他模型訓練步驟

軟體設計原則在資料科學中的應用

在進行資料科學專案的開發時，軟體設計原則扮演著重要的角色。這些原則可以幫助我們建立更易於維護、擴充套件和理解的系統。讓我們來探討一下在資料科學中如何應用這些原則。

1. 分離關注點（Separation of Concerns）

分離關注點是一個基本的設計原則，指出系統中的不同方面應該被分離和獨立地處理。這意味著我們應該將系統分成小的、獨立的模組，每個模組只負責一部分的功能。例如，在資料預處理、特徵提取、模型訓練和推理等階段，我們可以將每個階段獨立出來，方便維護和擴充套件。

2. 開放-封閉設計（Open-Closed Principle）

開放-封閉設計原則指出，軟體實體應該對擴充套件開放，但對修改封閉。這意味著我們可以在不修改現有程式碼的情況下擴充套件系統的行為。例如，在我們的資料科學專案中，如果我們需要新增新的資料轉換行為，我們可以建立一個新的模組來處理這個功能，而不需要修改現有的程式碼。

3. 單一職責原則（Single Responsibility Principle）

單一職責原則指出，每個模組或類別應該只有單一的職責或功能。這意味著每個模組或類別應該只負責一件事情，避免過度複雜和耦合。例如，在我們的資料預處理模組中，我們可以建立不同的函式來處理不同的資料轉換任務，每個函式只負責一件事情。

4. 依賴反轉原則（Dependency Inversion Principle）

依賴反轉原則指出，高層模組不應該依賴於低層模組，兩者都應該依賴於抽象。這意味著我們應該使用抽象介面和依賴注入來解耦模組之間的依賴關係。例如，在我們的模型訓練模組中，我們可以使用抽象介面來定義模型的訓練方法，然後使用依賴注入來提供具體的模型實作。

內容解密：

在上面的內容中，我們探討了軟體設計原則在資料科學中的應用。這些原則可以幫助我們建立更好的資料科學專案，提高系統的可擴充套件性和可維護性。透過分離關注點、開放-封閉設計、單一職責原則和依賴反轉原則等設計原則，我們可以建立更易於維護、擴充套件和理解的系統。

圖表翻譯：

  graph LR
    A[分離關注點] --> B[開放-封閉設計]
    B --> C[單一職責原則]
    C --> D[依賴反轉原則]
    D --> E[資料科學專案]
    E --> F[可擴充套件性]
    F --> G[可維護性]

在這個圖表中，我們展示了軟體設計原則在資料科學中的應用。分離關注點、開放-封閉設計、單一職責原則和依賴反轉原則等設計原則可以幫助我們建立更好的資料科學專案，提高系統的可擴充套件性和可維護性。

低耦合、高內聚的機器學習系統設計

在機器學習（ML）系統中，耦合和內聚是兩個非常重要的概念。耦合指的是系統中不同元件之間的相互依賴程度，而內聚則指的是元件內部元素之間的相關程度。高耦合意味著元件之間緊密相連，改變一個元件可能會對其他元件產生重大影響，而高內聚則意味著元件內部元素合作以達到共同目標。

耦合和內聚的重要性

在ML系統中，高耦合可能導致複雜的依賴關係，使得系統難以維護和擴充套件。例如，資料預處理、特徵提取、模型訓練和推理等模組之間的緊密耦合可能會使得系統難以修改和擴充套件。另一方面，高內聚可以使得系統更模組化和易於維護。

實作低耦合、高內聚的設計

要實作低耦合、高內聚的ML系統設計，需要注意以下幾點：

  1. 分離關注點：將不同的功能分離到不同的模組中，例如資料預處理、特徵提取和模型訓練等。
  2. 定義介面：定義明確的介面以便不同模組之間的通訊，減少耦合。
  3. 使用抽象：使用抽象概念來封裝實作細節，減少耦合。
  4. 實作高內聚：確保模組內部元素之間的相關程度高，合作以達到共同目標。

例項：使用抽象封裝實作細節

例如，假設我們有一個ML系統需要處理不同資料來源的資料。為了減少耦合和提高內聚，我們可以定義一個抽象的DataSource類別，封裝不同資料來源的實作細節。然後，其他模組可以透過DataSource介面與資料來源進行通訊，無需關心具體的實作細節。

from abc import ABC, abstractmethod

class DataSource(ABC):
    @abstractmethod
    def read_data(self):
        pass

class CSVDataSource(DataSource):
    def read_data(self):
        # 實作從CSV檔案中讀取資料
        pass

class DatabaseDataSource(DataSource):
    def read_data(self):
        # 實作從資料函式庫中讀取資料
        pass

設計原則與技術債務管理

在軟體開發中，設計原則和技術債務管理是兩個密不可分的概念。設計原則是指在設計軟體系統時應遵循的規則和，以確保系統的可維護性、可擴充套件性和可靠性。技術債務管理則是指在軟體開發過程中，如何管理和控制技術債務的累積和償還。

設計原則

設計原則是指在設計軟體系統時應遵循的規則和。以下是幾個重要的設計原則：

  • 單一責任原則：每個模組或類別應該只有單一的責任和功能。
  • 開放-封閉原則：軟體系統應該對擴充套件開放，但對修改封閉。
  • 里氏替換原則：子類別應該可以替換父類別。
  • 介面隔離原則：不應該強迫客戶依賴它不使用的介面。
  • 依賴反轉原則：高層模組不應該依賴低層模組，兩者都應該依賴抽象。

技術債務管理

技術債務是指在軟體開發過程中，為了快速完成任務而做出的妥協和折衷。技術債務可以是程式碼的壞味道、過度的複雜性、或是設計上的缺陷。技術債務管理是指在軟體開發過程中，如何管理和控制技術債務的累積和償還。

以下是幾個技術債務管理的策略：

  • 識別技術債務：在軟體開發過程中，識別出技術債務的存在和型別。
  • 評估技術債務：評估技術債務的嚴重性和影響。
  • 優先順序排序：根據技術債務的嚴重性和影響，優先順序排序技術債務的償還。
  • 償還技術債務：根據優先順序排序，償還技術債務。

案例研究

在一個機器學習專案中，開發團隊遇到了技術債務的問題。團隊成員們為了快速完成任務，做出了許多妥協和折衷，導致程式碼的壞味道和過度的複雜性。為瞭解決這個問題，團隊成員們識別出了技術債務的存在和型別，評估了技術債務的嚴重性和影響，優先順序排序技術債務的償還，最後根據優先順序排序，償還了技術債務。

圖表翻譯：
  graph LR
    A[設計原則] --> B[技術債務管理]
    B --> C[識別技術債務]
    C --> D[評估技術債務]
    D --> E[優先順序排序]
    E --> F[償還技術債務]

此圖表描述了設計原則和技術債務管理之間的關係，從設計原則到技術債務管理，然後到識別技術債務、評估技術債務、優先順序排序和償還技術債務。

技術債務管理的重要性

技術債務是軟體開發過程中不可避免的問題。有效管理技術債務可以幫助團隊在不犧牲產品品質的情況下交付高品質的軟體。要做到這一點，團隊需要建立一個社會契約，明確規定團隊成員的行為和期望。

技術債務管理技術

以下是一些我們在實際專案中使用的技術債務管理技術：

使債務可見

使債務可見是管理技術債務的第一步。一個有用的資訊輻射器是技術債務的“墻”。將所有債務放在一個地方，可以根據價值和努力程度對其進行分類和排序。這有助於我們看到哪些債務是低垂果（高價值，低努力）、快速贏得（低價值，低努力）、值得投資（高價值，高努力）和不值得投資（低價值，高努力）。

80/20 規則

我們已經看到很多團隊在是否應該花時間重構或支付技術債務上存在爭議。在我們的經驗中，80/20 規則可以幫助。對於每個故事卡，專注 80% 的時間在交付功能和完成故事上，然後花 20% 的時間支付一些技術債務，以便團隊可以繼續以可持續和可預測的速度交付功能。

使其廉價和安全

我們通常在處理技術債務時遇到兩種情況。第一種情況是支付技術債務需要花費大量時間（因為缺乏自動化測試）和令人感到不知所措（因為解決方案太過複雜）。在這種情況下，團隊想要做正確的事情（他們建立“技術債務卡”），但這些卡片通常被放在低優先順序的待辦事項列表中，從不被看到。

# 技術債務管理示例
class TechnicalDebt:
    def __init__(self, name, value, effort):
        self.name = name
        self.value = value
        self.effort = effort

    def __str__(self):
        return f"{self.name}: {self.value} ({self.effort})"

# 建立技術債務列表
technical_debts = [
    TechnicalDebt("低垂果", 10, 2),
    TechnicalDebt("快速贏得", 5, 1),
    TechnicalDebt("值得投資", 15, 10),
    TechnicalDebt("不值得投資", 2, 15)
]

# 將技術債務分類和排序
technical_debts.sort(key=lambda x: (x.value, x.effort))

# 列印技術債務列表
for debt in technical_debts:
    print(debt)

內容解密：

上述程式碼定義了一個 TechnicalDebt 類別，代表技術債務的名稱、價值和努力程度。然後，建立了一個技術債務列表，包含四個技術債務例項。最後，使用 sort 方法根據價值和努力程度對技術債務列表進行排序和分類。

圖表翻譯：

  flowchart TD
    A[技術債務管理] --> B[使債務可見]
    B --> C[80/20 規則]
    C --> D[使其廉價和安全]
    D --> E[技術債務列表]
    E --> F[排序和分類]
    F --> G[列印技術債務列表]

此圖表展示了技術債務管理的流程，從使債務可見到列印技術債務列表。每個步驟都與程式碼中的相應部分相關。

技術債務管理：提升系統健康度

技術債務是軟體開發中常見的問題，可能導致系統效能下降、維護成本增加和開發速度減慢。有效的技術債務管理可以幫助團隊提高系統健康度，提升開發效率和系統穩定性。

技術債務重構的重要性

重構是技術債務管理的一個重要方面。透過重構，團隊可以簡化程式碼、消除冗餘功能和改善系統結構。重構可以幫助團隊提高系統的可維護性、可擴充套件性和可靠性。

技術債務重構的挑戰

技術債務重構可能是一個具有挑戰性的任務，特別是當系統複雜、程式碼基礎龐大時。團隊需要仔細評估重構的風險和收益，確保重構不會導致系統不穩定或功能異常。

技術債務重構的最佳實踐

以下是一些技術債務重構的最佳實踐：

  • 測試覆寫率: 高測試覆寫率可以幫助團隊確保重構不會導致系統功能異常。
  • IDE捷徑: IDE捷徑可以幫助團隊快速重構程式碼，減少手工編輯的時間和錯誤。
  • 重構小步: 重構小步可以幫助團隊逐步重構系統，減少風險和複雜性。

技術債務管理的價值

技術債務管理可以幫助團隊提高系統健康度，提升開發效率和系統穩定性。透過技術債務管理，團隊可以：

  • 減少手工測試時間: 自動化測試可以幫助團隊減少手工測試時間，提高開發效率。
  • 減少生產警示: 技術債務管理可以幫助團隊減少生產警示，提高系統穩定性。
  • 加快交付速度: 技術債務管理可以幫助團隊加快交付速度，提高開發效率。

系統健康度評估

系統健康度評估是一種評估系統健康度的方法，透過評估系統的開發、營運和架構等方面。系統健康度評估可以幫助團隊瞭解系統的健康度，找出需要改善的方面。

系統健康度評估的維度

系統健康度評估的維度包括：

  • 開發: 開發維度評估系統的開發效率、程式碼品質和開發團隊的合作。
  • 營運: 營維運度評估系統的營運效率、系統的可靠性和可用性。
  • 架構: 架構維度評估系統的架構設計、系統的可擴充套件性和可維護性。

系統健康度評估的方法

系統健康度評估的方法包括：

  • RAG評估: RAG評估是一種簡單的評估方法，透過紅、黃、綠三種顏色來評估系統的健康度。
  • 問卷調查: 問卷調查是一種評估方法，透過問卷來評估系統的健康度。

系統健康評估指標

在評估系統的健康程度時，需要考慮多個維度。這些維度包括系統的可維護性、可擴充套件性、可靠性和安全性等。以下是系統健康評估指標的例子：

可維護性

  • 程式碼可讀性和品質評分
  • 開發環境設定自動化程度
  • 自動化測試的存在和覆寫率
  • 持續整合（CI）管道的存在和覆寫率
  • 適當的客戶、使用者和資料保護措施
  • 設計檔案和決策歷史檔案

可擴充套件性

  • 系統的效能和可擴充套件性
  • 系統的容錯和還原能力
  • 系統的安全性和合規性

可靠性

  • 系統的可用性和可靠性
  • 系統的故障率和還原時間
  • 系統的安全性和合規性

安全性

  • 系統的安全性和合規性
  • 系統的漏洞和風險評估
  • 系統的安全更新和補丁管理

效能

  • 系統的效能和效能
  • 系統的資源利用率和最佳化
  • 系統的監控和報警機制

建立系統健康評估指標

為了建立系統健康評估指標，需要與相關的利益相關者（例如技術負責人、架構師、產品經理）合作，共同定義評估指標和目標。以下是建立系統健康評估指標的步驟：

  1. 定義評估維度：定義系統健康評估的維度，例如可維護性、可擴充套件性、可靠性、安全性和效能。
  2. 列舉評估指標：列舉每個維度的評估指標，例如程式碼可讀性、自動化測試的存在和覆寫率等。
  3. 設定目標和路徑：設定每個評估指標的目標和路徑，例如提高程式碼可讀性和自動化測試的覆寫率。
  4. 簡化和演化：簡化評估指標和目標，隨著時間的推移演化和改進。

內容解密：

系統健康評估指標是評估系統健康程度的重要工具。它可以幫助團隊提高系統的可維護性、可擴充套件性、可靠性、安全性和效能。透過建立系統健康評估指標，團隊可以更好地瞭解系統的健康程度，從而採取有效的措施來改進系統的健康程度。

  graph LR
    A[系統健康評估指標] --> B[可維護性]
    A --> C[可擴充套件性]
    A --> D[可靠性]
    A --> E[安全性]
    A --> F[效能]
    B --> G[程式碼可讀性]
    B --> H[自動化測試]
    C --> I[系統效能]
    C --> J[容錯和還原]
    D --> K[系統可用性]
    D --> L[故障率和還原時間]
    E --> M[系統安全性]
    E --> N[漏洞和風險評估]
    F --> O[系統效能]
    F --> P[資源利用率和最佳化]

圖表翻譯：

此圖表展示了系統健康評估指標的框架。系統健康評估指標包括可維護性、可擴充套件性、可靠性、安全性和效能等維度。每個維度都有多個評估指標，例如程式碼可讀性、自動化測試、系統效能、容錯和還原等。透過這個圖表，可以清晰地看到系統健康評估指標的結構和關係。

從技術架構視角來看，本文探討了程式碼重構、設計原則及技術債務管理的重要性，並提供了實踐方法。分析了從移除死程式碼、抽象化實作到重構迭代的過程，也闡述了分離關注點、開放封閉原則等設計原則如何應用於資料科學專案，提升系統的可維護性和可擴充套件性。此外，文章還強調了低耦合、高內聚的機器學習系統設計，以及技術債務管理對系統健康度的重要性，並提供了具體的評估指標和實踐技術。然而，重構和技術債務管理的過程並非一蹴可及，需要團隊持續投入和長期規劃。玄貓認為，技術團隊應將這些原則融入日常開發流程，逐步改善系統架構，才能有效降低技術債務，提升系統的長期健康度，並持續交付高品質的軟體產品。未來，隨著DevOps和自動化測試技術的發展，預計技術債務管理將更加精細化和自動化，進一步提升軟體開發效率和品質。

玄貓

玄貓

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