unit testing - tradicionales - YAGNI: ¿la práctica ágil que no debe nombrarse?
scrum (6)
He visto una gran cantidad de publicaciones sobre SO haciendo referencia a la optimización prematura, que es una forma de yagni, o al menos ydniy (aún no lo necesita).
A medida que he absorbido cada vez más el pensamiento ágil en la forma en que trabajo, yagni ("no vas a necesitarlo") parece ser cada vez más importante. Me parece que es una de las reglas más efectivas para filtrar las prioridades equivocadas y decidir en qué no trabajar a continuación.
Sin embargo, yagni parece ser un concepto que apenas se susurra aquí en SO. Ejecuté la búsqueda obligatoria, y solo aparece en un título de pregunta, y luego en un rol secundario.
¿Por qué es esto? ¿Estoy sobreestimando su importancia?
Renuncia. Para evitar las respuestas, estoy seguro de que objetaré, permítanme enfatizar que yagni es lo opuesto a lo rápido y lo sucio . Lo alienta a enfocar su valioso tiempo y esfuerzo en obtener las partes que SI LO necesita.
Aquí hay algunas preguntas continuas fuera de lo común que uno podría preguntar.
¿Se seleccionan mis Pruebas unitarias en función de los requisitos del usuario o la estructura del marco?
¿Estoy instalando (y probando y manteniendo) pruebas unitarias que solo están allí porque se salen del marco?
¿Cuánto del código generado por mi marco de trabajo nunca he visto (pero todavía podría morderme algún día, aunque yagni)?
¿Cuánto tiempo estoy gastando trabajando en mis herramientas en lugar del problema del usuario?
Cuando se programa el par, el valor del rol del observador a menudo se encuentra en "yagni".
¿Usas una herramienta CRUD? ¿Le permite (más aún, lo alienta) usarlo como una herramienta _RU_, o una herramienta C__D, o está creando cuatro códigos (más cuatro pruebas unitarias) cuando solo necesita uno o dos?
TDD ha subsumido YAGNI de una manera. Si hace TDD correctamente, es decir, solo escribe aquellas pruebas que dan como resultado la funcionalidad requerida, luego desarrolla el código más simple para pasar la prueba, entonces está siguiendo el principio de YAGNI por defecto. En mi experiencia, solo cuando salgo del cuadro TDD y empiezo a escribir código antes de las pruebas, pruebo las cosas que realmente no necesito, o código que es más que la manera más simple de pasar el examen que violé a YAGNI .
En mi experiencia, este último es mi error más común al hacer TDD: tiendo a adelantarme y comenzar a escribir código para pasar la siguiente prueba. Eso a menudo me lleva a comprometer las pruebas restantes al tener una idea preconcebida basada en mi código en lugar de los requisitos de lo que debe probarse.
YMMV.
Yagni y KISS (mantenlo simple, estúpido) son esencialmente el mismo principio. Desafortunadamente, veo a KISS mencionado tantas veces como veo "yagni".
En mi parte de la vida silvestre, la causa más común de retrasos y fallas en los proyectos es la mala ejecución de los componentes innecesarios, por lo que estoy de acuerdo con su sentimiento básico.
El problema que encuentro es que las personas tienden a agrupar incluso fábricas de escritura, usando contenedores DI (a menos que ya tengas eso en tu base de código) bajo YAGNI. Estoy de acuerdo con JB King allí. Para muchas personas que he trabajado con YAGNI parece ser la licencia para cortar esquinas / escribir código descuidado.
Por ejemplo, estaba escribiendo una API de PinPad para abstraer PINPad de múltiples modelos / fabricantes. Descubrí que a menos que tenga la estructura general, no puedo escribir ni siquiera mis Pruebas Unitarias. Puede ser que no sea un experto en TDD. Estoy seguro de que habrá opiniones diferentes sobre si lo que hice es YAGNI o no.
No veo a YAGNI como lo opuesto a rápido y sucio, realmente. Está haciendo exactamente lo que se necesita y no más, y no planea que el software que alguien escribe tenga una duración de 50 años. Puede ser raro porque en realidad no hay tantas preguntas que hacer, al menos en mi mente. Similar a las reglas "no te repitas" y "hazlo simple, estúpido" que se vuelven comunes pero que no necesariamente se analizan y analizan de 101 maneras. Algunas cosas son tan simples que por lo general se obtienen poco después de hacer un poco de práctica. Algunas cosas se desarrollan detrás de escena y si te das la vuelta y miras puedes notar que pueden ser otra forma de decir las cosas.
La libertad de cambiar impulsa a YAGNI . En un proyecto de cascada, el mantra es el alcance de control. El alcance se controla estableciendo un contrato con el cliente. En consecuencia, el cliente incluye todo lo que se le ocurre en el documento de alcance, sabiendo que los cambios en el alcance serán difíciles una vez que se haya firmado el contrato. Como resultado, terminas con aplicaciones que tienen una larga lista de características, no un conjunto de características que tienen valor.
Con un proyecto ágil, el propietario del producto crea una cartera de pedidos de productos priorizados. El equipo de desarrollo construye características basadas en la prioridad, es decir, el valor. Como resultado, las cosas más importantes se construyen primero. Usted termina con una aplicación que tiene características que son valoradas por los usuarios. Lo que no es importante cae fuera de la lista o no se hace. Eso es YAGNI.
Si bien YAGNI no es una práctica, es el resultado de la lista de atrasos prioritarios. El socio comercial valora la flexibilidad que ofrece la empresa dado que puede cambiar y priorizar la acumulación de productos desde la iteración hasta la iteración. Es suficiente para explicar que YAGNI es el beneficio obtenido cuando aceptamos el cambio, incluso más tarde en el proceso.