¿Están mal vistos los patrones de diseño?

131

Tuve una discusión con uno de nuestros desarrolladores senior que ha estado en el negocio durante 20 años. Es bastante conocido en Ontario por un blog que escribe.

Lo extraño es lo que me dijo: dijo que hay una pieza de código que es una pesadilla con la que trabajar, ya que está escrito en un libro de texto y no tiene en cuenta el mundo real. Agregar un nuevo campo a la IU / base de datos / capa de datos toma de 2 a 3 horas, mientras que en su código toma 30 minutos.

La otra cosa también es que evita los patrones de diseño porque la mayoría de los programadores no los entienden y no son buenos desde una perspectiva de mantenimiento.

También está la idea de que la mayoría de los desarrolladores web en Canadá prefieren que su modelo de datos se herede de las clases de Capa de datos, en lugar de mantenerlo aislado. Le pregunté: "¿No es el estándar de la industria que el modelo se separe de la capa de datos?" Dijo que a veces, pero la mayoría de la gente aquí prefiere no hacer eso porque es demasiado trabajo.

Parece que su razonamiento para no codificar utilizando las mejores prácticas se debe a que es una pesadilla de mantenimiento, algunos de nuestros empleados lo entienden (aparte de mí) y es lento para trabajar si necesita eliminar nuevas funciones o campos en un Pocos días.

Es tan extraño escuchar una opinión como esta, considerando que Stack Overflow alienta a la gente a seguir los estándares de la industria. ¿El problema es que estamos constantemente obligados a generar nuevos campos y características en cuestión de días, que no es posible deducir un patrón sólido que sea lo suficientemente flexible? Eso parece ser la esencia de lo que entiendo de esto.

¿Qué opinas de estas afirmaciones?

    
pregunta Igneous01 30.08.2016 - 21:23
fuente

13 respuestas

234

Estas son las palabras de alguien que ha encontrado el éxito e ignora a las personas que tratan de decirle qué hacer en la jerga de patrones que no entiende.

Los patrones de diseño y las mejores prácticas no son lo mismo. Algunas personas piensan que lo son y hacen que las personas que saben lo que hacen estén locas. Incluso si no saben el nombre correcto de lo que están haciendo.

Los patrones de diseño existían antes de que tuvieran nombres. Les dimos nombres para que hablar de ellos sea más fácil. Un patrón que tenga un nombre no lo convierte en algo bueno. Lo convierte en una cosa reconocible.

Es probable que este tipo esté usando patrones de los que ninguno de los dos haya oído hablar. Eso está bien, hasta que necesites hablar con él sobre cómo se hace algo. O bien tendrá que aprender a hablar con usted o tendrá que aprender a hablar con él. No tiene nada que ver con quién tiene "razón".

    
respondido por el candied_orange 30.08.2016 - 21:36
fuente
95

Muchos patrones de diseño, del tipo que usted y su amigo están describiendo, son realmente soluciones para las deficiencias en los lenguajes de programación . Utilice un lenguaje de programación más expresivo, y la mayor parte de la necesidad de estos patrones de diseño desaparece.

Debido a que se requieren buenos patrones de diseño para atender a muchos escenarios de uso posibles, tienden a estar sobre diseñados. El código de ingeniería excesiva tiene un costo: usted tiene que leerlo, entender lo que hace y entender cómo funciona dentro del contexto de todo el sistema de software. En consecuencia, al igual que con cualquier otra técnica de desarrollo de software, debe evaluar la técnica contra el costo de utilizarla y decidir si los beneficios exceden el costo.

En igualdad de condiciones, menos código siempre es mejor. He pasado por arquitecturas en capas en las que literalmente tienes que hacer de tres a seis saltos en varios proyectos para encontrar cualquier código que sea interesante, es decir, el código que realmente logra algo que no sea la adición de gastos generales.

