DRY不相关但几乎相同的代码

我有一些几乎相同的代码，但是在主变量上使用绝对不同的类型，它们之间没有继承。具体来说，我正在用Roslyn针对C＃和VB.NET编写具有以下类型的分析器：

Microsoft.CodeAnalysis.CSharp.Syntax.AttributeSyntax Microsoft.CodeAnalysis.VisualBasic.Syntax.AttributeSyntax

我想知道是否因为代码在做相同的事情，我应该将其保持为DRY，将其尽可能少地拆分为单独的（但类型除外），还是将它们完全分开，因为这两种方法是不相关，将来的更改可能会迫使一个版本更改，而另一个版本则不能更改（尽管这不太可能）？

编辑：大约一年后，我遇到了同样的问题，罗斯林（Roslyn）团队帮助我解决了这个问题：编写一个采用泛型并具有TAttributeSyntax完成大部分工作的参数的基类。然后，使用最少的需要特定类型的数据编写派生类。

您不进行DRY操作是因为有人将它写在一本很好的书中，而您进行DRY操作则是因为它实际上具有明显的好处。

特别是从这个问题：

如果您重复自己的话，则会造成可维护性问题。如果doStuff1-3都具有类似的结构化代码，而您在一处解决了一个问题，则很容易忘记在其他地方解决该问题。同样，如果您必须添加新的大小写来处理，则可以简单地将不同的参数传递给一个函数，而不必在各处复制粘贴。

但是，聪明的程序员经常将DRY发挥到极致。有时候，为了不重复自己，您必须创建抽象，以至于使您的队友无法遵循这些抽象。有时，两件事的结构只是模糊地相似，但又足够不同。如果doStuff1-4的差异足够大，以至于对其进行重构以免重复您自己，从而使您不得不编写不自然的代码或进行聪明的编码后空翻，从而使您的团队目瞪口呆，那么重复一下自己就可以了。我向后弯下腰，不以不自然的方式重复几次，并对最终产品感到遗憾。

因此，基本上，不要以为“哦，伙计，这段代码非常相似，也许我应该重构以免重复我自己”。认为“不重构重用共同元素使代码，使这个代码库更易于维护或更少的维护？” 然后，选择使其更易于维护的一个。

话虽这么说，给定SRP并只是尝试一般地使用小型，灵活的类，出于这个原因分析代码可能是有意义的，将使用泛型类型（您说它们与类型相同）的行为分解为几部分小班。然后，您会发现其中的某些类实际上完全相同（而不仅仅是大部分相同），然后可以构建一个工具箱以防万一要添加Microsoft.CodeAnalysis.CPlusPlus.Syntax.AttributeSyntax。