从2000年代开始的软件解决方案，我应该尝试修补还是重新制作整个产品吗？

9

我被派去讨论某个公司当前正在使用的系统以及应该如何处理。

该公司生产各种纸箱展示架。开发该系统是为了跟踪客户，订单和价格。自从创建系统以来，发生了很多事情，并且正如经理所描述的那样，系统现在已“ 锁定 ”和“ 有问题 ”，我将其翻译为“非动态”和“不稳定”。

有关系统的一些信息

它是在2000年左右开发的
相当小的系统，2-5个用户，6个表格，〜8个表，平均数据量
建立在早期的Visual Basic上，是通过拖放设计创建的表单。界面基本上只是一个带有菜单和某些形式的窗口
使用MSSQL数据库（SQL2005服务器）存储数据并使用ODBC驱动程序进行查询，在此系统之前，数据是从excel迁移而来，在excel之前，它是用手工和纸来处理，计算和编写的
用户在Microsoft XP环境（及更高版本）中工作

他们的主要问题是他们无法正确地调整和计算价格，无法添加新的纸箱类型等，因为它们无法（或者更确切地说，他们不知道如何）触摸服务器上的数据。

我建议了3种可能的解决方案

尝试修补当前系统
创建一个全新的界面（最好是类似的环境，基于VB.net或VB）
考虑到它是一个很小的系统，请将其重新带到Excel解决方案中

可能还有更多选择，但是这些是我能想到的。

我的问题是

我应该推荐什么，为什么？
这些替代方案的利弊是什么？
还有其他（可能更好）的选择吗？

— ShadowScripter
source

3

在记录了数据库模式之前，您无法确定当前系统的损坏程度。

@ThorbjørnRavnAndersen是的。我只是偷看了数据库。从它的创建年代来看，我将假设它的设计确实非常糟糕，需要急救...或手术。

— ShadowScripter 2012年

1

您知道谁写了原始系统吗？这是内部努力还是被外包了？

— maple_shaft

7

不要那样做告诉客户数据库的状态对于各种选择的成本至关重要，无论选择哪种选择，都应该执行。即使是从头开始重写，他们也很可能希望将其数据移植过来。

4

开发人员喜欢默认为“从头重写”，并且仅在必要时进行重构。我宁愿默认为“逐渐重构”，并且仅在必要时重写。

— quant_dev

5

只有6种形式的东西，应该很容易在更现代的框架上重建。我曾与VB6项目一起迁移，该项目有大约200个表单以及数十个类和数据库表。听起来好像您没有在看任何杂乱无章的东西，但看起来可能在欺骗。

我必须分析代码，数据库和业务需求，以说最好重写或重构现有代码库。鉴于您所说的，我倾向于重写。但是，可能存在您现在看不到的隐患。

— 弗兰克卡尔
source

考虑到它的体积小，我同意。乍一看，似乎也不太复杂。从答案来看，重写似乎是最合适的。不过，在做出最终决定之前，我将仔细研究。感谢您的建议！:)

— ShadowScripter 2012年

@ShadowScripter在您使用它时，我将用比VB更好的语言来编写它。查看开源lazarus项目。

— Spencer Rathbun 2012年

5

到目前为止，大多数回复对我的建议略有不同。

尝试修补当前系统

我至少会足够了解当前的系统，以便向客户解释如何使用它。我将花时间解释他们当前系统中的缺陷，避免使用负面词，只是告诉他们即使所有已知的错误都已修复也不能做什么。

创建一个全新的界面（最好是类似的环境，基于VB.net或VB）

学习完所有内容后，便可以使用其当前设置。向他们提供选项，如果您可以解决他们对当前系统的担忧，那么他们的当前系统确实没有任何问题。当然，唯一需要担心的是Visual Basic 6支持可能在5年之内不存在。

另一个问题是它与数据库通信的方式。微软正在慢慢摆脱一些与其数据库产品进行通信的较旧方法（Access，MSSQL），因此您与这些产品进行交互的方式将决定该解决方案是否可以在Windows 9和Windows 10上使用。

这个答案完全取决于他们是否拥有应用程序本身的来源。如果他们没有资源，那么将很难解决他们的问题，修复当前的主要错误，甚至使其成为可以实际使用的工具。

我不觉得Visual Basic 6应用程序有什么“错误”，除了事实，它对将来版本的支持还未知。即使在使用Windows 7和64位操作系统的今天，其支持也越来越困难。这是在适当的64位支持下重写为现代语言的一个好主意。

如果他们当时没有源，那么重写实际上是他们唯一的解决方案。

— 猎犬
source

您能否引用“ Microsoft is slowly getting rid of some of the older ways to communicate...”？想了解更多有关它的信息。

— ShadowScripter 2012年

@ShadowScripter-例如，如果该进程不是32位进程，则不支持Microsoft.Jet.OLEDB.4.0提供程序以访问旧版Access数据库文件。WinRT可能还会改变我们连接这些Microsoft产品的方式。我忘了在哪里读到关于将来的更改的信息，我的理解是在MSSQL 2012之后，Microsoft也将仅支持特定的连接方式。当然，这是在Windows内置的提供程序及其开发产品的背景下

— Ramhound

1

考虑到系统相对较小，重写接口是一个很好的选择。优点是-

提高稳定性（假设您做得不错！）
改善的可维护性
现代界面

主要的缺点是，与破解现有代码相比，它可能仍会花费更多的钱。

— 克雷格·施瓦兹（Craig Schwarze）
source

重写接口也是我的主要目标。老实说，按照今天的标准来看，我不确定从旧界面开始的地方，真是太糟糕了。

— ShadowScripter 2012年

1

我也倾向于重写，但是您需要100％确保完全了解当前功能以及任何损坏，丢失或不足的功能。正如您提到的调整和计算价格一样，后两者很重要。您是否完全了解添加此功能的后果？

我曾经在所谓的“网站”上工作，但实际上是从1990年代末开始接管了基于Access的自定义CRM样式工具，并将其带入了现代的基于Web的世界。最初的开发人员早已不复存在，数据库已被修改了无数次，因此原始文档已过时，而且没有人真正了解系统的工作方式。但是他们只是知道如何使用它。该项目预算的大约80％用于三件事：

收集要求
了解当前系统
针对他们打算如何使用软件提出有意义的数据库模式

从财务上看，该项目没有成功！

— ZweiBlumen
source

我听到您在说什么：在做出最终决定之前，我需要充分了解其当前的失败，功能和目的。好像我不想全力以赴，拿着枪在燃烧，尖叫All right, let's do this. LEEEEEEEROOOOOOOY...！：P

— ShadowScripter 2012年

0

另一个选择可能是在重写整个内容和破解现有应用程序之间进行折衷。

在从头开始构建的新应用程序中为他们提供新功能。

这可能更容易实现，并且不如完全重写花费那么多。

完成此操作后，他们很高兴可以添加/更新数据，这打开了阶段，第二阶段可能是替换新应用程序中的现有功能。

这可能是更可口的方法。

— zz
source

1

我想这是个好主意，但是如果第二阶段从未发生，则它们最终将得到一个依赖于另一个新应用程序的旧的单独应用程序，从而使他们拥有两个应用程序，并使麻烦倍增。

— ShadowScripter 2012年

0

改写往往有预算用光的趋势。

但是拥有一个现代的应用程序框架可能是一项不错的投资，尤其是如果没人知道旧系统是如何工作的，并且一旦您开始触摸它们就会崩溃。

另外，VB6不利于支持。当您需要在10年内找到专家时，这将是一个很大的问题。

— 编码器
source