从一个开源项目看如何更好地进行设计重构

关注我，每天收获一个新技能!

一个名为 Bugzilla 的项目将其所有数据存储在数据库中。Bugzilla 仅支持一种特定的数据库系统来存储数据，名为 OldDB。

一些新客户希望使用不同的数据库系统来存储数据，名为 NewDB。这些客户有充分的理由希望使用这个特性：他们比 OldDB 更了解 NewDB，并且已经在他们的公司中运行了 NewDB。但所有现有客户都希望继续使用 OldDB。

因此，Bugzilla 必须开始支持多种数据库。

这将需要大量的代码更改，因为 Bugzilla 没有用于存储和接收来自数据库的信息的任何集中代码。相反，代码中有大量针对 OldDB 特定且在 NewDB 上不起作用的定制数据库命令。

一个选择是在整个代码库中散布 if 语句，为 NewDB 和 OldDB 编写不同的代码来访问数据库。然而，这将大致使整个代码库的复杂性翻倍。

如果系统的复杂性翻倍，他们将无法再维护它，因为 Bugzilla 团队只由几名兼职程序员组成。

尽管如些，Bugzilla 团队决定重新设计系统，使其可以轻松支持多个数据库。

这对这些兼职程序员来说，是一个巨大的工程。

以下是他们的最高层级的任务分解概述：

1. 修改所有可以使用标准数据库命令的代码。存在一些标准数据库命令，可以在任何数据库系统上工作，但它们并不总是被使用。逐个修复系统文件，尽可能在可以使用标准命令的地方进行更改。

2. 对于没有标准版本的数据库命令，创建函数，这些函数将返回正在使用的数据库的正确命令。为一个非标准命令创建一个函数，然后将所有该非标准命令的实例替换为函数调用。继续这个过程，直到所有非标准函数都被移除。

3. 逐个修改依赖 OldDB 功能的设计，停止使用它们，改成标准功能。许多代码片段完全围绕仅存在于 OldDB 中的功能设计。停止使用那些特定于 OldDB 的功能，而改用可以在所有数据库系统上工作的标准功能。必要时，逐个修复这些功能，如果需要，可以分多个步骤进行。

4. 重新设计 Bugzilla 的安装系统，使其可以在任何数据库系统上设置，而不仅仅是 OldDB。这涉及到首先将安装系统重新设计得更简单，然后调整该简化的代码以支持 OldDB 和 NewDB。

上面的每个步骤本身都是一个项目。它们都被细分为更小的步骤，以便可以在每个工作片段上进行良好的设计。

此外，在进行任何更改后都会测试系统，以确保它在 OldDB 上的运行方式与之前相同。

这是否产生了一个完美的系统？不。但它确实产生了一个比以前更好的系统——除了支持 NewDB 之外，代码现在更容易维护。最终，Bugzilla 扩展到支持四种不同的数据库系统，这一切都是因为这项工作使支持新的数据库变得更加容易。

• 将一个大任务分解成多个小任务。
  
• 分解小任务是为了让系统有更良好的设计。
• 每个小任务都是一个小工程。
• 每个小工程结束，都要确保系统仍旧能良好运行。