【发布时间】：2010-07-01 01:23:18
【问题描述】：
在编码和审查代码时，很容易发现可以使用设计模式的地方。这里有指挥链，那里有策略……尽管更好的解决方案可能是开关或一些简单的 if，但潜入并应用模式是很诱人的。
是否有一些您认为有价值的规则或提示可以估计何时进行实际重构？
等到添加功能变得太困难？等到第三次还要改代码？第一次需要破解？
【问题讨论】：
标签： design-patterns refactoring
【发布时间】：2010-07-01 01:23:18
【问题描述】：
如果代码可读/可理解并且将来不太可能更改或扩展，您可能希望保持原样。
但如果代码会发生变化，或者您需要在某个时候为其构建解决方法，那么最好立即重构它。签入代码比以前更干净是一个好习惯。
但请记住，这取决于投资回报。简单的重构可能会级联到代码的其他部分，然后也必须对其进行重构。如果代码库将来不会不断开发，那么可能不值得花太多时间重构它。
【讨论】：
我的想法是最有用的重构发生在开发新功能或修复错误时。当您编写新代码或修复错误时，您需要签入代码的改进版本（如果可以改进）。因此，如果设计模式改进了代码（可读性、可扩展性、可测试性），则在这样做时，您可以重构该模式。
在没有其他动机的情况下重构模式对 IMO 几乎没有价值。确实需要有一个问题需要解决，这些模式才会有帮助。
【讨论】：