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

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 un código que es una pesadilla para trabajar porque fue escrito desde un libro de texto y no tiene en cuenta el mundo real. Agregar un nuevo campo a la capa de UI / base de datos / Datos lleva 2-3 horas, mientras que en su código tarda 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.

Luego está la idea de que la mayoría de los desarrolladores web en Canadá prefieren que su modelo de datos herede de las clases de Capa de datos, en lugar de mantenerlo aislado. Le pregunté: "¿No es estándar en la industria que el modelo se separe de la capa de datos?" Él dijo a veces, pero la mayoría de las personas aquí prefieren no hacerlo porque es demasiado trabajo.

Parece que su razonamiento para no codificar utilizando las mejores prácticas es porque es una pesadilla de mantenimiento, pocos de nuestros empleados lo entienden (además de mí), y es lento para trabajar si necesita sacar nuevas funciones o campos en unos pocos días ' hora.

Es muy extraño escuchar una opinión como esta, considerando que Stack Overflow alienta principalmente a las personas a seguir los estándares de la industria. ¿El problema es que constantemente nos vemos obligados a producir 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? Esa parece ser la esencia de lo que entiendo de esto.

¿Qué opinas de estas declaraciones?

Estas son las palabras de alguien que ha tenido éxito e ignora a las personas que intentan 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 enloquecen a las personas que saben lo que están haciendo. 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 sobre ellos sea más fácil. Un patrón que tiene un nombre no lo convierte en algo bueno. Lo hace una cosa reconocible.

Es probable que este tipo use patrones que ninguno de ustedes haya escuchado. Está bien, hasta que necesites hablar con él sobre cómo se hace algo. Tendrá que aprender a hablar con usted o usted tendrá que aprender a hablar con él. No tiene nada que ver con quién tiene "razón".

Muchos patrones de diseño, del tipo que usted y su amigo están describiendo, son solo 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 adaptarse a muchos escenarios de uso posibles, tienden a ser diseñados en exceso. El código sobredimensionado tiene un costo: debe leerlo, comprender lo que hace y comprender cómo funciona dentro del contexto de todo el sistema de software. En consecuencia, como con cualquier otra técnica de desarrollo de software, debe evaluar la técnica contra el costo de usarla y decidir si los beneficios exceden el costo.

En igualdad de condiciones, menos código siempre es mejor. He pasado por arquitecturas en capas donde literalmente tienes que hacer de tres a seis saltos a través de múltiples proyectos para encontrar cualquier código que sea interesante, es decir, un código que realmente logre algo más que agregar sobrecarga.

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 de patrones de software lo suficientemente bien como para aplicarlo adecuadamente a sus problemas de programación. Los desarrolladores sin experiencia ven estos patrones dentro del dominio de expertos; quieren ser vistos como expertos, y por eso intentan aprender y aplicar los patrones demasiado pronto, antes de que estén listos. Lo que realmente deberían hacer es enfocarse primero en aprender los fundamentos de la programación 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 comprender y aplicar los patrones correctamente.

Stackoverflow.SE y Programmers.SE animan principalmente a las personas a seguir las mejores prácticas como SOLID, no los estándares de la industria . Y lo creas o no, el estándar de facto de la industria es a menudo la arquitectura de la "gran bola de barro" , 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 usan en exceso, lo que tiene un cierto riesgo de crear código de ingeniería excesiva y difícil de mantener. Pero la respuesta a esto seguramente no es evitar o prohibir el uso de patrones de diseño (o herencia) por completo, 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 "ágilmente" o no.

1. Los patrones de diseño son solo nombres utilizados para comunicar ideas. A menudo me encontraba haciendo cosas que luego descubrí que tenían un nombre. Por lo tanto, no existe una "forma de patrón de diseño" en oposición a una "forma de patrón sin 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 encaja, 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. Se pueden ignorar todas las mejores prácticas y pautas si hay una razón suficiente. Las razones válidas incluyen el tiempo de desarrollo y las expectativas de la aplicación. Por ejemplo, soy consciente de que es malo codificar los valores (ejemplo estúpido), pero como prueba de concepto, las ventajas pueden ser mayores que 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 requerirse una refactorización.

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 Iterator o Visitor?"

Una buena descripció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á la primera vez que lo intente y qué formas comunes se han encontrado para evitar esos errores. . Entonces lees el patrón de diseño (o lo revisas de memoria) y luego continúas con tu trabajo. Lo que no puedes hacer es usar solo Clippy y asistentes.

