logo标签列表

我何时需要停止使用设计模式？

design-patternslegacy-code
11

我的同事们都疯了，因为我总是想重写已经运行正常的代码，因为我想用设计模式替换一些旧的设计。尽管我觉得这样可以改进现有的代码，但我感到有些偏执，并试图在任何地方使用它们，甚至用一个设计模式替换另一个。我的一些同事说，只要旧代码能够工作，就不要动它。

什么时候应该停止使用它们？你如何划分需要被更好的设计替换和不需要触碰的代码之间的界限？

放手一搏，不要陷入重构旧代码的狂热中。我并不是说设计模式不好，但除非你必须与旧代码一起使用新代码，并且它对你的产品产生了负面影响，否则不要修复没有问题的东西。 - Justin Johnson
18个回答
39

如果代码正常工作且不需要关注-不要花时间/金钱更新它。除非财务上必须这样做，否则不要更新。只需确保所有新代码都是优秀的，并从现在开始慢慢消除此问题。

+1：它有多坏？如果它坏了，维护它需要多少费用？如果它没有坏，并且维护成本不高，那么就不值得花费任何精力。 - S.Lott
2
@S.Lott - 我同意，“只有在财政必要的情况下才需要修复。”如果它不稳定，并且如果忽略将会花费大量资金 - 那就修复它 :) - Sampson
2
@S. Lott：他甚至没有说它是坏的——只是它不符合Gof4设计模式之一。在我看来，这是一个非常荒谬的改变代码的理由。 - MusiGenesis
1
+1 真的。这不仅很危险（新代码比旧的工作代码更有风险），而且表明管理失败：你真的没有更好的事情要做，而是有效地“原地踏步”并做一些没有真正价值的工作吗？ - DarkSquid
24
这里有一个启发式法则：你所接触的代码在生产环境中无问题的时间越长，你改动它所承担的风险就越大。考虑到这一点，你能评估你正在做的事情的真正价值吗？你让代码变得更好了吗？性能表现更佳了吗？可维护性更高了吗？你必须量化你正在进行的变化的益处，并将它们与重构的风险相平衡。不加思索地进行重构通常是错误的。你应该有很好的理由去做它，并且你应该能够量化收益。
想象一下，你的老板把你叫到他/她的办公室，并问你：“为什么在代码没有问题的情况下要进行这种更改？”你会有一个好的回答吗？
根据评论: 我在这个SO Answer提供了一些关于质量成本（COQ）和非质量成本（CNQ）的好资源。
现在，我们如何量化好的代码和坏的代码呢？我似乎忘记了... - Mark Seemann
@Mark：永远不要怀疑，万事皆有方法。 :) - JP Alioto
链接已损坏。 - jaco0646
12
通常，Gof4设计模式涉及增加一定程度的间接性，以使其两侧更易于改变。如果事物不会改变/不需要更灵活，则不需要这种间接性。如果已经存在且正常工作，则无需更改。间接层次不是免费的，因为它们在性能和复杂性方面具有成本。如果我没记错的话，GofF的作者自己指出了这一点。
编辑添加：好的，不得不去找书来找到确切的引用。至少在我手上的版本中，它在第31页介绍的最后一个部分中：
设计模式不应该被不加区分地应用。通常它们通过引入额外的间接级别来实现灵活性和可变性，这可能会复杂化设计并/或者对你的性能造成一些影响。只有当需要它提供的灵活性时，才应该运用设计模式。
8

触碰代码会增加出错的风险，导致原本正常运行的代码无法正常工作。更好的做法是确保遗留代码已经通过单元测试覆盖。当需要修改代码时，可以重构到适合的模式，并确保代码仍然按设计要求正常工作。

7

当你进行重构时，可以考虑将其重构为设计模式，但是如果代码已经正常工作，没有必要仅为了设计模式而更改代码。

7
我赞同Joel Spolsky的观点，即重写代码几乎总是一个坏主意，除非你对现有代码的问题有非常明确的想法，知道重写它会带来什么改进，并且知道你可能会因此失去什么知识。
“因为代码让你感到不适而重写代码”是一个非常糟糕的想法。这是浪费时间的不好做法，而且会有破坏你不理解的东西的风险。
每一行你重写的代码都有可能（并且根据我的经验，很可能）成为代码库中新的错误。除非你有充分和强有力的理由这样做，否则不要重写代码。
7

如果你是我的同事，我也会变得很疯狂。设计模式只是一些解决问题的一般性思路，并不是从山顶上用泥板刻下来的上帝之言。

5
我认为你提出这个问题非常好，这是向DPW（设计模式戒除）迈出的第一步。
听起来你有成瘾的典型迹象，现在是时候退后一步，审视你的编码生活，并问自己一些问题，比如，这是否影响了我的同事？我的公司是否因为我的习惯而受到了影响？
经过反思和检查，也许你可以找到一种方式来控制你的设计模式使用，并用健康的模式代替破坏性的模式，这将给你和你的编码团队带来好处。
一些有用的问题可能是，你是否只是因为昨晚读了一个新的设计模式而使用设计模式，还是因为你认为它可能为项目增加真正的价值？你是否因为强烈的愿望而强制在代码中使用设计模式，还是因为模式的真正用途已经出现了？代码已经很好地工作并且不会很快更新吗？如果是这样，可能有更好的地方可以花费你的时间。
最后，你可以尝试完全放手，看看从你写的代码中会出现什么自然的“模式”，而不是试图强制代码适应你关于它应该是什么样子的想法。你可能会通过这种方式发现自己的“模式”。
祝好运，我认为我们许多人在某种程度上都有过这样的经历，记住如果你复发了，你总是可以依靠SO（和常识）的支持网络。
3

不要强制进行重新设计 - 只有在需要时才对代码进行重构，特别是如果代码已经正常工作。你改动的越多，就需要测试的越多。如果没有现有的测试，这意味着（在完美的世界中）你需要编写测试。

相反，专注于以小块为单位清理代码，只做必须做的事情。随着进行，为接触到的类编写或更新单元测试，以确保一切都能正常工作。

2

对于个人项目，你可以尽情发挥。

但对于专业工作，请停止这样做！你正在浪费资源，而这些资源本可以用来完成所需的功能。此外，当你更改旧代码时，你确定已经将其100％翻译正确吗？如果没有，你会产生问题并可能引入新的错误。

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文，
原文链接