¿Pudiste implementar patrones de diseño en plazos ajustados?

Me pregunto, en plazos ajustados, ¿quién tiene tiempo para implementar patrones de diseño? Es mucho más trabajo y sobrecarga de programación para hacerlo bien la primera vez y dentro del marco de tiempo. Sé que tiene ventajas a largo plazo, pero si pudo implementar cualquier patrón de diseño correctamente cuando el cliente está sentado sobre su cabeza y la presión está creciendo.

Creo que una vez que se lance su primera versión y tenga suficiente tiempo para la próxima versión, puede pensar en mejorar la calidad del código y la capacidad de administración con patrones de diseño.

Es mucho más trabajo y sobrecarga de programación para hacerlo bien la primera vez y dentro del marco de tiempo.

Eso es falso

Sin el beneficio de que alguien ya haya pensado en el patrón de diseño, y lo explique y documente, sería el doble de difícil.

Un patrón de diseño simplifica todo pensar, preguntarse y decidir.

No tienes que inventar algo nuevo. Puede usar algo que usted y los demás ya entiendan bien.

Los patrones de diseño te permiten pensar menos. Ese es realmente el punto completo. Hay una pequeña dicotimia falsa implícita en la pregunta. Sugiere que utilice patrones de diseño o que no utilice ningún patrón. La verdadera opción es entre usar un patrón establecido o un patrón hecho en casa. A veces, su diseño será mejor que el enfoque recomendado, pero ... generalmente no lo será. ¿Por qué hacer todo el trabajo de resolver un problema que ya se ha resuelto bien? Su propia versión a medio cocer casi nunca será tan buena, y tiene que desperdiciar toda esa brainergy pensando en ello.

En mi experiencia, rápido y sucio es un oxímoron. Cualquier tiempo que pueda ahorrar escatimando en el diseño casi siempre se consume mediante depuración adicional.

No se comprometa a una fecha límite que no le dé suficiente tiempo para hacer las cosas bien. Eventualmente, tiene que pagar la deuda técnica, y cuanto más código tenga antes de comenzar a refactorizar las cosas en un diseño sensato, más difícil será. Eso significa aún más trabajo y gastos generales de programación.

La lista de patrones de diseño es muy larga (a la gente le gusta dar nombres a las cosas). Incluso si no está pensando en "Ok, aquí estoy usando _ aquí", lo que probablemente esté haciendo es un patrón que alguien ha nombrado. Cuanto más programes, más tendrás una idea sobre cómo hacer algo y menos tendrás que preocuparte por los patrones que estás utilizando.

Creo que una vez que se lance su primera versión y tenga suficiente tiempo para la próxima versión, puede pensar en mejorar la calidad del código y la capacidad de administración con patrones de diseño.

Comparto una situación similar. Para el mantenimiento de las aplicaciones, puede ser necesaria una amplia refactorización para que el patrón de diseño valga la pena. Si hay un gran tiempo de inactividad a la vuelta de la esquina, lo mejor es posponerlo hasta que tenga tiempo de solucionar el problema.

Especialmente si el cliente está exigiendo un producto ayer. El triángulo de calidad del software existe tanto si lo reconoce como si lo conoce. "Hacer las cosas bien la primera vez" a menudo requiere una gran planificación inicial que incluye buenos requisitos y un bajo alcance. Esto significa que el cliente debe estar dispuesto a participar activamente en el éxito compartido del proyecto.

También tenga en cuenta que OO 101 requiere uno para construir una sección hasta que se completen los requisitos. ENTONCES refactorice, de lo contrario solo está girando las ruedas.

No es más trabajo y gastos generales hacerlo bien la primera vez.

Si no está roto, es probable que no se arregle. Y no correcto no necesariamente significa roto. Siempre habrá algo más que debe hacerse. Por lo tanto, pasará mucho más tiempo apoyándolo y menos tiempo capaz de corregirlo o crear algo nuevo.

No solo que hacerlo bien no lleva más tiempo que hacerlo mal. Puede aparecer a corto plazo como si no estuvieras cumpliendo con los plazos o los hitos de la colección. Pero al final todo se junta en aproximadamente la misma cantidad de tiempo. Pero la calidad del primer lanzamiento de control de calidad superará con creces el primer lanzamiento de qa del asiento del pantalón. Esto reducirá el retrabajo antes del lanzamiento. Al final, hacerlo bien no solo empata, gana cada vez.

