在軟件工程的實(shí)際操作中，我常常遇到這樣一種現(xiàn)象：本可以用簡(jiǎn)單代碼解決的問題，卻因?yàn)樵O(shè)計(jì)者過分關(guān)注“通用性”、“可維護(hù)性”和“可擴(kuò)展性”而變得不必要地復(fù)雜，難以理解。

他們的思維方式是這樣的：“這段代碼未來可能會(huì)在更多場(chǎng)景中使用，所以我現(xiàn)在應(yīng)該考慮它的可擴(kuò)展性?！苯Y(jié)果，他們?cè)诖a中加入了各種“框架結(jié)構(gòu)”，以便在未來有新需求時(shí)，無需修改就能在新的地方使用。

“通用性”的價(jià)值與誤區(qū)

作者并不否認(rèn)“通用性”的價(jià)值，我的一些程序也具有很高的通用性。然而，很多人所謂的“通用性”實(shí)際上適得其反，這種現(xiàn)象通常被稱為 “過度設(shè)計(jì)” 。關(guān)于過度設(shè)計(jì)，有一個(gè)有趣的故事：

傳說在上世紀(jì)60年代美國(guó)和俄羅斯的“太空競(jìng)賽”期間，NASA 遇到了一個(gè)嚴(yán)重的技術(shù)問題：宇航員需要一支能在外太空真空環(huán)境中書寫的筆。最終，NASA 花費(fèi)了150萬美元開發(fā)了這樣一支筆。不幸的是，這種筆在市場(chǎng)上并不暢銷。

俄羅斯人也面臨同樣的問題，他們則用了鉛筆。

雖然這個(gè)故事是虛構(gòu)的，但它具備了伊索寓言的力量?，F(xiàn)在讓我們看看軟件行業(yè)，可能會(huì)發(fā)現(xiàn)：

代碼需要“重用”的場(chǎng)合比您想象的要少得多。

許多人在寫程序時(shí)，連“當(dāng)前異?！倍继幚聿缓茫瑓s關(guān)注“未來的需求”。他們總是想象別人會(huì)重用這段代碼。然而，實(shí)際上，由于設(shè)計(jì)過于復(fù)雜，理解這些設(shè)計(jì)所需的心智努力已經(jīng)超過了從頭開始的成本。因此，大多數(shù)人根本不會(huì)使用他們的代碼，而是重新寫一個(gè)。有些人最終會(huì)發(fā)現(xiàn)自己甚至看不下去之前寫的代碼，更愿意刪除它并重新開始，而不是談?wù)撝赜谩?/p>

我們用一個(gè)簡(jiǎn)單的例子來說明這一點(diǎn)。假設(shè)我們需要寫一個(gè)簡(jiǎn)單的程序來計(jì)算兩個(gè)整數(shù)的和：

def add(a, b):
    return a + b

result = add(3, 5)
print(result)  # 輸出 8

這個(gè)函數(shù)非常直觀，可以很好地滿足當(dāng)前需求。然而，一些程序員可能會(huì)考慮未來可能需要更多的計(jì)算能力，因此設(shè)計(jì)了一個(gè)復(fù)雜的框架：

class Operation:
    def execute(self, a, b):
        raise NotImplementedError

class AddOperation(Operation):
    def execute(self, a, b):
        return a + b

class OperationFactory:
    @staticmethod
    def get_operation(op_type):
        if op_type == 'add':
            return AddOperation()
        # 可以添加更多操作類型。
        raise ValueError("不支持的操作類型")

operation = OperationFactory.get_operation('add')
result = operation.execute(3, 5)
print(result)  # 輸出 8

雖然這個(gè)設(shè)計(jì)提供了可擴(kuò)展性，但在當(dāng)前只需計(jì)算兩個(gè)整數(shù)和的場(chǎng)景中，這個(gè)設(shè)計(jì)無疑增加了代碼的復(fù)雜性和理解成本。

實(shí)際修改代碼所需的工作量比你想象的少

還有一種情況是，這些設(shè)計(jì)為“共享”而寫的代碼在很多地方并沒有被使用，因此即使你完全手動(dòng)修改它們，也不會(huì)花費(fèi)很多時(shí)間?，F(xiàn)在，隨著 IDE 技術(shù)的發(fā)展和各種高級(jí)重構(gòu)工具的出現(xiàn)，批量代碼修改不再特別麻煩。過去需要在邏輯層面設(shè)計(jì)可維護(hù)性，現(xiàn)在只需在 IDE 中點(diǎn)擊幾下就能輕松完成。因此，在考慮設(shè)計(jì)框架之前，你還應(yīng)該考慮這些因素。

例如，在上面提到的復(fù)雜設(shè)計(jì)中，如果我們需要修改加法操作，我們需要修改多個(gè)類和文件。在這種情況下，我們可能會(huì)發(fā)現(xiàn)簡(jiǎn)單的函數(shù)實(shí)現(xiàn)更容易維護(hù)和修改。

“考慮”通用性并不意味著你已經(jīng)準(zhǔn)確“掌握”了通用性