Donde las personas sin experiencia pueden equivocarse y escribir 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, y tratan de diseñar el código al vincular el diseño patrones hasta que esté terminado. Otra táctica deficiente observada en la naturaleza es colocar un patrón de diseño en una situación en 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 al introducir una 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 busque 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 un desarrollo ágil es frustrante cuando no se descubren requisitos totalmente predecibles desde el principio. No puedo haber sido el único programador de C ++ que se divirtió mucho porque Java inicialmente rechazó los contenedores genéricos como innecesariamente complejos, luego los atornilló más tarde.

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

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

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

Por lo tanto, reconoció que cualquier patrón que requiera que toque muchos puntos diferentes en el código para agregar un campo es un mal patrón para el trabajo, "hace que sea fácil agregar campos", y no usó esos patrones. Las arquitecturas en capas de hecho pueden sufrir en ese sentido, y es incorrecto usar patrones de diseño sin apreciar sus desventajas.

Por el contrario, ¿cuánto tiempo lleva escribir una nueva interfaz de usuario en su diseño y cuánto tiempo lleva una arquitectura en capas? Si el proyecto requería que construyera e implementara constantemente nuevas IU sobre un modelo de datos fijo, en lugar de agregar constantemente campos, es de esperar que hubiera diseñado para eso. O también Pero, a pesar de todos sus beneficios, decir "estamos haciendo ágilmente" no significa que nunca tenga que hacer otra compensación.

Seleccionar de un menú de patrones de diseño ciertamente puede hacer que no pienses en las preocupaciones más importantes. Pero reconocer cuándo está escribiendo un Visitante y documentarlo o nombrarlo "Visitante" para ayudar a los lectores a obtenerlo rápidamente, no se interpone en nada. Escribir "esto es un visitante" en lugar de documentarlo correctamente es un terrible error por la razón que da su desarrollador principal: los programadores no lo entenderán. Incluso los programadores que saben qué es un visitante necesitan más información que simplemente "esto es un visitante".

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

Es perfectamente plausible que su código facilite agregar nuevos campos: también soy mucho más rápido para actualizar mi propio código que el código escrito por otros chicos. Pero esta velocidad a corto plazo no dice nada sobre la mantenibilidad y 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 si ha seguido una buena receta en el contexto incorrecto.

Evitar patrones de diseño es realmente sorprendente. En mis últimos 30 años de codificación y gestión de codificadores, los patrones de diseño ayudaron a poner palabras en las cosas que se hicieron instintivamente, ayudando así 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 aceleradores reales para dominar la complejidad!

• ¿Quizás su colega es realmente mucho más inteligente que la mayoría de nosotros y puede permitirse el lujo de reinventar patrones sin una disminución notable de la productividad?

• Los argumentos de que "los programadores no entienden los patrones de diseño" suenan como "Realmente no puedo explicar lo que estoy haciendo". O "No quiero discutir sobre mi propio diseño". Realmente creo que la modelización podría aprovechar la comprensión general, y podría permitir que colegas menos importantes compartan opiniones valiosas. Pero tal vez tu colega mayor 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 están estructurados en torno a esta idea y superan a las arquitecturas artesanales por orden 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 NIH de tu colega ;-)

Una idea clave que mucha gente echa de menos es que el diseño del software es contextual. Existe para alcanzar objetivos comerciales, y diferentes objetivos pueden requerir diferentes enfoques. Dicho de otra manera, no existe 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 en cascada y ágil es cuando se toman las decisiones de diseño. En cascada, reunimos todos los requisitos, identificamos qué patrones de diseño necesitamos y solo entonces comenzamos a codificar. En la arquitectura ágil, seguimos el precio de YAGNI para diferir las decisiones de diseño hasta el último momento responsable, cuando sepamos todo lo posible sobre la elección.

Es decir, en cascada, los patrones de diseño tienden a aplicarse si se anticipa su necesidad , en forma á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 anticipadas son reales.

Los patrones de diseño no se llaman 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 antes . Algunos desarrolladores o desarrolladores diseñaron un método que realizó bien una tarea 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 código 100% único, donde no se puedan utilizar conceptos o implementaciones de un caso de uso al siguiente, es casi seguro que esté utilizando al menos algunos patrones de diseño. Puede que no tengan nombres llamativos y comunes como "Repositorio" o "Unidad de trabajo" o incluso "MVC", pero eso no los convierte en "no un patrón de diseño".

Por lo general, me gusta pensar en la forma de, por ejemplo, "navegación" utilizando el GPS. Al aprender 'mejores prácticas' y 'patrones de diseño', aprende a tomar la ruta de navegación GPS. Pero cuando conozca el área, a menudo aprenderá que conducir por una carretera secundaria lo llevará a áreas problemáticas pasadas, lo llevará más rápido y / o mejor. Es lo mismo cuando se trata de estas cosas: la experiencia le permite deconstruir su caja de herramientas y tomar atajos.

