Principios SÓLIDOS vs YAGNI

¿Cuándo se convierten los principios SÓLIDOS en YAGNI?

Como programadores, hacemos compensaciones todo el tiempo, entre complejidad, mantenibilidad, tiempo de construcción, etc. Entre otros, dos de las pautas más inteligentes para tomar decisiones son, en mi opinión, los principios SÓLIDOS y YAGNI. Si no lo necesitas no lo construyas y mantenlo limpio.

Ahora, por ejemplo, cuando veo la serie Dimecast en SOLID , veo que comienza como un programa bastante simple y termina como bastante complejo (al final sí, la complejidad también está en el ojo del espectador), pero aún así Me pregunto: ¿cuándo los principios SOLID se convierten en algo que no necesitas? Todos los principios sólidos son formas de trabajo que permiten el uso para realizar cambios en una etapa posterior. Pero, ¿y si el problema a resolver es bastante simple y es una aplicación descartable, entonces qué? ¿O son los principios SÓLIDOS algo que siempre se aplican?

Como se preguntó en los comentarios:

• Principios SÓLIDOS
• YAGNI

Siempre es difícil juzgar un enfoque basado en un screencast, ya que los problemas elegidos para las demostraciones suelen ser tan pequeños que aplicar principios como SOLID rápidamente hace que parezca que la solución está completamente diseñada.

Yo diría que los principios SOLIDOS son casi siempre útiles. Una vez que te vuelves competente con ellos, usarlos no parece algo en lo que tengas que pensar deliberadamente. Simplemente se vuelve natural. He visto muchas aplicaciones desechables convertirse en algo más que eso, así que ahora tengo miedo de decir que voy a tirar algo, porque nunca se sabe.

El enfoque que suelo adoptar es que si escribo una aplicación simple para una tarea en particular, a veces renunciaré a los principios de renombre en favor de algunas líneas de código que funcionen. Si descubro que vuelvo a esa aplicación para hacer más cambios, me tomaré el tiempo para hacerlo SÓLIDO (al menos un poco, ya que una aplicación del 100% de los principios rara vez es factible).

En aplicaciones más grandes, empiezo con poco y, a medida que el programa evoluciona, aplico principios SÓLIDOS cuando sea posible. De esta manera no intento diseñar todo por adelantado hasta la última enumeración. Ese, para mí, es el punto dulce donde coexisten YAGNI y SOLID.

Piense en primer lugar en el problema en cuestión. Si aplica ciegamente los principios de YAGNI o SOLID, puede lastimarse más adelante. Algo que espero que todos podamos entender es que no existe un enfoque de diseño "único" que se adapte a todos los problemas. Puede ver evidencia de eso cuando una tienda vende un sombrero anunciado como "talla única", pero no se ajusta a su cabeza. Es demasiado grande o demasiado pequeño.

En cambio, es mejor comprender los principios y problemas que SOLID intenta abordar; así como los principios y problemas que YAGNI intenta abordar. Descubrirá que uno está relacionado con la arquitectura de su aplicación y el otro está relacionado con el proceso de desarrollo en su conjunto. Si bien puede haber superposición en algunos casos, son problemas claramente diferentes.

YAGNI (No lo vas a necesitar [siglas estadounidenses pintorescas]) se preocupa por ahorrar tiempo al desarrollador agregando cimientos de hormigón reforzado con acero a un puente que solo está destinado a atravesar un arroyo de 3 pies de ancho cuando un puente de madera más simple multa. Si estamos atravesando un río de una milla de ancho y necesitamos soportar varios remolques de tractores, por supuesto, necesitaríamos ese trabajo de base adicional. En esencia, YAGNI le está diciendo que mire la imagen más grande y el diseño para las necesidades actuales . Está abordando el problema de hacer algo demasiado complicado porque anticipamos una serie de necesidades potenciales que el cliente aún no ha identificado.

SOLID se preocupa por cómo nos aseguramos de que las piezas del puente encajen correctamente y puedan mantenerse a lo largo del tiempo. Puede aplicar principios SÓLIDOS al puente de madera, así como al puente de hormigón armado de acero.

En resumen, estos dos conceptos no están necesariamente en conflicto entre sí. Cuando te encuentras con una situación en la que crees que están, es hora de echar un vistazo al panorama general. Dependiendo de su conclusión, puede decidir eliminar una parte de los principios SÓLIDOS o puede decidir que realmente lo necesita.

Los principios SÓLIDOS no son necesarios cuando se trata de una aplicación desechable; de lo contrario, siempre son necesarios.

SOLID y YAGNI no están reñidos: un buen diseño de clase hace que la aplicación sea más fácil de mantener. YAGNI simplemente declara que no debe agregar la capacidad para que su aplicación sea esta monstruosidad configurable que puede hacer todo bajo el sol, a menos que realmente lo necesite.

Es la diferencia entre una clase de automóvil que tiene límites bien definidos (SÓLIDO) y una clase de automóvil que tiene la capacidad de autocuración (YAGNI) antes de que el cliente lo solicite.

¡Nada se aplica siempre! ¡No dejes que los astronautas de la arquitectura te asusten! Lo importante es tratar de comprender qué problemas están tratando de resolver estos principios para que pueda tomar una decisión informada sobre su aplicación.

Recientemente estaba tratando de entender cuándo debería usar el Principio de responsabilidad única ( esto es lo que se me ocurrió).

¡Espero que esto ayude!

Hay una cita atribuida a Einstein (probablemente una variación de una real ):

"Todo debe hacerse lo más simple posible, pero no más simple".

Y ese es más o menos el enfoque que adopto cuando me enfrento a la compensación SOLID vs YAGNI: aplíquelos alternativamente, porque nunca se sabe si un programa es un código 'desechable' o no. Entonces, solo agregue una capa de suciedad que funcione, luego púlsela a una interfaz más limpia ... y repita hasta que converja al nivel correcto de entropía. Ojalá.

Hay muchas formas de diseñar un programa para un problema dado; SOLID es un intento de identificar las propiedades de un buen diseño. Se supone que el uso adecuado de SOLID dará como resultado un programa que sea más fácil de razonar y modificar.

YAGNI y KISS están preocupados por el alcance de las características. Un programa que resuelve más tipos de problemas es más complejo y abstracto. Si no necesita esa generalidad, ha dedicado tiempo y esfuerzo a crear código que es más difícil de entender y mantener pero que no ofrece valor agregado.

Un programa bien diseñado no se centra necesariamente solo en las características que necesita. Un programa que se centra solo en las características que necesita no está necesariamente bien diseñado. No hay compensación, solo dos ejes ortogonales en el espacio de toma de decisiones. Un programa ideal es modular y solo tiene características esenciales.

Creo que deberías iniciar YAGNI y, cuando sea necesario, SOLIDARlo.

Lo que quiero decir es que SOLID está allí, así que cuando agregue una nueva clase no tendrá que refactorizar, simplemente cambie una implementación (por ejemplo), bueno, en mi opinión, escriba su código simplemente y cuando vea que está cambiando cosas: cámbielo con SOLID (es decir, se supone que la refactorización temida de SOLID lo salvará, no es tan malo cuando apenas está comenzando).

No está perdiendo el tiempo porque tendría que hacer el trabajo de todos modos (al principio) y donde sea necesario, su código es agradable y ordenado.

Supongo que podría llamarse evaluación perezosa de SOLID.