，简短的答案，

我希望在这一问题上的主要共识将是尽可能赞成分离。

虽然我绝对同意这一共识的基本意图，但对于(几乎是盲目地)将其作为一项总括性规则的适用程度，我有点不同意。这个答案的其余部分集中在我不同意的部分，因为这部分我也同意你的问题的断言，过度的分离本身也会开始感到肮脏。

话虽如此，我并不反对分离。我只是反对盲目地适用任何笼统的规则。

分离与可重用

首先，我同意你的看法。我不喜欢一遍又一遍地重复同样的事情。我看到许多受人尊敬的同事主张将所有东西分开，但我也看到，我的工作更多地是复制/粘贴，而不是其他任何东西，这就是可重用性的the对立面。当我输入这个时，我正在复制粘贴，添加了一个新特性，我通过复制文件并用Bar替换任何提到的D5，创建了一个完整的企业特性(7个项目，包括单元测试和集成测试)。

不过，我明白为何一般会建议这样做。仅仅因为您现在可能有两个具有相同属性/行为的视图模型，并不意味着这些视图模型将永远保持这种状态。当您到达需要更改其中一个视图模型的程度时，您会注意到已经将所有视图分割开来的好处：

• 如果您已经创建了两个独立的视图模型，则可以简单地调整需要调整的视图模型。
• 如果您还没有创建两个独立的视图模型，那么现在您将不得不花费精力来分离它们，然后您可以开始调整需要调整的视图模型。

随着时间的推移，程序员往往会忘记一些事情，如果您在安装过程中提前几个月将视图模型分开(或者没有)，您可能已经忘记了应用程序结构的某些部分，这意味着当您必须分离视图模型(现在)时，您可能很难确保您没有忘记任何地方的任何东西。

上段显然赞成提前分离，因为这意味着你在设置所有东西时都在执行分离任务，这是你拥有最好的工作知识的时间点(相对于将来你会忘记一些事情)。

对未来变化的押注

这本质上是一种猜测游戏:这些视图模型会随着时间的推移而分离吗？

在任何一种情况下，如果你最终是正确的，你投入了适当的努力。没有争论。但是当你错了的时候，错误的后果是不可比拟的：

• 如果您需要分离视图模型而没有这样做，结果是您必须连接和附加模型，这可能是一个复杂的任务。
• 如果您不需要分离视图模型，但无论如何都是这样做的，结果就是您浪费了一小部分开发时间--复制/粘贴两个文件。

这里的数学很清楚。最好是站在分离的一边，因为错误的后果比你没有分开和错误的时间要少。<#>但是，这是一个重要的问题，但我觉得许多开发人员忘记了：

• 分离一切意味着你为每件事做这件事(100%)，因为这是一种全面的方法。
• 不把所有的东西分开，只在你需要的时候才把它们分开，可以逐案进行(<100%)。

如果你在将来只需要(迟到)分离1%的班级，而不是今天必须(提前)将100%的班级分开，那就意味着数学发生了变化。早分离明显比晚分离快。但是，100早期分离可能不会比1晚分离更快。

更好的选择是使用least开发时间(注意:这里要考虑代码复杂性，因为它会影响未来的开发时间)。这里没有普遍正确的答案。这在很大程度上取决于代码库的复杂性以及您的期望(需要进行未来更改)出错的概率。

结束

对于开发人员来说，偷工减料的先例层出不穷，最终导致了无法维护的代码库混乱。这是一个非常常见的事情，也是为什么良好实践对开发人员的压力如此之大的原因。这也是“亲分离”论点的根源:防止不可维护的混乱和对未来维护的长开发时间。

然而，错误太多也是一个问题，因为它并不直接影响开发人员(这只是增加了开发时间，这是产品所有者而不是产品开发人员的问题)。

答案，就像生活中的所有事物一样，是find的正确平衡。不要盲目地错误地在天平的两边，因为任何一方都会带来问题。相反，查看当前的情况，评估您的选项(考虑到过去的经验)，并选择对开发总时间影响最小的选项(包括未来的维护！)。

不要盲目地应用毛毯规则。在应用规则之前，一定要评估规则对当前上下文的适用性。