我什么时候需要停止使用设计模式？

Question

我的同事们疯了，因为我一直想重写已经有效的代码，因为我想用设计模式替换一些遗留设计。虽然我觉得它有助于改进现有的代码，但我觉得我对此有点偏执，并尝试在任何地方使用它们，甚至用另一种代替一种设计模式。我的一些同事说，只要遗留代码有效，就不要管它。

我什么时候应该停止使用它们？你在哪里画出需要用更好的设计代替的代码和不需要触摸的代码之间的界限？

Answer 1

如果代码正常工作，并且不需要注意 - 请不要花时间/金钱更新它。直到财政上必须这样做。只需确保您的所有新代码都非常出色，并从现在开始慢慢消除此问题。

Answer 2

这是一个启发式的方法：您触摸的代码在没有问题的情况下生产的时间越长，您通过更改它所承担的风险就越大。鉴于此，你能评估你正在做的事情的真正价值吗？你是在改进代码吗？表现更好？更易于维护？您必须量化您所做更改的好处，并将其与重构的风险相平衡。一般来说，无情的重构是一个错误。你应该有一个很好的理由去做，你应该能够量化好处。

想象一下，你的老板带你进入他/她的办公室并问你“为什么在代码没有问题时你做了这个改变？”你会得到一个好的答案吗？

每条评论：我在SO Answer中为质量成本（COQ）和非质量成本（CNQ）提供了一些很好的资源。

Answer 3

通常，Gof4设计模式涉及添加一定程度的间接，以便更改它的任何一方。如果事情不会改变/不需要变得更灵活，那么你就不需要那种间接。如果它已经存在并且正在工作，则无需更改。重定向的级别不是免费的，但在性能和增加的复杂性方面具有成本。如果我没记错的话，GofF的作者自己就指出了这一点。

编辑添加：好的，必须去拿书找到确切的报价。这是在第31页的介绍结束时，至少在我的版本中：

  

不应该应用设计模式   乱射。他们常常实现   灵活性和可变性   引入额外的水平   间接，这可能会使a复杂化   设计和/或花费你一些   性能。设计模式应该   只有在灵活性时才适用   它实际上是需要的。

Answer 4

通过触摸代码，您会产生一旦工作代码停止正常工作的风险。更好地利用您的时间可能是为了确保单元测试涵盖遗留代码。然后，当需要更改代码时，您可以重构任何适当的模式，并确保代码仍然按照设计的方式工作。

Answer 5

当你重构时，你可以看一下重构设计模式，但是如果设计模式已经有效，那么改变代码就没有意义了。

Answer 6

我同意Joel Spolsky rewriting code is almost always a bad idea，除非你对现有代码的错误有什么非常非常具体的认识，它会改进什么改写，以及你可能会失去什么知识< / em>通过重写它。

“重写代码，因为它冒犯了你的敏感性”，严重来说，这是一个非常糟糕的主意。这是对你的时间的一种不好的利用，它有可能破坏你不理解的东西。

您重写的每一行代码都可能（并且根据我的经验，可能）是您要引入代码库的新错误。不要重写代码，除非你有一个现在和令人信服的理由这样做。

Answer 7

如果你是我的同事，我也会发疯。设计模式只是如何解决问题的一般概念。他们不是主在粘土碑上从山顶上下来的话。

Answer 8

我认为你问这个问题非常好，这是DPW（设计模式撤销）的第一步。

听起来你有成瘾的经典迹象，现在是时候退后一步来检查你的编码生活了，问问题，这是否会影响我的同事？我的公司因为我的习惯而受苦吗？

经过反思和检验，也许您可​​以找到一种方法来缓和您的设计模式使用，并用健康的模式取代破坏性模式，为您和您的编码团队带来好处。

一些有用的提问线可能是，你是否因为昨晚读到一个新的设计模式，或者因为你认为它可能为项目增加真正的价值而使用设计模式？由于您的强烈愿望，您是否在代码上强制设计模式，还是因为模式的真正有用性已经出现？代码是否已经运行良好，不会很快更新？如果是这样，可能有更好的地方可以花时间。

