1

这个问题严格来说是关于需要重建的现有系统的低效架构。它征求有管理此类尴尬系统经验的开发人员的验证。我试图在下面尽可能地抽象它。

该应用程序满足了非常复杂的需求,并且交付得非常好。问题是内部管道使代码管理和可扩展性成为一场噩梦。我可以分享的关于上下文的少量信息包括我们需要将代码视为数据商品这一事实。换句话说,系统只有在持续添加实现的类的情况下才能运行。

应用程序交付给最终用户的不是数据,而是[Action]需要代码执行上下文的。因此,应用程序必须在目标系统上执行一些代码才能交付用户期望的内容。现在这些期望在编译时是未知的,几乎每天都需要添加新的期望。这意味着,开发人员[Actions]会定期向系统添加内容。

[Action]现有系统静态链接到这些类!这不仅使代码管理成为一场噩梦,而且每次添加操作时都需要重新编译。

我的第一直觉是让系统在运行时动态链接到程序集,其中每个程序集都包含一堆动作。这类似于向应用程序添加可扩展性功能。我考虑过 MEF 框架,但感觉不对。

我能想到的唯一选择是将数据库中的每个操作存储为源代码或编译模块。每个都有自己的权衡,例如作为源存储不太安全,但让我可以更好地控制代码审查和持续维护。存储为已编译具有服务器端程序集签名的好处。

对于如何构建这样的系统,我将不胜感激。

4

1 回答 1

1

我认为您不需要更灵活的架构,而是需要更灵活的软件流程。每天添加新功能是大多数开发人员所做的。对于插件系统来说,这不是一个有效的论据。

您不需要插件架构。你需要一个好的软件开发方法,比如敏捷过程(比如 Scrum 和 XP),并确保你能够做到这一点:

  • 让开发人员在分支中构建新组件。
  • 经过全面测试后,将新功能合并到主分支。
  • 这样,主分支始终具有生产质量,您可以使用持续集成和持续交付每天推出新版本。
于 2013-06-07T11:21:44.590 回答