我目前已经采用了大约15个自动化应用程序，它们都在做类似的事情，但是它们是由不同的人编写的。几乎所有代码都在3年内被复制粘贴。需要创建一个新的自动化，并且由负责该自动化的人复制最新的项目并进行修改。我也有一些新项目正在做类似的事情，并且想避免过去发生的事情。
我正在尝试以某种方式组合相同的功能，并寻求有关最佳方法的想法，以便使这些项目更易于维护和修复错误。首先，我将描述这些自动化程序的工作。它们都是C＃控制台应用程序，它们是在一天中的指定时间在几台计算机上从任务计划程序运行的。但是，当前它们都被移到同一台机器上。理想情况下，我认为我们应该假设它们不会在同一台计算机上。他们可以循环并等待，但是所有人都应该在结束日（当地时间23:59:59）之前完成执行。
它们都从源中检索文件，并将它们复制到工作目录中。该工作目录通常是本地计算机，但并非总是如此。有些通过ftp将源传输到工作目录，一些通过UNC路径，也可能通过其他方式。检索到的源文件采用不同的格式，有时是JSON，XML或CSV。有时需要进行预处理，因为源文件是格式错误的XML或记录不正确的CSV文件，等等。我负责修复或删除不良条目。从这里开始，根据这些文件中的数据类型，我们将数据发送到不同的源以进行更多处理，有时还结合我们自己的内部数据。因此，例如，源文件可能包含地址，但是这种特定的自动化也将需要我们内部数据库中的信息以及位于图像服务器中的文件。
这是每个应用程序中变化最大的部分，但仅限于数据可以进入的6个不同位置（即6种不同的格式输出）。每个目的地具有我们将需要使用的数据格式不同的格式，但是每个当前的自动化应用程序都有不同的处理方式。在将格式化的源发送出去之后，有时我们会将其取回并发送到另一个源。
这可能很复杂。比方说，我们有已预处理的初始数据D0（除去了不良条目，并与内部数据结合在一起），以及2个外部文件进程A，B。我们将A的D0格式化为D1。 D1发送到A，然后我们以其他格式返回D2。 D2必须采用新格式才能由B处理，因此我们为B创建了D3，这使我们得到了D4。然后，D4通常会针对自动化进行一些最终确定。
在对数据进行完全处理之后，我们将文件移至最终位置，并更新数据库中的必要值，生成报告，并将电子邮件发送给需要它们的人。在此过程中，将跟踪错误并将错误写入日志，并在流程的关键部分失败时发送错误电子邮件。
我的直觉告诉我，共享和版本控制的库是完成大多数任务的方法，因此，当我们进行更改或修复时，可以通过更新配置将其部署到每个应用程序中。我的同事对此表示抵触，并希望走网络服务之路，所以我希望在讨论中提出任何要点/对策。
下一部分，我想提出建议的是我们在格式化中使用的不同数据格式。我最初的想法是创建一个大类，其中包含内部数据中的所有数据以及从源中收集的数据，甚至可能包含可以从外部处理返回的数据。称我们的整体式类格式M，以及我们的外部处理输入和输出格式类Ai，Ao，Bi，Bo，...对于每个外部过程，我都必须有一个M-> Ai，Ao-> M。有时我们需要先执行M-> Ai，Ao-> M，然后才能执行M-> Bi，因为进程B依赖于A处理中的数据。不知道最好做M-> Ai-> Ao-> Bi-> Bo-> M，还是M-> Ai-> Ao-> M-> Bi-> Bo-> M。似乎将每种外部过程格式转换为另一种格式可能都是一项不可能的任务，因为它随着其他外部源的增加呈指数增长。我倾向于使用某种系统来跟踪哪些外部过程已应用于M中的整体数据。
谢谢，我希望听到任何建议。
问题没有得到任何关注，所以我将在这里发表自己的发现。我一直在探索.dll组装路线，这似乎是解决这种特殊情况的方法。所有进程/程序都位于一台机器上，因此增加宁静的api或Web服务的复杂性似乎是过大的，尤其是因为我们不需要一台机器之外的互操作性或可伸缩性。
某些功能可能适用于Web服务/ REST API，但是，我们需要在所有应用程序中编写代码以调用所述服务，因此仍然需要.dll组装路径，因此我们无需复制到处都调用服务/ api。因此，此刻，我正在将重复功能写入所有这些程序都将使用的.dll中，如果上级人士想制作Web服务或一个宁静的api，我将能够添加告诉每个应用程序的代码如何在不更改所有应用程序的情况下联系.dll中的api /服务。