Aprender los patrones de diseño y las "mejores prácticas" de aprendizaje significa que obtienes una comprensión de la idea subyacente para que puedas 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; Necesita trabajar con código heredado; Necesita 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 patrones son más generales.

Una razón importante por la que muchas personas en sitios como SE le darán respuestas de 'mejores prácticas' y respuestas de 'patrones de diseño' es que están respondiendo de manera general y con soluciones abstractas y, por lo tanto, ayuda a proporcionar un lenguaje común para resolver un tipo de problemas. Y para que aprendas.

Por lo tanto, no, los patrones de diseño no están mal vistos en los entornos de desarrollo ágil; 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.

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

Si desea "optimizar" un diseño, debe decir lo que está tratando de 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:

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

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

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

Las descripciones de los patrones comienzan con una descripción del problema que el patrón está destinado a resolver. Si cree que es "la mejor práctica" no utilizar un patrón específico, entonces (suponiendo que no sea un patrón estúpido, suponiendo que sea un patrón que sea útil a veces) supongo que no tiene / experimenta el problema específico que ese patrón afirma para resolver, y / o tiene un problema diferente (más grande o más urgente, competidor) para el que está tratando de optimizar.

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

Con demasiada frecuencia, 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 malo en ello, siempre y cuando eventualmente aprendan que el Patrón A se aplica al Problema B, y 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; usa el patrón porque es la mejor herramienta (conocida) para el trabajo.

La otra cara de los patrones son los antipatrones. Cosas que han demostrado una y otra vez ser malas, generalmente en términos de tiempo de ejecución o memoria. Sin embargo, tanto los patrones como los antipatrones 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. Es probable que se haya pensado antes. Las personas antes que ellos han creado los patrones debido a la experiencia.

Por supuesto, los desarrolladores junior a menudo parecen encontrar nuevas formas de hacer las 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 comprende 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 creen que son superiores, pero no saben que, en realidad, 10.000 desarrolladores ya han utilizado un diseño específico, y luego lo descartaron porque era realmente malo.

Agile favorece "hacer las cosas de manera responsable" en lo que respecta a adaptarse rápidamente a las necesidades cambiantes del cliente. 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 particular costaría más tiempo que simplemente "hacerlo", usar algo que no sea un patrón probablemente esté bien (suponiendo, por supuesto, que el rendimiento no se vea gravemente degradado, etc.). Si no se puede encontrar ningún patrón conocido, se prefiere diseñar el suyo propio antes que decirle a un cliente "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 sean La Perdición de la Existencia, está equivocado. Los patrones son herramientas destinadas a ser aplicadas a situaciones específicas y tienen diversos grados de éxito según las circunstancias. Esta es una Verdad, una que no depende de si elige MVC o no, si usa Data Transfer Objects, o no, etc. Lo que importa es implementar 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 funcionarán mejor que ignorar todos los patrones a favor de escribir ideas 100% originales, pero no puede evitar todos los patrones. Por ejemplo, si y = x + 5, ¿realmente va 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 eso está bien . Lo que más importa es tener un código que sea lógicamente funcional, raramente se cuelgue y sea fácil de usar. Nada más importa más que eso.

No puede 'evitar patrones de diseño', excepto que supongo que evite diseñar dos partes de su sistema de la misma manera (lo cual no recomiendo y dudo que su desarrollador senior lo esté haciendo). Lo que probablemente quiere decir es 'evitar el uso a ciegas de un diseño 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; tristemente, eso no parece estar sucediendo.

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 en aras de usar patrones de diseño, la práctica común entre los recién graduados y los estudiantes para pensar en la forma de "cómo vamos a resolver este problema usando un patrón de fábrica".

Ágil significa elegir la mejor herramienta para el trabajo, NO tratar de darle forma al trabajo para que se ajuste a la herramienta que ha seleccionado.
Y eso es a lo que se reducen TODAS las prácticas de desarrollo de sentido común (aunque a menudo, por supuesto, tiene que hacer compromisos porque la selección de herramientas entre las que puede elegir generalmente está restringida por estándares corporativos, restricciones de licencia (como GPL y, a veces, otras herramientas de código abierto a menudo) no se puede usar, especialmente cuando se construye software para reventa), y cosas así.

Su colega / amigo probablemente se opuso a su código no porque usa 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 muchos conmigo sin duda) han visto muchos ejemplos en los que el uso forzado de un patrón de diseño específico condujo a un código feo, difícil de mantener y altamente ineficiente).