YAGNI - La práctica ágil, que no debe ser nombrado? [cerrado]

Question

Como he absorbido cada vez más ágil pensando en mi forma de trabajar, YAGNI ( "que no van a necesitar") parece ser cada vez más importante. Me parece que una de las reglas más eficaces para el filtrado de las prioridades equivocadas y decidir qué no a trabajar a continuación.

Sin embargo, YAGNI parece ser un concepto que está apenas susurraba aquí en SO. Me encontré con la búsqueda obligatoria, y éste sólo aparece en un título de la pregunta -. Y luego en un papel secundario

¿Por qué es esto? ¿Estoy sobreestimar su importancia?

exención de responsabilidad. Para anticiparse a las respuestas Estoy seguro de que obtendrá en la objeción, quiero destacar que es YAGNI es el contrario de rápido y sucio . Se le anima a centrar su valioso tiempo y esfuerzo en conseguir las partes que necesita a la derecha.

Aquí hay algunas preguntas en curso fuera de la parte superior se podría preguntar.

¿Mis pruebas unitarias seleccionados en base a las necesidades del usuario, o estructura de marco?

¿Puedo instalar (y las pruebas y el mantenimiento) pruebas unitarias que sólo están allí porque caen fuera del marco?

¿Qué parte del código generado por mi marco tengo nunca vistos (pero todavía podría muérdeme un día, a pesar de que YAGNI)?

¿Cuánto estoy gastando trabajando en mis herramientas más que el problema del usuario el tiempo?

Cuando par de programación, el valor de la función del observador se encuentra a menudo en "YAGNI".

¿Utiliza una herramienta de ABM? ¿Le permite (o mejor dicho, animar) que permite utilizarla como una herramienta _RU_, o una herramienta C__D, o está creando cuatro piezas de código (más cuatro pruebas unitarias) cuando sólo se necesita uno o dos?

Answer 1

TDD ha subsumido YAGNI de una manera. Si lo hace TDD correctamente, es decir, solamente escribir aquellas pruebas que dan lugar a la funcionalidad requerida, a continuación, desarrollar el código más simple para pasar la prueba, entonces usted está siguiendo el principio YAGNI por defecto. En mi experiencia, es sólo cuando llegue el borde del área TDD y empezar a escribir código antes de las pruebas, las pruebas para las cosas que realmente no necesita, o código que es más que la forma más sencilla posible para pasar la prueba de que violo YAGNI .

En mi experiencia de este último es mi paso en falso más común cuando se hace TDD - tiendo a ir por delante y empezar a escribir código para pasar la siguiente prueba. Que a menudo resulta en mí comprometer las pruebas restantes por tener una idea preconcebida sobre la base de mi código en lugar de los requisitos de lo que tiene que ser probado.

Tu caso es distinto.

Answer 2

YAGNI y un beso (mantenerlo simple, estúpido) son esencialmente el mismo principio. Por desgracia, veo BESO mencionado tan a menudo como lo veo "YAGNI".

En mi parte del desierto, la causa más común de las demoras y fracasos de proyectos es una mala ejecución de los componentes innecesarios, por lo que estoy de acuerdo con su sentimiento básico.

Answer 3

La libertad de cambiar de unidades YAGNI . En un proyecto de cascada, el mantra es controlar alcance. Ámbito de aplicación se controla mediante el establecimiento de un contrato con el cliente. En consecuencia, el cliente rellena todo lo que pueden pensar en el documento de alcance a sabiendas de que los cambios en el alcance será difícil una vez que el contrato ha sido firmado. Como resultado, se termina con las aplicaciones que tiene una larga lista de características, no un conjunto de características que tienen valor.

Con un proyecto ágil, el dueño del producto construye una pila de producto priorizada. El equipo de desarrollo se basa características dependiendo de la prioridad, es decir, el valor. Como resultado, las cosas más importantes se construyó en primer lugar. Se termina con una aplicación que tiene características que son valorados por los usuarios. La materia que no es importante cae de la lista o no se hacen. Es decir YAGNI.

Mientras YAGNI no es una práctica, es un resultado de la lista priorizada atraso. El socio de negocios valora la flexibilidad que ofrece el negocio dado que pueden cambiar y nuevas prioridades de la cartera de productos de una iteración a otra. Es suficiente para explicar que YAGNI es el beneficio obtenido cuando aceptamos fácilmente el cambio, incluso tarde en el proceso.

Answer 4

El problema que encuentro es que la gente tiende a escribir la pala incluso fábricas, utilizando contenedores DI (a menos que ya haya que tiene en su base de código) bajo YAGNI. Estoy de acuerdo con JB Rey allí. Para muchas personas que he trabajado YAGNI parece ser la licencia para cortar las esquinas / escribir código descuidado.

Por ejemplo, yo estaba escribiendo una API PinPad para abstraer PINPad múltiples modelos / fabricantes. He encontrado a menos que haya la estructura general, no puedo escribir ni mis pruebas unitarias. Puede ser que no soy un practicante muy experimentado de TDD. Estoy seguro de que habrá diferentes opiniones sobre si lo que hice es YAGNI o no.

Answer 5

He visto una gran cantidad de puestos de SO referencia a la optimización prematura, que es una forma de YAGNI, o al menos ydniy (que no lo necesita todavía).

Answer 6

No veo YAGNI como lo contrario de rápido y sucio-, de verdad. Se está haciendo precisamente lo que se necesita y no más y no planificar como el software de alguien escribe tiene que durar 50 años. Puede venir rara vez porque no son realmente tan muchas preguntas que hacer alrededor de él, al menos en mi opinión. De manera similar a las reglas "No te repitas" y "mantenerlo simple, estúpido" que se convierten en común, pero no necesariamente están diseccionados y analizados en 101 maneras. Algunas cosas son bastante simple que por lo general se incorporó poco después de hacer un poco de práctica. Algunas cosas se desarrollaron entre bastidores y si a su vez alrededor y mire se pueden notar ellas pueden ser otra manera de expresar las cosas.