不要只为了让你的代码符合某本书中的模式而进行重构。
模式确实有助于锻炼您的大脑，思考良好的软件设计。我实际上认为，我通过阅读模式书籍并反思它们以及学习如何理解它们以及它们的优点来获得了我的很多编程技能和知识。这实际上就是关键所在。它们的目的是使事情变得更加容易，更易于维护、测试等等...... 而不是让你的生活变得更加困难 :)
我认为这也是“困难”的原因。当您遇到问题时，模式给您一个框架、一个起点。例如：您真的想对您的代码进行单元测试，但由于它依赖于UI逻辑或耦合度太高而无法进行。那就是您的问题，因此您可能会通过了解MVC模式和依赖注入和控制反转的概念来找到解决方案。它们可以给您一个起点，因为MVC模式在高层次上解释了Observer、Observable、Controller view等概念以及它们之间的关系。然后，作为一名优秀的程序员，您的任务是选择正确的方法，并在合理的范围内应用该模式。不要只是因为模式告诉你这样做。记住，它只是一个框架，您可以修改和适应它以适应您特定的环境。
IIABDFI。如果它不坏，就不要修复它。
换句话说，“一个良好运行的代码片段”作为您所说的唯一重写原因是，如果您需要概括它所做的内容，而不会使同一代码可重用。
在这种情况下，使用模式可以在确定如何有效实现可重用性方面具有好处，但该模式需要成为“工具”，而不是最终目标。
请注意，使用模式还是不使用模式是一个完全不同的问题，我发现最好通过this SO question的第一个（被接受的）答案回答。简而言之，如果您是一位优秀的开发人员，则会使用模式，无论您知道与否，因为模式只是特定设计问题的好的且经常见到的解决方案。（我曾经处于这种情况-多年来，我创建或学习并反复使用了许多有用的设计，直到有一天有人告诉我这些东西叫做模式，并给他们取了可爱的名字）。
最近我在Twitter上和一些程序员产生了争执。我邀请他们参加“设计模式Barcamp”，但有一个人开始说这样的Barcamp没有意义，因为你是否知道模式都无所谓。他说这就像达到涅磐一样。但我不同意。我们都是工程师，而学习如何编写好的软件部分地来自抽象思维。但是，仅仅那还不够。学习其他编程语言、编程范例，扩展你对正在使用的工具的知识，阅读用你喜欢的语言编写的开源软件代码，这些都会让你成为更好的程序员（如果你足够幸运的话）。
回答你的问题。是的，有些人认为他们可以应用模式。但有时他们可能选择不适合他们问题的模式。我喜欢说所有工具都是最适合用于它们预定的场景。因此，模式也是一样的。如果你不确定，最好与你的架构师交流。查找最佳实践，了解为什么会使用模式，它会给你什么样的机会/困难？它会增加额外负担吗？代码是否仍然可读性强且易于维护呢？如果答案为“是”，那就继续吧。