Se supone que los patrones de software conocidos le brindan un vocabulario común mediante el cual puede comunicar estrategias de diseño. Desafortunadamente, muchos desarrolladores de software no entienden el vocabulario del patrón de software lo suficientemente bien como para aplicarlo adecuadamente a sus problemas de programación. Los desarrolladores sin experiencia ven estos patrones como parte del dominio de los expertos; quieren ser vistos como expertos, por lo que intentan aprender y aplicar los patrones antes de que estén listos. Lo que realmente deberían hacer es enfocarse en aprender los fundamentos de la programación primero y luego intentar resolver el problema que cada patrón resuelve por sí mismo. Si hacen esto, estarán en una posición mucho mejor para entender y aplicar los patrones correctamente.

    
respondido por el Robert Harvey 30.08.2016 - 22:13
fuente
85

Stackoverflow.SE y Programmers.SE alientan principalmente a las personas a seguir mejores prácticas como SOLID, no estándares de la industria . Y créanlo o no, el estándar de facto de la industria es a menudo la arquitectura "big ball of mud" - en serio.

Pero para responder a su pregunta directamente: el problema con los patrones de diseño es similar al de la herencia: muchos desarrolladores mediocres los utilizan en exceso, lo que tiene un cierto riesgo de crear un código con ingeniería excesiva y difícil de mantener. Pero la respuesta a esto seguramente no es evitar o prohibir completamente el uso de patrones de diseño (o herencia), la respuesta es aprender a usar estas herramientas en situaciones en las que tienen sentido, y solo allí. Y esto es totalmente independiente de trabajar "ágil" o no.

    
respondido por el Doc Brown 30.08.2016 - 22:12
fuente
45
  1. Los patrones de diseño son solo nombres que se usan para comunicar ideas. A menudo me encontraba haciendo cosas que más tarde descubrí que tienen un nombre. Por lo tanto, no hay una "forma de patrón de diseño" a diferencia de una "manera de patrón de no diseño".

  2. Los patrones de diseño son pautas. Como todo, cada uno de ellos tiene ventajas y desventajas. La clave no es aprender el patrón y aplicarlo donde corresponda, sino comprender la idea del patrón, las ventajas y desventajas que tiene y usarlo para inspirarse en la solución de su problema.

  3. Todas las mejores prácticas y pautas pueden ignorarse si existe una razón suficientemente buena. Las razones válidas incluyen el tiempo de desarrollo y las expectativas de la aplicación. Por ejemplo, soy consciente de que es malo para los valores de código duro (ejemplo estúpido) pero para una prueba de concepto, las ventajas podrían superar los costos (en este caso, principalmente el tiempo de desarrollo). Sin embargo, si se toma una decisión como esta, podría ser contraproducente y, en algún momento, podría ser necesaria una refactorización.

respondido por el Paul92 30.08.2016 - 22:27
fuente
28

Para agregar otra metáfora a la sopa, los patrones de diseño son Clippy, el ayudante de Microsoft Office. "Parece que estás haciendo lo mismo con un montón de cosas. ¿Puedo ayudarte con eso ofreciéndote Iterador o Visitante?"

Una buena revisión de esos patrones indicará cuándo es útil hacer algo de la misma manera que se ha hecho muchas veces antes, qué errores cometerás la primera vez que lo intentes y qué formas comunes se han encontrado Evita esos errores. Entonces, lee el patrón de diseño (o lo revisa de memoria) y luego continúa con su trabajo. Lo que no se puede hacer es obtener solo utilizando Clippy y asistentes.

Cuando las personas sin experiencia pueden equivocarse y escribir un código que no tiene en cuenta la realidad, es cuando piensan que su lista de patrones de diseño es una lista completa de todos los enfoques posibles para resolver problemas en el software e intentan diseñar el código Uniendo patrones de diseño hasta que esté terminado. Otra táctica deficiente que se observa en la naturaleza es hacer que un patrón de diseño se adapte a una situación para la que no es realmente adecuado, sobre la base de que el patrón de diseño "es la mejor práctica". No, puede o no ser la mejor práctica para la clase de problema que realmente resuelve , pero ciertamente no es la mejor práctica para problemas que no resuelve, o para problemas que resuelve solo introduciendo Complejidad innecesaria cuando hay una solución más simple.

