如何向团队传授设计模式

时间:2009-11-04 15:24:09

标签: design-patterns

我是经典Design Patterns书的忠实粉丝。我非常努力地学习大多数模式以及如何使用它们(以及何时应该避免使用它们)。但是,我经常遇到一些团队,我是唯一一个定期推销这本书的团队。我希望学习本书可以更容易地向其他开发人员解释概念,但大多数人还没有花时间去学习这些主题。

这些是需要坚固架构的主要系统。我不想经常说“读这本书”。我如何鼓励经常使用设计模式而不会过于夸张?有没有人成功让整个团队学习和使用设计模式?

8 个答案:

答案 0 :(得分:14)

我建议不要改进设计模式,而是在遇到特定问题时提倡具体的设计/方法。

稍后当出现类似情况时,您可以回过头来解决之前问题。然后你可以把它称为团队已经看到用来解决实际问题的“模式”。

为了自己的利益,我也不会严格遵守书中的设计模式。它可能使您无法接受来自非设计模式主义者的好建议,或使您对可能特定于您的环境/问题领域的实际问题视而不见。

答案 1 :(得分:4)

代码审查。

强迫他们使用设计模式可能会导致过度使用和反模式。

答案 2 :(得分:2)

我承认我从未尝试过这样做,所以我正在利用关于团队如何提高技能和产品质量的一般观察。人们如何学习?阅读,试验,模仿,指导......甚至听讲座!我认为你需要应用几种不同的方法。我要说两件事是至关重要的:接触想法和反馈。

因此,对于一个团队,我会做以下事情:

1)。设计和代码审查。评论不仅仅由老年人进行。让青少年也阅读代码和评论。理想情况下他们也学习。

2)。设计wokrshops折腾问题并提出替代解决方案。

在这两种情况下,我都不太关心设计模式(书),而不是灌输评价精神和设计考虑。有什么好的?什么不好?什么力量和妥协导致这个特定的解决方案。什么时候足够好?

答案 3 :(得分:2)

  1. 采取一个众所周知的问题

  2. 确定能够最有效地解决问题的模式。并解决模式的问题,并实施解决方案并显示它们的工作。

  3. 不要告诉他们有关设计模式的信息。 重复以解决大约3-4个问题。后来告诉他们你做了什么解决了设计模式的问题 - 为每个模式命名,并为他们的进一步研究和研究提供参考书或URL指针。

答案 4 :(得分:1)

不要强迫他们阅读这本书,这是行不通的。

只需使用设计模式重构代码,并向他们展示为什么这样更容易。

同时给他们一些时间来学习新的工作方式。

答案 5 :(得分:1)

获取“Head First Design Patterns”的几份副本,并请大家阅读。这是学习模式的有趣方式。

我为约翰霍普金斯专业人士工程专业(晚间硕士学位课程)教授设计模式课程,并定期举办棕色包午餐工作,讨论模式。

我建议每月一次或两次吃一小时的褐色午餐。谈谈模式的概念并展示一些编程实例。

我在谈论金锤时的每一个讲座 - 学习如何使用每个模式并将它们锁定在工具箱中直到您需要它们为止!

我最喜欢的技术是我称之为“模式剧场”。我的每个学生都研究一个模式,并编写一个2-3页的脚本,使用现实世界中的模式。例如,我提出了一个关于保罗·里维尔(Paul Revere)驾驶描述观察者的剧院。 (罗伯特纽曼看到英国和灯光;保罗里维尔看到灯,开始骑车和大喊;一些市民听到他和隐藏;一些市民听到他并抓住他们的枪 - 离散刺激/响应对)没有任何在剧院提到编程;在开始讲座的编程部分之前,他们都是为了理解这些概念。

答案 6 :(得分:0)

阅读本书只会让您对“设计模式”有所了解,而且我相信在实施某些模式后,只需点击一下。在您的情况下,建议您建立同行评审并观察完成的代码以查看模式可能缓解特定问题的位置。

由于您没有提及源代码,我将假设您正在讨论GOF书籍,如果是这样,我还假设您使用的是静态类型语言,如C ++,Java,C#等。如果没有,那么许多模式可能甚至不适用于您的问题域,并且可能会使您的团队适应工作变得边缘化。例如,访问者(双重调度)不用于动态绑定语言,Scala使用Singleton烘焙等。

答案 7 :(得分:0)

讲道不起作用。以身作则。

当您从事设计工作时,请抓住您的设计模式书并将其打开。即使你已经记住了所有的模式,也要打开这本书。

当有人问您设计问题时,不要只告诉他们图案的名称,抓住图书,打开图案,指向图案的相关部分,然后说出“哦,听到是的,我不确定,但我认为这可能会有所帮助“。

如果您的团队中的大多数人认为您是设计大师并且他们经常看到您引用设计模式书,那么他们将自己建立连接。