許多人考慮通用性，但他們并不準(zhǔn)確地看到未來可能需要修改的部分，因此他們的設(shè)計(jì)往往錯(cuò)失重點(diǎn)。當(dāng)新需求出現(xiàn)時(shí)，發(fā)現(xiàn)最初認(rèn)為可能變化的部分并沒有變化，而那些認(rèn)為不變的部分卻發(fā)生了變化。

能夠準(zhǔn)確預(yù)測(cè)未來需求并從代碼中抽象出真正通用的框架是非常困難的任務(wù)。它不僅需要編程技能，還需要強(qiáng)大的觀察現(xiàn)實(shí)世界事物的能力。許多人設(shè)計(jì)的框架只是復(fù)制他人的經(jīng)驗(yàn)，無法適應(yīng)實(shí)際需求。Java 世界中的許多設(shè)計(jì)模式就是由這些半吊子的人創(chuàng)造的。

例如，假設(shè)我們需要添加一個(gè)新的操作，如減法。如果我們沒有準(zhǔn)確掌握哪些部分需要通用設(shè)計(jì)，我們可能會(huì)發(fā)現(xiàn)現(xiàn)有框架不適用于新需求：

class SubtractOperation(Operation):
    def execute(self, a, b):
        return a - b

operation = OperationFactory.get_operation('subtract')
result = operation.execute(10, 3)
print(result)  # 輸出 7

在這里，我們需要修改 OperationFactory 類以支持減法操作。這表明，雖然我們考慮了通用性，但我們沒有準(zhǔn)確掌握未來的需求，導(dǎo)致框架的靈活性有限。

初始設(shè)計(jì)的復(fù)雜性

如果在初始設(shè)計(jì)中過早地考慮未來需求，可能會(huì)導(dǎo)致不必要的復(fù)雜性和問題。因此，這種對(duì)未來變化的考慮阻礙了進(jìn)展。原本如果我們專注于解決當(dāng)前問題，可以取得很好的結(jié)果。然而，由于“通用性”帶來的復(fù)雜性，設(shè)計(jì)者每次都要多費(fèi)一些心思，無法創(chuàng)建優(yōu)雅的程序。

例如，在上面提到的復(fù)雜設(shè)計(jì)中，如果我們只需要一個(gè)簡(jiǎn)單的加法操作，復(fù)雜的框架反而使初始設(shè)計(jì)變得臃腫且難以理解：

class Operation:
    def execute(self, a, b):
        raise NotImplementedError

class AddOperation(Operation):
    def execute(self, a, b):
        return a + b

class OperationFactory:
    @staticmethod
    def get_operation(op_type):
        if op_type == 'add':
            return AddOperation()
        raise ValueError("不支持的操作類型")

# 初始設(shè)計(jì)的復(fù)雜性。
operation = OperationFactory.get_operation('add')
result = operation.execute(3, 5)
print(result)  # 輸出 8

相比之下，只需執(zhí)行一個(gè)簡(jiǎn)單的函數(shù)即可。

def add(a, b):
    return a + b

result = add(3, 5)
print(result)  # 輸出 8

理解和維護(hù)框架代碼的開銷

如果你設(shè)計(jì)了一個(gè)框架式的代碼，每個(gè)程序員都需要理解這個(gè)框架的構(gòu)建，才能在這個(gè)框架下編寫代碼，這帶來了學(xué)習(xí)成本。一旦發(fā)現(xiàn)這個(gè)框架有設(shè)計(jì)問題，依賴它的代碼可能需要修改，這帶來了修改成本。因此，在設(shè)計(jì)中加入“通用性”的初衷是為了節(jié)省未來的修改成本，但可能會(huì)增加當(dāng)前的開發(fā)和維護(hù)成本。

例如，在復(fù)雜的框架設(shè)計(jì)中，添加新操作類型需要理解多個(gè)類及其關(guān)系：

class MultiplyOperation(Operation):
    def execute(self, a, b):
        return a * b

# 理解和維護(hù)的成本。
operation = OperationFactory.get_operation('multiply')
result = operation.execute(3, 5)
print(result)  # 輸出 15

而在簡(jiǎn)單的函數(shù)實(shí)現(xiàn)中，添加新功能相對(duì)簡(jiǎn)單：

def multiply(a, b):
    return a * b

result = multiply(3, 5)
print(result)  # 輸出 15

結(jié)論

在軟件工程中，設(shè)計(jì)的“通用性”確實(shí)是一個(gè)重要的考慮因素，但我們必須謹(jǐn)慎。過度設(shè)計(jì)和過度工程不僅不會(huì)提高代碼的可維護(hù)性，反而會(huì)增加開發(fā)和維護(hù)成本。在實(shí)際項(xiàng)目中，我們應(yīng)該根據(jù)當(dāng)前需求采用最簡(jiǎn)單直接的解決方案，而不是為了未來的可能性增加當(dāng)前的復(fù)雜性。

總的來說，簡(jiǎn)潔直觀的代碼往往比復(fù)雜的框架更能滿足實(shí)際需求。我們應(yīng)在設(shè)計(jì)中保持平衡，避免過度工程，專注于解決當(dāng)前問題，同時(shí)為未來擴(kuò)展留有余地。