一个(破碎的)遗产框架要保留多少

Question

我继承了一个托管系统(系统"A")，它可以用于管理产品、库存和订单，并可以将这些产品发送给各种第三方。

很简单，A系统不起作用。产品和库存系统是缓慢的，复杂的，有问题的。第三方整合根本不起作用。代码是一个邪恶的，意大利面的混乱，所以修复事情不是简单的。

我的任务是尝试将系统挽救成有用的东西，我最初的计划是重构、重构和重构更多，直到系统运行为止。

然而，我的公司也有一个单独的系统(系统"B")，我们使用它来建立电子商务网站。除其他外，系统"B“还可以管理产品、库存和订单--只是在某些情况下以较小的容量管理。系统"B“也在不断地由一个团队进行工作和更新。

我的新计划是从根本上抛弃系统"A"，并在"B“系统的基础上重新创建它。

由于我的重构最终会完全重组系统"A“，我想我可以通过重新使用另一个现有的框架来节省时间。然而，如果我走这条路，我仍然需要重新编码第三方集成，而系统"A“和系统"B”没有的次要功能。

现在，系统"A“基本上已经失效了--没有人真正使用它，所以如果我选择的话，我有一个稍微延长重写期的自由。

这是一个好主意，还是我应该坚持原计划的重构系统"A"？

Answer 1

很高兴你在开始之前就问了。

根据Joel (一位经验丰富和受人尊敬的软件开发人员以及堆栈交换背后的人之一)的说法，公司最大的“战略错误”是决定从头开始重写代码。

在那篇博文中，Joel指出，编写自己的代码比尝试理解现有的代码基础有趣得多--所以程序员倾向于编写自己的系统而不是重构。这方面的问题是，现有的代码库有大量内置的“知识”。现有的代码几乎可以肯定地处理许多特定的小问题/细节，这些问题/细节绝对是使软件真正有用的关键。当你扔掉一个遗留系统时，你就把所有的知识都扔掉了。取代它可能比你想象的要困难得多，而且耗时也更多。

我个人掉进了这个陷阱。我完全重写了一个复杂的遗留系统，原因与您引用的原因相同(许多bug，混乱的代码，缺少某些功能)。一旦我重新构建了这个系统，我就不得不重新修复原系统中已经修复过的大量问题。使用该软件的非技术人员没有看到我的“干净代码”--他们只是看到了一个新的系统，已经(痛苦地)解决了一些小问题。回想起来，我应该重新考虑一下，而不是重写。

如果代码是错误的--修复错误。如果代码是无序的，组织它。但别把整件事都扔了。

Answer 2

您放弃系统A并根据系统B重写它的计划是可行的，但前提是满足以下几个条件：

• 系统B必须已经提供了系统A所具有的很大一部分功能。否则，您只需要从头开始重写，@akh2103的答案中的警告就适用了。
• 系统B的体系结构很好地为系统添加了扩展。如果不是这样的话，尝试添加System所需的附加功能将像目前的System一样造成很大的混乱。
• 系统B所具有的多余功能(但系统A不需要)和新功能不相互干扰，或者更新后的系统B+有可能部署多个包含整体功能子集的部署。

如果满足这些条件，它可以迁移到同时包含当前系统A和当前系统B的系统。在这样做时，我将尽量使用“复制-重构”循环来向新系统添加System功能，而不是从头重写所有新特性。

Answer 3

你正在做的是考虑以下选项: a)升级到"System B“或b)，维护"System A”。

我们不能给你一个直截了当的答案最重要的通常是最不技术性的，需要与你的经理和财务控制人员进行重要的协商。假设A已部署，且大部分工作正常，则留在A上的成本较低，前期投资较低，持续成本较高。B-低成本的优势被初始成本(通常不是微不足道的)所抵消.

在这种情况下，成本包括企业考虑的所有事情-美元，机会成本，风险，以及税收影响(A可能是所有维护，B，所有资本化为税收目的)。

在这个过程中，你可以，也应该加入‘软’之类的东西，比如“没有人想要工作在粗糙的旧代码上”，“很容易招募开发人员来开发新的、闪亮的东西”，以及“不管我们做什么，A总是有问题的，但是我们可以选择B，让它像你喜欢的那样充满but。”

你应该做些什么来权衡这两种选择，列出相对成本(时间、金钱、风险……)。每一种选择的回报，并对广告做出决定。

在选择“System B”之前，一定要阅读@akh2103的答案，并阅读“第二个系统效应”