Cómo enseñar patrones de diseño a un equipo

Question

Soy un gran admirador del libro clásico Design Patterns. Trabajé diligentemente para aprender la mayoría de los patrones y cómo se usan (y cuándo deben evitarse). Sin embargo, frecuentemente me encuentro con equipos donde soy el único que promociona el libro de forma regular. Tenía la esperanza de que el aprendizaje de este libro facilitaría la explicación de conceptos a otros desarrolladores, pero la mayoría todavía no ha invertido el tiempo para aprender tales temas.

Estos son sistemas importantes que necesitan una arquitectura sólida. No quiero decir constantemente "lee el libro". ¿Cómo animo el uso regular de patrones de diseño sin parecer pomposo? ¿Alguien ha tenido éxito en tener todo un equipo aprendiendo y usando patrones de diseño?

Answer 1

Sugeriría que no se evangilicen los patrones de diseño, sino que se proponen diseños/enfoques específicos para problemas específicos a medida que se los encuentre.

Más tarde, cuando ocurre una situación similar, puede recordar el enfoque que tomó para el problema anterior. Entonces puede llamarlo un "patrón" que el equipo ha visto utilizado para resolver problemas reales con un beneficio real.

Tampoco me adheriré estrictamente a los patrones de diseño en el libro por sí mismos. Puede cegarle a las buenas sugerencias de non-patternistas o cegarlo de problemas reales que pueden ser específicos de su entorno/dominio del problema.

Answer 2

No fuerce la lectura del libro, esto no funcionará.

Simplemente refactorice su código utilizando un patrón de diseño y muéstreles por qué es más fácil.

También deles algo de tiempo para aprender la nueva forma de trabajar.

Answer 3

Revisión de código.

Obligarlos a utilizar patrones de diseño probablemente conduzca a un uso excesivo y antipatrón.

Answer 4

Confieso que nunca he tratado de hacer esto, así que estoy recurriendo a observaciones generales sobre cómo los equipos pueden mejorar sus habilidades y la calidad de lo que producen. ¿Cómo aprenden las personas? Leer, experimentar, imitar, ser mentor ... ¡incluso escuchar conferencias! Creo que deberás aplicar varios enfoques diferentes. Diría que dos cosas son críticas: exposición a ideas y comentarios.

Por lo tanto para un equipo que haría lo siguiente:

1). Diseño y revisiones de código. Las revisiones no deben ser conducidas solo por seniour people. Haga que los juniors también lean el código y comenten. Lo ideal es que aprendan también.

2). El diseño de wokrshops genera problemas y soluciones alternativas.

En ambos casos, me preocupan menos los Patrones de diseño (el libro) que en inculcar un espíritu de evaluación y consideración por el diseño. ¿Lo que es bueno? ¿Lo que es malo? Qué fuerzas y compromisos conducen a esta solución particular. ¿Cuándo es lo suficientemente bueno?

Answer 5

1. Tome un problemabien conocido por ellos.

2. Identificar el patrón que puede resolver el problema más eficazmente. Y resuelva el problema con el patrón y también implemente la solución y demuéstrelos funcionando.

3. No les diga todavía sobre el patrón de diseño. Repita esto por aproximadamente 3-4 problemas. Luego dígales que lo que hicieron fue resolver un problema con el patrón de diseño: nombre cada patrón y bríndeles libros de referencia o punteros URL para su estudio e investigación.

Answer 6

Leer el libro solo le da "una idea" de los patrones de diseño y creo que esa luz solo hace clic después de haber implementado algunos patrones. En su situación, puede ser recomendable establecer una revisión por pares y observar el código final para ver dónde un patrón puede haber aliviado un problema en particular.

Como no mencionó una fuente, asumiré que está hablando del libro GOF y, si es así, también supongo que está trabajando en un lenguaje estáticamente tipado como C++, Java, C#, etc. Si no es así, es posible que muchos de los patrones no se apliquen al dominio de su problema y probablemente dejen de lado sus esfuerzos para la adaptación del equipo. Por ejemplo, Visitor (doble despacho) no se usa en idiomas enlazados dinámicamente, Scala tiene Singleton horneado, etc.

Answer 7

Obtenga un par de copias de "Patrones de diseño de Head First" y solicite a la gente que lo lea. Es una forma divertida de aprender sobre patrones.

Enseño un curso de Patrones de Diseño para el Programa de Ingeniería Johns Hopkins para Profesionales (programa de maestría vespertino), y regularmente hago almuerzos con bolsas de papel en el trabajo para hablar sobre patrones.

Yo recomendaría tener un almuerzo brownbag de una hora una o dos veces al mes. Hable sobre el concepto del patrón y muestre algunos ejemplos de programación.

Cada conferencia hablo sobre el Golden Hammer: aprende a usar cada patrón y BLOQUEA en tu caja de herramientas hasta que los necesites.

Mi técnica favorita es lo que yo llamo "Pattern Theatre". Cada uno de mis alumnos investiga un patrón y escribe un guión de 2-3 páginas que usa el patrón en el mundo real. Por ejemplo, presento un teatro sobre el viaje de Paul Revere para describir Observer. (Robert Newman ve las lámparas británicas y las lámparas, Paul Revere ve las lámparas y comienza a montar y gritar, algunos ciudadanos lo escuchan y se esconden, algunos ciudadanos lo escuchan y agarran sus armas) parejas discretas de estímulo/respuesta) Nada en los teatros menciona la programación; se trata de resolver los conceptos antes de comenzar la parte de programación de la conferencia.

Answer 8

La predicación no funciona. Predicar con el ejemplo.

Cuando esté trabajando en un diseño, agarre su (s) libro (s) de patrones de diseño y ábralo. Incluso si ha memorizado todos los patrones, abra el libro.

Cuando alguien le hace una pregunta de diseño, no solo diga el nombre de un patrón, agarre el libro, ábralo al patrón, señale la parte relevante del patrón y diga algo como "oh, lo escucho, no estoy seguro, pero creo que esto podría ser útil ".

Si la mayoría de su equipo lo ve como un gurú del diseño y constantemente lo ven haciendo referencia a un libro de patrones de diseño, establecerán la conexión por su cuenta.