什么时候不重用软件？

Question

我正在开发一个在第一个版本中对身份验证有基本要求的应用程序(例如，单一管理员登录)，现在我需要对其进行扩展以允许不同的用户、角色和权限。

有人建议我尝试与我们现有的一个产品集成，该产品可以作为一个单独的服务器进行基本身份验证，或者扩展到第二个因素身份验证。我正在处理的应用程序是一个小型的、可下载的应用程序，应该是易于设置和运行的。另一个产品是大型和‘企业级’的，需要手动设置，我可以尝试自动完成我所需要的(也许)。

最大的问题是，当描述为我们在产品中想要做的功能集时，它与其他产品的功能映射得非常完美，但它不是我可以使用的一种形式。管理层希望与其他产品集成，因为我们可以利用这一点似乎很直观，但另一个产品不是我可以使用的形式。也就是说，从MVC的角度来看，我认为没有办法将视图与模型分开。

我关心的另一件事，过去发生过的事情是，如果我被要求集成，我将是做所有集成工作的人，如果其他产品做不到什么，那么我就是运气不好。与我的产品集成比其他团队想要的任何东西都次要，而且我的团队不是“客户”，所以没有什么动机让他们为我们修复或添加东西。

因此，总之，我的问题是:我不想重新发明轮子，但我是否应该尝试使用一种能满足我需要的产品，而不是一种易于重用的产品，从而迫使正方形钉进入圆孔？

编辑:我使用Java，所以Security是一个选项。

Answer 1

如果代码不是为预先重用而编写的，那么您必须重新构建它/重构它，这样它才能实现。这样做将危及现有平台的稳定性。管理层总是想要“重用”，因为他们认为这意味着更少的时间。但是他们没有看过代码，也不知道细节，而且这个假设并不总是正确的。这取决于你解释原因。

您没有提到您正在使用的平台，但是已经有了主要MVC平台的安全解决方案。例如，java具有spring安全性。为什么不使用为您的平台构建的框架，其中作者主要关注的是可重用性。然后你就不用再发明一个轮子了，你也不必担心你现有的代码库的去a。

Answer 2

人们似乎常常觉得他们有两种选择。

1. 从头开始/重新发明轮子。
2. 通过使用包装器或对现有框架进行结构更改来调整不适合这种情况的软件。

然而，还有第三种选择。

1. 使用旧的软件作为基础，创建一个新的框架。重用任何适合新框架设计的算法、方法，还有什么。通常，您可以以这种方式节省大约50%的代码，但是仍然有一个新的框架来满足您的需要。

现在，您是选择2还是3取决于您想要将它们一起维护还是单独维护。如果一个包装器可以很容易地制作，并且唯一的软件将被继续维护。那可能是最好的选择了。

Answer 3

你知道，通过使用适配器，你总是可以把一个方钉很好地塞进圆孔里。为什么不将另一个模块隐藏在适合您需要的接口后面呢？如果这是可能的话，只有很少有人反对集成软件。

为了报告的目的，我曾经不得不将没有COM-Interop的Microsoft集成到现有的应用程序中。我必须将TCP服务器集成到Access-Project中，并将Access Windows强制应用到我的应用程序中。我写这篇文章的时候有一种不好的预感。看起来像一团易碎的烂摊子。但事实并非如此。

我把所有的东西都隐藏在界面后面，最终它工作得很好，用户很高兴，而且使用起来也很容易。由于有了接口，当时机成熟时，访问就可以被交换成更好的东西。