当前位置：首页 > 文章列表 > 文章 > 前端 > 改变范式：从过早的重构和虚假的“可重用性”到适应性、可扩展性和可靠性

改变范式：从过早的重构和虚假的“可重用性”到适应性、可扩展性和可靠性

来源：dev.to 2024-12-24 11:43:04 0浏览收藏

本篇文章主要是结合我之前面试的各种经历和实战开发中遇到的问题解决经验整理的，希望这篇《改变范式：从过早的重构和虚假的“可重用性”到适应性、可扩展性和可靠性》对你有很大帮助！欢迎收藏，分享给更多的需要的朋友学习~

在软件世界中，人们普遍痴迷于过早的重构以及对虚假可重用性的追求。开发人员（尤其是刚起步的开发人员）经常被教导“可重用性”是圣杯。但不惜一切代价追求可重用性往往会导致过度设计的解决方案，这些解决方案过于通用、过于僵化，并且与当前项目的具体需求相距甚远。事实上，它可能会导致我们通常所说的“抽象地狱”——除非您完全理解系统的每个部分如何以及为什么被抽象以适应通用接口，否则什么都不会真正起作用。

我们建议进行范式转变：不要沉迷于可重用性，让我们关注适应性、可扩展性和可重写性。

在这种情况下，我们不再尝试预测代码库的未来需求（就像算命先生预测未来一样），而是专注于为今天创建一个坚实、灵活的基础，该基础仍有增长空间和随着未来的展开而发展。

过早的重构困境：虚假的可重用性

过早重构的问题在于，它来自于这样的信念：您编写的所有内容都应该可重用。这似乎是一个崇高的目标。然而，可重用性常常会导致不必要的复杂性和不必要的抽象。以创建适用于所有模型的通用 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 等）中实现它们。这是用于各种适配器的模板。理论上听起来不错，对吧？有一天，如果我们需要连接到新服务或与新存储解决方案集成，我们只需创建另一个子类即可。

但是让我们面对现实：它真的可以重用吗？或者它会变得复杂起来，让你的系统更难维护、理解和扩展吗？您真的在构建可以在真实世界中重复使用的东西，还是只是在猜测未来？

转变：从可重用性到适应性、可扩展性和可重写性

不要追求过早的可重用性，我们建议重点关注适应性和可扩展性。这是什么意思？

适应性：创建一个可以轻松更改或扩展的基础，而无需重写大部分代码。
可扩展性：为新功能留出空间，而无需重构整个架构。
可重写性：允许其他人（或将来的您自己）轻松扩展或重写您的代码，而不用冒破坏所有内容的风险。

这并不是要创建适用于当今每种边缘情况的完美可重用代码。相反，我们专注于构建坚实的基础，您可以随着时间的推移在其上进行构建、添加和修改。关键是灵活性，而不是过早的优化。

旧的“界面”范式：预测未来

在 java（以及许多其他静态类型语言）的旧时代，重点通常是创建接口并使代码“面向未来”。这个想法是提前预测每个场景并围绕它进行设计。

但是，这种方法通常会导致过度设计：为可能永远不会发生的事情进行设计，或者围绕尚未出现的问题构建抽象框架。您实际上正在编写应该是“通用”的代码，而不了解您正在使用的系统的具体需求。

在 java 中，接口用于定义契约。但是，如果我们将这种思维从“定义契约”转变为简单地设定当前的期望呢？对于当前上下文而言，这是一个清晰且可靠的承诺，无需假设未来会发生什么。

一种新的承诺：对未来的自己的承诺

在我们的新方法中，我们不会像一些神秘的算命师那样对应用程序的未来做出承诺。相反，我们为今天制定明确、可靠的承诺，并确保这些承诺可以在需要时轻松扩展和调整。

这样想：我们不是在预测 5 年后世界会是什么样子；而是在预测 5 年后世界会是什么样子。我们确保我们今天编写的代码能够随着世界的变化而发展和适应。这就像为建筑物打下坚实的地基，确保它足够坚固，能够承受任何变化。

我们做出的“承诺”是对适应性和可扩展性的承诺。我们的目标不是预测未来，而是创建工具，让未来的开发人员（或未来的你）能够根据需要轻松添加、修改或扩展功能。

实际示例：扩展和覆盖适配器

让我们回顾一下我们的 baseadapter 和 apiadapter 示例。我们不会创建尝试处理所有情况的超级通用方法，而是专注于使代码适应性强和易于扩展。

这是 apiadapter 的快速重新架构：

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;
    }
}

现在，不再为每种新型适配器创建一个全新的 baseadapter，我们创建了一个可以轻松扩展和适应未来需求的基础。

扩展新 api 端点的示例：

class OrderAdapter extends APIAdapter {
    static baseURL = 'https://api.example.com';
    static endpoint = 'orders';
}

class UserAdapter extends APIAdapter {
    static baseURL = 'https://api.example.com';
    static endpoint = 'users';
}

在这种情况下，如果您需要为一个 api 端点添加特定行为（例如订单的自定义错误处理），您可以覆盖或扩展 apiadapter 以适应您的需求无需重构整个系统即可满足需求。