Lo más probable es que, si le toma más tiempo implementar un patrón de diseño, entonces el patrón que está tratando de usar no se ajusta bien al problema que está tratando de resolver. No obtiene "puntos de bonificación" en su próxima revisión de código por implementar un nuevo patrón, el punto es poder identificar más fácilmente formas comprobadas de resolver problemas comunes. Los patrones de diseño son una forma para que las personas compartan un enfoque de estos problemas y puedan hablar de ello en términos comunes.

Es muy probable que ya esté utilizando patrones de diseño, son solo una clasificación formal de conceptos arquitectónicos recurrentes.

Para usar una analogía de construcción, en la que podría referirse a cierta parte de su edificio como "la parte que evita la lluvia y el calor", alguien versado en la construcción simplemente llamaría a esa parte "el techo". No hay ninguna desventaja que pueda ver al implementar un "techo" en una casa en lugar de implementar una "parte que evita la lluvia y el calor".

La sobrecarga principal es descubrir qué patrones de diseño se ajustan a dónde, ya que a menudo son bastante abstractos cuando se ven fuera de contexto. Es casi seguro que usa Facade / Factory a menos que esté escribiendo procedimientos. Encontré a Observador, Estrategia y Fábrica el más fácil de entender.

Como otros han señalado, hacerlo bien la primera vez es, por supuesto, más barato. Pero también señalaría que cualquier construcción de programación cae en algún lugar del espectro del patrón anti patrón. O estás implementando algo de manera ordenada o no; El código infestado de 'goto' sigue un patrón, es algo que se reconoció desde el principio como potencialmente dañino. Pero tenga en cuenta que todo el código se reduce a saltos y ramificaciones en algún momento del ciclo de compilación. No hay nada inherentemente malo en saltar: simplemente termina haciendo que los proyectos más grandes sean más difíciles de entender.

Es fácil dejarse engañar por patrones que parecen triviales para casos de uso simples. Tan pronto como comience a necesitar más flexibilidad, la mayoría de los patrones frágiles se degenerarán en patrones anti. Por lo tanto, mi regla es solo escribir código que pueda entender y tener una posibilidad razonable de depuración. Si decido aplicar un patrón inteligente a ciegas, tengo que ser al menos tan inteligente como el código del patrón para depurarlo. Entonces, la clave es asegurarse de que está aislando y utilizando patrones que se aplican específicamente a su problema directamente, que está abordando el problema en el nivel adecuado de abstracción y que puede comprender y depurar cada línea de su código.

Una clave aquí es lograr el equilibrio correcto entre los requisitos a corto y largo plazo. Tenga en cuenta que escribir un buen código rápidamente es algo que a partir de patrones bien entendidos ciertamente puede ayudar: el código de espagueti puede parecer más rápido, especialmente al principio. Pero verá rápidamente las limitaciones de los anti patrones en cualquier proyecto más grande, donde la descomposición, la modularidad, etc., se vuelven increíblemente importantes.

Voy contra la corriente y digo que pueden ayudar, pero que a menudo duelen cuando se dan las circunstancias que usted describe.

Ayudan SI está familiarizado con ellos Y (tiene una buena cobertura de prueba de todas las partes que serán efectivas O esto es codificación de campo verde).

Pero, realmente, si está haciendo esta pregunta, entonces usted tampoco: A. No use los patrones como una forma natural de hacer las cosas (porque si lo hiciera, no pensaría en preguntar, simplemente lo haría sin pensar) O B. El código es tan incompatible con la implementación del patrón en la cantidad asignada que simplemente no es realista usar el patrón.

No. Parece que lleva tiempo aplicar las mejores prácticas (patrones de diseño, MVC, lo que sea) a un problema, y ​​no es que yo u otros desarrolladores no conozcan bien los patrones de diseño.

Algunas de estas buenas prácticas pueden aplicarse incluso si tiene prisa, pero, un buen sistema, lleva tiempo diseñarlas.