改變範式：從過早的重構和虛假的「可重用性」到適應性、可擴展性和可靠性

在軟體世界中，人們普遍沉迷於過早的重構以及對虛假可重用性的追求。開發人員（尤其是剛起步的開發人員）經常被教導「可重用性」是聖杯。但不惜一切代價追求可重複使用性往往會導致過度設計的解決方案，這些解決方案過於通用、過於僵化，並且與當前專案的具體需求相距甚遠。事實上，它可能會導致我們通常所說的“抽像地獄”——除非您完全理解系統的每個部分如何以及為什麼被抽像以適應通用接口，否則什麼都不會真正起作用。

我們建議進行範式轉移：不要沉迷於可重用性，讓我們專注於適應性、可擴展性和可重寫性。

在這種情況下，我們不再試圖預測程式碼庫的未來需求（就像算命先生預測未來一樣），而是專注於為今天創建一個堅實、靈活的基礎，該基礎仍有成長空間和隨著未來的展開而發展。

---

過早的重構困境：虛假的可重複使用性

過早重構的問題在於，它來自於這樣的信念：您所寫的所有內容都應該可重複使用。這似乎是一個崇高的目標。然而，可重複使用性常常會導致不必要的複雜性和不必要的抽象。以建立適用於所有模型的通用 API 適配器的概念為例。理想情況是該適配器可以處理任何 API 端點、任何資料格式和任何網路條件。但實際上，這意味著您正在為不確定的未來建立框架，而不是有效解決今天的問題。

範例：

讓我們來看看之前的 BaseAdapter 和 APIAdapter 類別：

export class BaseAdapter {
    constructor(modelClass) {
        this.modelClass = modelClass;
    }

    async get(id) {
        throw new Error("Method 'get' must be implemented.");
    }

    async *all() {
        throw new Error("Method 'all' must be implemented.");
    }

    async query(params = {}) {
        throw new Error("Method 'query' must be implemented.");
    }

    async create(payload) {
        throw new Error("Method 'create' must be implemented.");
    }

    async update(payload) {
        throw new Error("Method 'update' must be implemented.");
    }

    async delete(id) {
        throw new Error("Method 'delete' must be implemented.");
    }
}

在上面的程式碼中，BaseAdapter 定義了所有可能的方法，讓我們在特定的子類別（如 APIAdapter、LocalStorageAdapter 等）中實作它們。這是用於各種適配器的模板。理論上聽起來不錯，對吧？有一天，如果我們需要連接到新服務或與新儲存解決方案集成，我們只需創建另一個子類別即可。

但是讓我們面對現實：它真的可以重複使用嗎？ 或者它會變得非常複雜，使您的系統更難以維護、理解和擴展？您真的在建立可以在真實世界中重複使用的東西，還是只是在猜測未來？

---

轉變：從可重用性到適應性、可擴展性和可重寫性

不要追求過早的可重複使用性，我們建議專注於適應性和可擴展性。這是什麼意思？

1. 適應性：建立一個可以輕鬆更改或擴展的基礎，而無需重寫大部分程式碼。
2. 可擴充性：為新功能留出空間，而無需重構整個架構。
3. 可重寫性：允許其他人（或將來的自己）輕鬆擴展或重寫您的程式碼，而不用冒破壞所有內容的風險。

這並不是要創建適用於當今每種邊緣情況的完美可重複使用程式碼。相反，我們專注於構建堅實的基礎，您可以隨著時間的推移在其上進行構建、添加和修改。關鍵是靈活性，而不是過早的最佳化。

---

舊的「介面」範式：預測未來

在 Java（以及許多其他靜態類型語言）的舊時代，重點通常是創建介面並使程式碼「面向未來」。這個想法是提前預測每個場景並圍繞它進行設計。

但是，這種方法通常會導致過度設計：為可能永遠不會發生的事情進行設計，或圍繞尚未出現的問題建立抽象框架。您實際上正在編寫應該是“通用”的程式碼，而不了解您正在使用的系統的特定需求。

