我的同事们都快疯了，因为我一直想重写已经有效的代码，因为我想用设计模式替换一些遗留设计。虽然我觉得它有助于改进现有代码，但我确实觉得我对它有点偏执，并尝试在任何地方使用它们，甚至用另一种设计模式替换一种设计模式。我的一些同事说，只要遗留代码有效，就不要管它。
我什么时候应该停止使用它们？您在需要被更好的设计替换的代码和不需要触及的代码之间划清界限？
问问题
1693 次
18 回答
39
如果代码正常工作，并且不需要注意 - 不要花费时间/金钱来更新它。除非在财政上需要这样做。只要确保你所有的新代码都很好，从现在开始慢慢消除这个问题。
于 2009-08-18T18:02:27.197 回答
24
这里有一个启发式方法：您接触的代码在生产中没有出现问题的时间越长，更改它所承担的风险就越大。鉴于此，你能评估你正在做的事情的真正价值吗？你让代码变得更好了吗？表现更好？更易于维护？您必须量化所做更改的好处，并在它们与重构风险之间取得平衡。无论如何，重构通常是一个错误。您应该有充分的理由这样做，并且您应该能够量化收益。
想象一下，你的老板把你带到他/她的办公室，问你“为什么在代码没有问题的情况下做出这个改变？” 你会有好的答案吗？
每条评论：我在这个SO Answer中为质量成本 (COQ) 和非质量成本 (CNQ) 提供了一些很好的资源。
于 2009-08-18T18:04:07.910 回答
12
通常，Gof4 设计模式涉及添加一定程度的间接性，以便更轻松地更改它的任一侧。如果事情不会改变/不需要变得更灵活，那么你就不需要那种间接性。如果它已经存在并且正在工作，则无需更改。重定向级别不是免费的，但会在性能和复杂性方面付出代价。如果我没记错的话，Goff 作者自己也指出了这一点。
编辑添加：好的，必须去拿书才能找到确切的报价。它在第 31 页介绍的末尾，至少在我拥有的版本中：
设计模式不应随意应用。通常，它们通过引入额外的间接级别来实现灵活性和可变性，这可能会使设计复杂化和/或降低一些性能。只有在实际需要其提供的灵活性时，才应应用设计模式。
于 2009-08-18T18:06:33.320 回答
8
通过触摸代码，您会产生风险，即一旦工作的代码将停止正常工作。更好地利用您的时间可能是确保单元测试涵盖遗留代码。然后，当需要更改代码时，您可以重构为任何合适的模式，并确保代码仍然按照设计的方式工作。
于 2009-08-18T18:04:54.430 回答
7
当您重构时，您可以考虑重构为设计模式，但如果它已经在工作，那么仅仅为设计模式更改代码是没有意义的。
于 2009-08-18T18:03:47.273 回答
7
我同意 Joel Spolsky 的观点，即重写代码几乎总是一个坏主意，除非您非常非常具体地了解现有代码有什么问题，重写它会改进什么，以及重写它可能会失去什么知识。
“重写代码，因为它冒犯了你的感受”，说真的，是一个非常糟糕的主意。这是对您时间的不当利用，并且可能会破坏您不理解的东西。
您重写的每一行代码都可能（并且根据我的经验，很可能）是您要引入代码库的新错误。除非您有当前且令人信服的理由，否则永远不要重写代码。
于 2009-08-18T18:06:49.107 回答
7
如果你是我的同事，我也会发疯的。设计模式只是关于如何解决问题的一些一般想法。它们不是主从山顶上写在泥板上的话语。
于 2009-08-18T18:08:37.560 回答
5
我认为您提出这个问题非常好，这是迈向 DPW（设计模式退出）的第一步。
听起来你有典型的上瘾迹象，现在是时候退后一步，检查你的编码生活，问问自己，这会影响我的同事吗？我的公司是否因为我的习惯而受苦？
经过反思和检查，也许您可以找到一种方法来缓和您的设计模式使用，并用健康的模式替换破坏性模式，从而为您和您的编码团队带来好处。
一些有用的问题可能是，你使用设计模式只是因为你昨晚读到了一个新的，还是因为你认为它可能会为项目增加真正的价值？您是因为强烈的愿望而在代码上强制使用设计模式，还是因为该模式已经出现了真正的用处？代码是否已经运行良好并且不会很快更新？如果是这样，可能会有更好的地方消磨时间。
最后，您可以尝试完全放手，看看您编写的代码会出现哪些自然“模式”，而不是试图强迫代码适应您对它应该如何的想法。您可以通过这种方式发现自己的“模式”。
祝你好运，我认为我们中的许多人都以某种方式去过那里，请记住，如果您复发，您总是有您的支持网络 SO（和常识）可以依靠。
于 2009-08-18T18:13:32.867 回答
3
不要强制重新设计 - 仅根据需要重构代码，尤其是在代码已经正常工作的情况下。你改变得越多，你就越需要测试。如果没有现有的测试，这意味着（无论如何，在一个完美的世界中）你必须编写测试。
相反，专注于清理小块代码，只做必须做的事情。在你进行的过程中，为你接触的类编写或更新单元测试，以确保一切继续按应有的方式工作。
于 2009-08-18T18:03:15.557 回答
2
对于个人项目，把自己搞砸。
对于专业的工作，停止它！您正在浪费资源，您可能正在完成请求的功能。alos，您确定在更改旧代码时要 100% 翻译它吗？如果没有，您正在制造问题，并且可能会产生新的错误。
于 2009-08-18T18:11:47.943 回答
1
不需要时不要过度设计。不过，我自己花了一些时间来学习这一点。
问问自己何时需要使用特定的设计模式。如果不是这种情况，请不要。在遗留系统上使用设计模式的一个很好的理由是在重构期间。
于 2009-08-18T18:05:23.307 回答
1
Joel Spolsky 在他的博客上相当聪明地讨论了这个问题。
从本质上讲，一段代码越旧，就越有可能经过彻底的测试和调试。即使它充满了奇怪的修复和你认为是黑客的东西，也可能有一个很好的理由。因此，无论设计多么冒犯您，都应避免重写代码，除非该代码被彻底破坏。
于 2009-08-18T18:08:34.033 回答
0
我用“钱”的方法。重写现有代码会花费您的雇主资金（您的薪水等）。你能诚实地说，你的重写会让你的雇主付出更少的代价吗？根据我的经验，答案几乎总是“不”。
我遇到过不少人，他们量化成本的能力很差，从来没有给予任何合理的考虑，或者更关心他们获取薪水的直接愿望，而不是为他们的雇主提供良好的价值。我个人发现好的雇主会认识到你在帮助他们，并且会随着时间的推移相信你的判断。
于 2009-08-18T18:22:42.803 回答
0
大多数程序员都有一个客户，他们基本上是在支付程序员的薪水。
当你想到要做出这样的改变时，问问自己，“如果我让客户了解所涉及的问题，他会希望我花时间在这上面吗？”。很多时候，答案是否定的。他们为什么要关心它是否有效？
于 2009-08-18T19:00:28.843 回答
0
当您没有客户时，我不同意所有人。重新设计、批评、改进你的代码会让你变得更好。如果你永远不想回顾你所做的事情，那么你就不会进步，你需要批评自己。即使稍后您发现重新设计是一个坏主意，您也会知道原因。
于 2009-08-18T19:22:27.097 回答
0
我经常发现自己使用“总是让一段代码处于比你找到的更好的状态”的原则。
因此，如果我加载了一些课程并注意到它可以在我开始执行更改请求之前进行一些弹簧清洁，那么我将首先执行此操作。这还有另一个优点，因为它可以为您提供一种阅读和理解代码及其依赖项等的方式。
我发现执行更改请求要简单得多，因为您更了解代码。
最后，您将拥有两全其美的优势……一个满意的客户和一个更满意的代码库。
于 2009-08-18T19:42:24.653 回答
0
以不同的设计模式换取不劳而获是一种失败的主张。在设计应用程序时，请使用您认为合适的设计模式并坚持下去，除非有明显的理由需要更改模式。我建议听你的同事的话，不要管这个应用程序。
于 2009-08-18T20:17:07.410 回答
-1
我不认为“如果它没有坏，就不要修复它”是正确的。我认为您绝对应该寻找可以重构的代码，以便以有形的方式使其变得更好。问题是——确保你正在做的事情对未来有帮助，而它有帮助的部分是具体的。
在设计模式术语中——设计模式帮助你使你的代码在面对变化时更加健壮——它允许代码的某些部分独立于其他部分而变化。想一想是否有特定的理由来改变某些东西——你是否预计将来会对需要触及许多其他子系统的某些代码进行更改？
如果你清楚地陈述了你正在解决的问题，并且你能够说服自己和你的同事认为这个问题值得解决（即未来的好处是显而易见的），那么你应该能够继续前进。
于 2009-08-18T21:37:59.757 回答