最后，你可以尝试完全放手，看看你编写的代码中出现了什么样的自然“模式”，而不是试图强迫代码适应你的想法。你可以用这种方式发现自己的“模式”。

祝你好运，我想我们中的许多人都曾以这种或那种方式存在过，记得如果你复发，你总是有SO（和常识）的支持网络。

Answer 9

不要强制重新设计 - 只需要重构代码，特别是如果代码已经正常工作。你改变的越多，你就必须测试的越多。如果没有现有测试，这意味着（在一个完美的世界中，无论如何）你必须编写测试。

相反，专注于以小块清理代码，只做必须做的事情。当你去的时候，为你触摸的类编写或更新单元测试，以确保一切都能继续正常工作。

Answer 10

对于个人项目，请自己解决。

对于perfessional工作，停止它！你在浪费资源，你可能正在完成所要求的功能。 alos，你确定在更改它时100％翻译旧代码。如果没有，你就是在制造问题，也可能是新的错误。

Answer 11

Joel Spolsky在his blog上非常聪明地讨论了这个问题。

基本上，代码越旧，它就越有可能经过彻底的测试和调试;即使它充满了奇怪的修复和你认为很糟糕的事情，它们很可能是有充分理由的。因此，无论设计多么冒犯你，都要避免重写代码，除非代码明确地被破坏。

Answer 12

不需要时不要过度工程。但是，花一些时间让我自己学习。

问自己什么时候需要才能使用特定的设计模式。如果不是这样的话，请不要。在遗留系统上使用设计模式的一个很好的理由是在重构期间。

Answer 13

我选择“钱”方法。重写现有代码会花费您的雇主钱（您的工资等）。你能否诚实地说你的重写会使你的雇主损失的费用低于离开它的方式？根据我的经验，答案几乎总是“不”。

我遇到了不止一些人，他们量化成本的能力很差，没有给予任何理性的考虑，或者更关心他们提出薪水的直接愿望，而不是为雇主提供良好的价值。我个人已经发现好的雇主会认识到你在帮助他们，并会随着时间的推移而相信你的判断。

Answer 14

大多数程序员在某个地方都有一个客户，他实际上是在支付程序员的工资。

当你想要做出这样的改变时，问问自己，“如果我让顾客了解所涉及的问题，他会要我花时间在这上面吗？”。通常情况下，答案是否定的。为什么他们会关心它是否有效？

Answer 15

如果您没有客户，我不同意所有人的意见。 重新设计，批评和改进代码是让你变得更好的原因。 如果你永远不想回顾你所做的事情，那么你就不会改进，你需要批评自己。 即使稍后您发现重新设计是个坏主意，您也会了解原因。

Answer 16

我经常发现自己使用“总是将一段代码留在比你发现它更好的状态”原则。

因此，如果我加载一些类并注意它可以在我开始执行更改请求之前使用一点弹簧清理，那么我将首先执行此操作。这还有另一个优点，它可以为您提供双倍的阅读和理解代码及其依赖性等方法。

我发现执行更改请求更简单，因为您更了解代码。

然后在这一切结束时，你拥有两全其美......一个快乐的客户和一个更快乐的代码库。

Answer 17

交易不同的设计模式以获取无利可图是一个失败的主张。在设计应用程序时，请使用您认为合适的设计模式并坚持使用它，除非有明显的理由来更改模式。我建议听你的同事一个人离开这个应用程序。

Answer 18

我不认为“如果没有破产，就不要修理它”是对的。我认为你一定要注意可以重构的代码，以便以切实的方式使其更好。问题是 - 确保你做的事情将来会有所帮助，而它所帮助的部分是具体的。

在设计模式术语中 - 设计模式可以帮助您在面对变化时使代码更加健壮 - 它允许代码的某些部分独立于其他部分而变化。想一想是否有一个特定的理由来改变某些东西 - 你是否预计未来会对需要触及很多其他子系统的代码片段进行更改？

如果您明确说明您正在解决的问题，并且您能够说服自己和您的同事这个​​问题值得修复（即未来的好处是显而易见的），那么您应该能够继续前进。