在 Java 中，介面用來定義契約。但是，如果我們將這種思維從「定義契約」轉變為簡單地設定當前的期望呢？對於當前上下文而言，這是一個清晰且可靠的承諾，無需假設未來會發生什麼。

---

一種新的承諾：對未來的自己的承諾

在我們的新方法中，我們不會像一些神秘的算命師那樣對應用程式的未來做出承諾。相反，我們為今天制定明確、可靠的承諾，並確保這些承諾可以在需要時輕鬆擴展和調整。

這樣想：我們不是在預測 5 年後世界會是什麼樣子；而是在預測 5 年後世界會是什麼樣子。我們確保我們今天編寫的程式碼能夠隨著世界的變化而發展和適應。這就像為建築物打下堅實的地基，確保它足夠堅固，能夠承受任何變化。

我們所做的「承諾」是對適應性和可擴展性的承諾。我們的目標不是預測未來，而是創建工具，讓未來的開發人員（或未來的你）能夠根據需要輕鬆添加、修改或擴展功能。

---

實際範例：擴充和覆蓋適配器

讓我們回顧一下我們的 BaseAdapter 和 APIAdapter 範例。我們不會建立嘗試處理所有情況的超級通用方法，而是專注於使程式碼適應性強和易於擴充。

這是 APIAdapter 的快速重新架構：

export class BaseAdapter {
    constructor(modelClass) {
        this.modelClass = modelClass;
    }

    async get(id) {
        throw new Error("Method 'get' must be implemented.");
    }

    async *all() {
        throw new Error("Method 'all' must be implemented.");
    }

    async query(params = {}) {
        throw new Error("Method 'query' must be implemented.");
    }

    async create(payload) {
        throw new Error("Method 'create' must be implemented.");
    }

    async update(payload) {
        throw new Error("Method 'update' must be implemented.");
    }

    async delete(id) {
        throw new Error("Method 'delete' must be implemented.");
    }
}

現在，不再為每種新型適配器創建一個全新的 BaseAdapter，我們創建了一個可以輕鬆擴展和適應未來需求的基礎。

擴充新 API 端點的範例：

export class APIAdapter extends BaseAdapter {
    static baseURL;
    static headers;
    static endpoint;

    async *all(params = {}) {
        // Custom logic, but easily extensible if needed
        const url = `${this.baseURL}/${this.endpoint}`;
        const response = await API.get(url, { params, headers: this.headers });
        return response.data;
    }

    async query(params = {}) {
        // Simplified for illustration
        const url = `${this.baseURL}/${this.endpoint}/search`;
        const response = await API.get(url, { params });
        return response.data;
    }

    // Easily extendable for specific cases
    async customRequest(method, endpoint, params = {}) {
        const url = `${this.baseURL}/${endpoint}`;
        const response = await API[method](url, { params });
        return response.data;
    }
}

在這種情況下，如果您需要為一個API 端點添加特定行為（例如訂單的自訂錯誤處理），您可以覆蓋或擴充 APIAdapter 以適應您的需求無需重構整個系統即可滿足需求。

---

結論：對未來的自己的承諾

在這個新典範中，我們並沒有試圖預測未來的每一個需求或問題。相反，我們專注於建立一個強大、靈活的基礎，隨著需求的變化和新挑戰的出現適應。我們不會根據假設的問題過早地抽象化或過度設計解決方案。相反，我們創建工具，這些工具可以隨著新需求的出現而不斷發展並輕鬆適應。

關鍵不是像算命先生一樣面向未來，而是創建一個能夠可靠地經受時間考驗的基礎，即使世界發生變化。這是您可以對未來的自己做出的承諾：程式碼是可靠的、適應性強的，並且可以隨著新需求的出現而擴展。

以上是改變範式：從過早的重構和虛假的「可重用性」到適應性、可擴展性和可靠性的詳細內容。更多資訊請關注PHP中文網其他相關文章！