Por supuesto, también es posible que alguien evite un patrón sobre la base de YAGNI, luego se dé cuenta de que lo necesita y busca a tientas la solución normal. Esto suele ser (pero no siempre) peor que darse cuenta del requisito desde el principio, y es por eso que incluso en el desarrollo ágil es frustrante cuando los requisitos totalmente predecibles no se descubren temprano. No puedo haber sido el único programador de C ++ que se mostró muy divertido al ver que Java rechazó inicialmente los contenedores genéricos por ser innecesariamente complejos, y luego los volvió a conectar.

Por lo tanto, es casi seguro que sea un error evitar escribir un Iterador en principio porque prefieres evitar los patrones de diseño.

  

Agregar un nuevo campo a la IU / base de datos / capa de datos toma de 2 a 3 horas, mientras que en su código toma 30 minutos.

Realmente no puedes discutir eso: por esta métrica su diseño es mucho mejor que el otro. Sin embargo, si es porque evitó los patrones de diseño es cuestionable, creo que es más probable porque consideró los problemas correctos del "mundo real" cuando lo diseñó, y con el beneficio de la experiencia es mejor en su trabajo que alguien armado solo con un libro de texto y altos ideales.

Entonces, reconoció que cualquier patrón que requiera que toques muchos puntos diferentes en el código para agregar un campo es un mal patrón para el trabajo, "facilita la adición de campos", y no usó esos patrones. Las arquitecturas en capas pueden sufrir en este sentido, y es incorrecto usar patrones de diseño sin apreciar sus desventajas.

En contra de eso, ¿cuánto tiempo se tarda en escribir una nueva interfaz de usuario en su diseño y en una arquitectura en capas? Si el proyecto requería que él construyera y desplegara constantemente nuevas interfaces de usuario a través de un modelo de datos fijo, en lugar de agregar campos constantemente, con suerte habría diseñado para eso. O también. Pero a pesar de todos sus beneficios, decir "estamos haciendo ágil" lamentablemente no significa que nunca tendrás que hacer otra compensación.

La selección de un menú de patrones de diseño ciertamente puede impedirle pensar en las preocupaciones más importantes. Pero reconocer cuándo estás escribiendo un Visitante, y documentarlo o nombrarlo como "Visitante" para ayudar a los lectores a obtenerlo rápidamente, no interfiere mucho con nada. Escribir "esto es un Visitante" en su lugar de documentarlo correctamente es un terrible error por la razón que da su desarrollador senior: los programadores no lo entenderán. Incluso los programadores que saben lo que es un visitante necesitan más información que simplemente "este es un visitante".

    
respondido por el Steve Jessop 31.08.2016 - 10:56
fuente
18

Su colega parece sufrir el síndrome NIH ("No se ha inventado aquí").

Es perfectamente plausible que su código facilite la adición de nuevos campos: también soy mucho más rápido para actualizar mi propio código que el código escrito por otros tipos. Pero esta velocidad a corto plazo no dice nada sobre la capacidad de mantenimiento y la portabilidad del código. Le daré el beneficio de la duda: el código existente podría estar mal estructurado si ha seguido mal un libro de texto o una buena receta en el contexto incorrecto.

Evitar los patrones de diseño es realmente sorprendente. En mis últimos 30 años de codificación y administración de programadores, los patrones de diseño ayudaron a poner palabras sobre las cosas que se hicieron de manera instintiva, ayudándoles a comprender más rápidamente la intención, las ventajas, los inconvenientes, el riesgo, las oportunidades y los patrones relacionados. ¡Los patrones de diseño demostraron ser verdaderos aceleradores para dominar la complejidad!

  • ¿Quizás tu colega es realmente mucho más inteligente que la mayoría de nosotros y puede pagar la sobrecarga de reinventar los patrones sin una disminución notable de la productividad?

  • Los argumentos de que "los programadores no entienden los patrones de diseño" parecen "no puedo explicar lo que estoy haciendo". O "No quiero discutir sobre mi propio diseño". Realmente creo que la creación de patrones podría aprovechar la comprensión general y permitir que los colegas con menos experiencia compartan opiniones valiosas. Pero tal vez su colega sénior quiera evitar eso.

