我是经典 Design Patterns 书籍的忠实粉丝。我非常努力地学习了大多数模式以及它们是如何使用的（以及何时应该避免使用它们）。但是，我经常遇到只有我一个人定期兜售这本书的团队。我希望学习这本书可以更轻松地向其他开发人员解释概念，但大多数人还没有花时间学习这些主题。
这些是需要稳固架构的主要系统。我不想经常说“看书”。我如何鼓励经常使用设计模式而不显得浮夸？有没有人成功地让整个团队学习和使用设计模式？
【问题讨论】：
标签： design-patterns
我建议不要宣传设计模式，而是提倡针对遇到的特定问题的特定设计/方法。
稍后当发生类似情况时，您可以重新使用针对之前问题所采取的方法。然后，您可以将其称为团队已经看到用于解决实际问题并带来真正好处的“模式”。
我也不会为了他们自己而严格遵守书中的设计模式。它可能使您对非设计模式专家的好建议视而不见，或者使您对可能特定于您的环境/问题域的实际问题视而不见。
【讨论】：
代码审查。
强迫他们使用设计模式可能会导致过度使用和反模式。
【讨论】：
我承认我从未尝试过这样做，因此我正在参考有关团队如何提高技能和产品质量的一般性观察。人们如何学习？阅读、实验、模仿、指导……甚至听讲座！我认为您需要应用几种不同的方法。我想说两件事很关键：接触想法和反馈。
因此，对于一个团队，我会做以下事情：
1)。设计和代码审查。审查不能只由高级人员进行。让大三学生也阅读代码和评论。理想情况下，他们也学习。
2)。 Design wokrshops 将问题抛诸脑后，并提出替代解决方案。
在这两种情况下，我都不太关心设计模式（这本书），而是灌输一种评估和考虑设计的精神。有什么好的？有什么不好？是什么力量和妥协导致了这个特定的解决方案。什么时候足够好？
【讨论】：
解决他们熟知的问题。
确定可以最有效地解决问题的模式。并用模式解决问题并实施解决方案并展示它们的工作原理。
暂时不要告诉他们设计模式。 重复 大约 3-4 个问题。稍后告诉他们你所做的是解决了设计模式的一个问题 - 为每个模式命名并给他们参考书或 URL 指针，以供他们进一步学习和研究。
【讨论】：
不要强迫他们看书，这是行不通的。
只需使用设计模式重构他们的代码，并向他们展示为什么这样做更容易。
也给他们一些时间来学习新的工作方式。
【讨论】：
获取几本“Head First Design Patterns”并请人们阅读。这是一种了解模式的有趣方式。
我为约翰霍普金斯大学专业工程项目（夜间硕士学位项目）教授设计模式课程，并定期在工作中举行棕色袋子午餐来讨论模式。
我建议每月举行一次或两次一小时的棕色袋午餐。谈谈模式的概念，并展示一些编程示例。
我每次讲课都会谈到金锤——学习如何使用每种模式并将它们锁定在你的工具箱中，直到你需要它们！
我最喜欢的技术是我所说的“模式剧场”。我的每个学生都会研究一种模式并编写一个 2-3 页的脚本，以在现实世界中使用该模式。例如，我展示了一个关于 Paul Revere 骑行的剧院来描述观察者。 （罗伯特·纽曼（Robert Newman）看到英国人并点亮灯；保罗·里维尔（Paul Revere）看到灯并开始骑马并大喊大叫；一些市民听到他并躲藏起来；一些市民听到他并拿起枪——离散的刺激/反应对）剧院里没有提到编程；在我开始讲座的编程部分之前，它们都是关于了解概念的。
【讨论】：
阅读这本书只会让你“洞察”设计模式，我相信只有在实现了一些模式之后才会点击。在您的情况下，建议您进行同行评审并观察已完成的代码，以了解模式在哪些方面可能缓解了特定问题。
由于您没有提及来源，我假设您在谈论 GOF 书，如果是这样，我还假设您正在使用 C++、Java、C# 等静态类型语言工作。如果不是，那么许多模式甚至可能不适用于您的问题领域，并且可能会影响您为团队适应所做的努力。例如，Visitor（双重调度）在动态绑定的语言中是不使用的，Scala 已经烘焙了 Singleton 等等。
【讨论】：
讲道不起作用。以身作则。
当您进行设计时，请拿起您的设计模式书并打开它。即使你已经记住了所有的模式，打开这本书。
当有人问你一个设计问题时，不要只告诉他们一个模式的名称，拿起书，打开它，指向模式的相关部分，然后说“哦，听着是的，我不确定，但我认为这可能会有所帮助”。
如果您的团队中的大多数人都将您视为设计大师，并且他们经常看到您参考设计模式书籍，他们会自行建立联系。
【讨论】：