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

ak3*_*t0n 11 design-patterns legacy-code

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

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

Sam*_*son 39

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

  • @ S.Lott - 我同意,"直到它在财政上是必要的." 如果它不稳定,如果被忽视将花费一大笔钱 - 修复它:) (2认同)
  • @S.Lott:他甚至没有说它被打破了 - 只是它与Gof4的一种设计模式不匹配.恕我直言,改变代码是一个完全荒谬的理由. (2认同)

JP *_*oto 24

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

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

评论:我在本SO答案中为质量成本(COQ)和非质量成本(CNQ)提供了一些很好的资源.


Ano*_*non 12

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

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

不应该不加区分地应用设计模式.通常,它们通过引入额外的间接层来实现灵活性和可变性,并且可能使设计复杂化和/或使您获得某些性能成本.只有在实际需要灵活性时才应用设计模式.


Ner*_*ury 8

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


Jam*_*ack 7

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


pet*_*erb 7

我同意Joel Spolsky的说法,重写代码几乎总是一个坏主意,除非你对现有代码有什么问题有一个非常非常具体的想法,它会改进什么改写,以及你可能通过重写它可能会失去什么知识.

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

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


Mus*_*sis 7

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


alc*_*cal 5

我认为你问这个问题非常好,这是DPW(设计模式撤销)的第一步.

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

通过反思和检查,也许您可​​以找到一种方法来调节您的设计模式使用,并用健康的模式取代破坏性模式,为您和您的编码团队带来好处.

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

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

祝你好运,我想我们很多人都曾以这样或那样的方式去过那里,记住如果你复发,你总是有你的支持网络(以及常识).