Los enfoques en capas han demostrado ser superiores a otras arquitecturas en la mayoría de las aplicaciones empresariales. Los paquetes líderes de clase mundial se estructuran en torno a esta idea y superan a las arquitecturas artesanales en órdenes de magnitud. Martin Fowler presenta este enfoque en su excelente libro sobre "Patrones de arquitectura empresarial". Oh! Lo siento de nuevo: se trata de patrones probados; ninguna posibilidad en la vista de NIH de tu colega ;-)

    
respondido por el Christophe 31.08.2016 - 21:23
fuente
16

Una idea clave que mucha gente se pierde es que el diseño del software es contextual. Existe para alcanzar los objetivos de negocios, y diferentes objetivos pueden requerir diferentes enfoques. Dicho de otra manera, no hay un diseño que sea siempre el mejor, aunque siempre haya un mejor diseño.

Los patrones de diseño son soluciones estándar para problemas estándar. Sin embargo, si no tiene el problema, resolverlo es una pérdida de esfuerzo.

La diferencia clave entre el diseño de software ágil y en cascada es cuando se toman las decisiones de diseño. En cascada, reunimos todos los requisitos, identificamos los patrones de diseño que necesitamos y solo así comenzamos a codificar. En arquitectura ágil, seguimos el principio de YAGNI para diferir las decisiones de diseño hasta el último momento responsable, cuando sepamos lo más posible sobre la elección.

Es decir, en cascada, los patrones de diseño tienden a aplicarse si su necesidad es anticipada , en ágil, cuando realmente se necesitan . Como consecuencia, los proyectos ágiles tienden a aplicar patrones de diseño con menos frecuencia, porque no todas las necesidades previstas son reales.

    
respondido por el meriton 31.08.2016 - 08:13
fuente
8

Los patrones de diseño no se denominan realmente patrones de diseño porque prescriben qué hacer. Los patrones de diseño son patrones de diseño porque describen lo que se ha hecho anteriormente . Algunos desarrolladores diseñaron un método que cumplía bien una tarea en particular y pudieron aplicarlo a situaciones similares con resultados similares. Eso es todo lo que es. Muchos patrones tienen fortalezas y debilidades inherentes, y depende del desarrollador educado evaluar las necesidades tecnológicas y comerciales para determinar un patrón apropiado para aplicar.

En ese sentido, a menos que esté realmente comprometido a escribir un código único al 100%, donde no se puedan utilizar conceptos o implementaciones de un caso de uso a otro, es casi seguro que esté utilizando al menos algunos patrones de diseño. Es posible que no tengan nombres llamativos, como "Repositorio" o "Unidad de trabajo" o incluso "MVC", pero eso no los convierte en "no un patrón de diseño".

    
respondido por el Jeremy Holovacs 31.08.2016 - 21:42
fuente
6

Por lo general, me gusta pensar en el modo de, digamos, "navegación" utilizando el GPS. Cuando aprende "mejores prácticas" y "patrones de diseño", aprende a tomar la ruta de navegación GPS. Pero cuando conoce el área, a menudo aprenderá que conducir por un camino lateral lo llevará más allá de las áreas problemáticas, lo hará más rápido y / o mejor. Es lo mismo cuando se trata de estas cosas: la experiencia te permite deconstruir tu caja de herramientas y tomar atajos.

Los patrones de diseño de aprendizaje y las "mejores prácticas" de aprendizaje significan que obtiene una comprensión de la idea subyacente para poder elegir en una situación determinada. Debido a que las situaciones de la vida real a menudo son más complejas en comparación con las situaciones teóricas, a menudo tendrá limitaciones y problemas que no se encuentran en los libros de texto. Los clientes / clientes quieren su producto rápido y generalmente barato; Necesitas trabajar con código legado; Debe interactuar con herramientas de terceros que pueden ser cajas negras e ineficaces; y todo tipo de cosas. Su situación es específica: las mejores prácticas y los patrones son más generales.

Una de las principales razones por las que muchas personas en sitios como SE le darán respuestas de "mejores prácticas" y de "patrón de diseño" es porque están respondiendo en soluciones generales y abstractas y, por lo tanto, ayudan a proporcionar un lenguaje común para resolver Un tipo de problemas. Y para que aprendas.

Por lo tanto, los patrones de no diseño no son mal vistos en los entornos de desarrollo Agile; sin embargo, el desarrollo rara vez es lo suficientemente general y abstracto como para ajustarse perfectamente a un patrón y el desarrollador (experimentado) lo sabe.

    
respondido por el Allan S. Hansen 31.08.2016 - 08:33
fuente
5
  

Agregar un nuevo campo a la IU / base de datos / capa de datos toma de 2 a 3 horas, mientras que en su código toma 30 minutos.

Si desea "optimizar" un diseño, debe decir lo que está intentando optimizar.

Por ejemplo, una bicicleta de carreras es un vehículo optimizado ... y un Boeing 747 también es un vehículo optimizado ... pero están optimizados para un conjunto diferente de requisitos.

La idea del patrón "MVC", por ejemplo, se optimiza para cosas como:

  • Vistas diferentes del mismo modelo (la vista es independiente del modelo)
  • Cada capa puede desarrollarse por separado (por ejemplo, por equipos diferentes) y probarse por separado (pruebas unitarias) antes de la integración
  • etc.

Mientras que su código podría estar optimizando para otra cosa, por ejemplo:

  • Líneas de código mínimas
  • Es fácil para una persona hacer un cambio que afecta a todas las capas (al no tener capas realmente distintas)
  • etc.

Las descripciones de patrones comienzan con una descripción del problema que el patrón intenta resolver. Si piensa que es "una buena práctica" no usar un patrón específico, entonces (asumiendo que no es un patrón estúpido, asumiendo que es un patrón que a veces es útil) supongo que no tiene / experimenta el problema específico que ese patrón afirma para resolver, y / o tiene un problema diferente (mayor o más urgente, que compite) para el cual está tratando de optimizar.

    
respondido por el ChrisW 01.09.2016 - 13:01
fuente
4

Los patrones de diseño son herramientas. Al igual que las herramientas, hay dos formas de usarlas: la forma correcta y la forma incorrecta. Por ejemplo, si te doy un destornillador y un clavo y te pido que juntes dos trozos de madera, deberías pedirme un martillo. Los martillos se usan para clavos, mientras que los destornilladores se usan para tornillos.

Muy a menudo, un patrón de diseño se anuncia como One True Way, que a menudo solo es cierto cuando surgen problemas particulares. Los desarrolladores junior a menudo son como niños cuando encuentran algo nuevo para jugar; quieren aplicar ese patrón de diseño a todo . Y no hay nada intrínsecamente incorrecto en esto, siempre que aprendan que el Patrón A se aplica al Problema B, y que el Patrón C se aplica al Problema D. Así como no usa un destornillador para clavar clavos, no usa un patrón solo porque existe; utiliza el patrón porque es la mejor herramienta (conocida) para el trabajo.

La otra cara de los patrones son anti-patrones. Cosas que han demostrado ser malas una y otra vez, generalmente en términos de tiempo de ejecución o memoria. Sin embargo, tanto los patrones como los anti-patrones no son buenos para el desarrollador que no entiende por qué existen. A los desarrolladores les gusta pensar que lo que están haciendo es nuevo e inventivo, pero la mayoría de las veces no lo son. Probablemente se ha pensado antes. Las personas anteriores a ellos han creado los patrones debido a la experiencia.

Por supuesto, los desarrolladores junior a menudo parecen encontrar nuevas formas de hacer cosas viejas, y a veces esas formas son mejores. Sin embargo, con demasiada frecuencia termina siendo un caso del efecto Dunning-Kruger; el desarrollador sabe lo suficiente para crear un programa funcional, pero no entiende sus propias limitaciones. La única forma de superar esto parece ser a través de la experiencia, tanto positiva como negativa. Ignoran los patrones porque se creen superiores, pero no saben que, en realidad, 10.000 desarrolladores ya han usado un diseño específico y luego lo han descartado porque en realidad era malo.

Agile favorece "hacer las cosas de manera responsable" en lo que respecta a un rápido ajuste a las necesidades cambiantes de los clientes. No favorece los patrones de diseño ni los desprecia. Si un patrón es el método más rápido y confiable, entonces el desarrollador debe usarlo. Si un patrón en particular costara más tiempo que simplemente "lograrlo", es probable que esté bien usar algo que no es un patrón (asumiendo, por supuesto, que el rendimiento no está muy degradado, etc.). Si no se puede encontrar un patrón conocido, se prefiere el diseño propio antes que decirle a un cliente que "no". Los clientes, especialmente los clientes que pagan, generalmente tienen razón.

Cualquiera que afirme que los patrones son el Camino, o que los patrones son La Perdición de la Existencia, está equivocado. Los patrones son herramientas, destinadas a aplicarse a situaciones específicas, y tienen diferentes grados de éxito en función de las circunstancias. Esta es una Verdad, una que no depende de si eligió MVC o no, si usa Objetos de Transferencia de Datos, o no, etc. Lo que importa es implementar el código en un marco de tiempo razonablemente corto, que funcione razonablemente bien para los usuarios, y está razonablemente libre de errores lógicos.

Por lo general, , los patrones permitirán una forma coherente de diseño y tendrán un mejor rendimiento que ignorar todos los patrones en favor de escribir ideas 100% originales, pero no se pueden evitar todos los patrones. Por ejemplo, si y = x + 5, ¿realmente vas a escribir y = x + (5 * 3 + 15/3) / 4, solo para evitar el patrón de escritura x + 5? No tu no eres. Vas a escribir y = x + 5, y pasarás al siguiente problema.

La gente usa patrones todos los días y está bien . Lo que más importa es tener un código que sea lógicamente funcional, que rara vez se bloquee y que sea fácil de usar. Nada más importa más que eso.

    
respondido por el phyrfox 01.09.2016 - 10:28
fuente
2

No puedes 'evitar los patrones de diseño', excepto que supongo que al evitar diseñar cualquiera de las dos partes de tu sistema de la misma manera (lo cual no recomiendo y dudo que tu desarrollador senior esté haciendo). Lo que probablemente quiere decir es "evitar usar un diseño a ciegas solo porque se adhiere a un patrón de diseño". Pensar en lo que estás haciendo es definitivamente una "mejor práctica", y una universidad debería existir para enseñar; Lamentablemente, eso no parece estar sucediendo.

    
respondido por el Jonathan Cast 31.08.2016 - 17:33
fuente
2

Los patrones de diseño no son antitéticos a las prácticas ágiles. Lo que es antitético a las prácticas ágiles es usar patrones de diseño para usar patrones de diseño, la práctica común entre los recién graduados y estudiantes para pensar "cómo vamos a resolver este problema con un patrón de fábrica".
Agile significa elegir la mejor herramienta para el trabajo, NO tratar de dar forma al trabajo para que se ajuste a la herramienta que ha seleccionado.
Y a eso se reducen TODAS las prácticas de desarrollo del sentido común (aunque a menudo, por supuesto, tiene que hacer concesiones porque la selección de herramientas de las que puede elegir suele estar restringida por estándares corporativos, restricciones de licencia (como GPL y, a veces, otras herramientas de código abierto). no se puede usar, especialmente al compilar software para reventa), y cosas por el estilo.

Su colega / amigo probablemente objetó su código no porque use patrones de diseño per se, sino porque es una construcción artificial diseñada para mostrar el uso de un patrón específico cuando otro diseño hubiera sido mejor (aunque a menudo subjetivo, he (y sin duda muchos han visto muchos ejemplos en los que el uso forzado de un patrón de diseño específico llevó a un código feo, difícil de mantener y altamente ineficiente).

    
respondido por el jwenting 01.09.2016 - 13:16
fuente

Lea otras preguntas en las etiquetas