¿Cuándo violar YAGNI?

Question

El YAGNI "principio" establece que no debe centrarse en proporcionar funcionalidad antes de lo necesario ya que "no lo va a necesitar" de todos modos.

Suelo tender a usar el sentido común por encima de cualquier regla, no importa pero algunas veces siento que es útil diseñar en exceso o probar algo en el futuro si tiene buenas razones, incluso si es posible que nunca lo haga usarlo

El caso real que tengo en mis manos en este momento es más o menos así:

Tengo una aplicación que tiene que correr a través de una sencilla protocolo de comunicación propietaria (nivel OSI 4). Este protocolo tiene un conjunto de características deseables (como la siguiente especificación NORM) que proporcionan robustez a la aplicación pero que no son estrictamente necesarias (la multidifusión UDP podría funcionar aceptablemente).

También existe el hecho de que la aplicación probablemente (pero no seguramente) sea utilizada por otros clientes en el futuro que no tendrán acceso a la solución propietaria y, por lo tanto, necesitarán otra solución. Sé de hecho que la probabilidad de que otro cliente para la aplicación sea alto.

Entonces, ¿qué piensas? ¿Debo simplemente diseñar para el protocolo patentado y dejar la refactorización, la extracción de la interfaz y demás para cuando realmente lo necesite o debería diseñar ahora pensando en el futuro (no tan lejano)?

Nota: Para que quede claro, estoy interesado en escuchar todo tipo de opiniones a la pregunta general (cuando se viola a YAGNI), pero realmente me gustaría algún consejo o pensamientos en mi dilema actual :)

Answer 1

mi humilde opinión

• Yo diría que ir YAGNI primero. Haz que funcione sin la especificación NORM usando 'lo más simple que funcionaría'.
• A continuación compare si el costo de hacer los 'cambios de diseño' en el futuro es significativamente mayor que hacer el cambio ahora. ¿Es su solución actual reversible? Si puede hacer el cambio fácilmente mañana o después de un par de meses, no lo haga ahora. Si no necesita tomar una decisión de diseño irreversible ahora ...retraso hasta el último momento responsable (para que tenga más información para tomar una mejor decisión)

Para cerrar si sabe con un grado considerable de certainity que algo está en el horizonte y añadiendo posteriormente va ser un dolor, no seas un avestruz .. diseño para ello.
p. Ej. Sé que los registros de diagnóstico serían necesarios antes de que el producto se envíe. Agregar el código de registro después de un mes sería mucho más esfuerzo que sumarlo hoy mientras escribo cada función ... así que este sería un caso en el que anularía YAGNI aunque no necesite registros en este momento.

See-also: T. & Los libros magros de M. Poppendieck son mejores para explicar el dilema de la viñeta n. ° 2 anterior.

Answer 2

Creo que YAGNI podría ser inapropiado cuando quieres aprender algo :) YAGNI es bueno para los profesionales, pero no para los estudiantes. Cuando quieres aprender, siempre lo necesitarás.

Answer 3

No me preocupe. El hecho de que tenga conocimiento de "YAGNI" significa que ya está pensando de forma pragmática.

Yo diría que, independientemente de lo que se publique aquí, es estadísticamente más probable que se presente un código mejor que alguien que no está analizando sus prácticas del mismo modo.

Answer 4

Estructurar bien el programa (abstracción, etc.) no es algo a lo que YAGNI se aplica. Siempre quieres estructurar bien tu código.

Solo para aclarar, creo que su situación actual se debe a la aplicación excesiva de YAGNI. Estructurar su código de tal forma que tenga una biblioteca reutilizable para usar este protocolo es una buena práctica de programación. YAGNI no aplica.

Answer 5

Creo que es bastante simple y obvia:

Violar YAGNI cuando se sabe que, en plena certeza, Usted va a necesitar Se

Answer 6

La razón YAGNI aplica al código es que el el costo del cambio es bajo Con el código bueno y bien refactorizado agregar una característica más tarde es normalmente barato. Esto es diferente de decir construcción.

En el caso de los protocolos, agregar cambios más tarde generalmente no es barato. Las versiones antiguas se rompen, puede provocar fallas de comunicación y una matriz de prueba N^2, ya que tiene que probar cada versión con cada otra versión. Compare esto con bases de código individuales donde las nuevas versiones solo tienen que funcionar consigo mismas.

En su caso, para el diseño del protocolo, no recomendaría YAGNI.

Answer 7

Estoy de acuerdo con Gishu y Nick.

El diseño parte de un protocolo con posterioridad a menudo conduce a pensamientos como "maldito, yo debería haber hecho esto de esa manera, ahora tengo que usar esta fea solución"

Pero también depende de que estará en comunicación con este protocolo .
Si su control termina, y que cambiarán de versión al mismo tiempo, siempre puede refactorizar el protocolo más tarde como lo haría con una interfaz de código normal.

Sobre la implementación posterior de las características del protocolo adicional, descubrí que la implementación del protocolo ayuda mucho a validar su diseño, por lo que al menos puede querer hacer una muestra del código simple fuera de producción para probarlo, si Necesito que el diseño sea oficial.

Answer 8

Hay algunos casos en los que tiene sentido ir en contra de la intuición YAGNI.

Éstos son algunos de ellos:

siguientes convenciones de programación. Especialmente contratos de clase base e interfaz. Por ejemplo, si una clase base que hereda proporciona un método GetHashCode y un método Equals, anula Igual pero no GetHashCode rompe las reglas documentadas por la plataforma que los desarrolladores deben seguir cuando anulan Equals. Se debe seguir esta convención incluso si descubre que GetHashCode en realidad no se llamará. No anula GetHashCode es un error, incluso si no hay una forma actual de provocarlo (que no sea una prueba artificial). Una versión futura de la plataforma podría presentar llamadas a GetHashCode.O bien, otro programador que haya analizado la documentación (en este ejemplo, la documentación de la plataforma para la clase base que está heredando) podría esperar legítimamente que su código se adhiera sin examinar su código. Otra forma de pensar sobre esto es que todo el código y la documentación aplicable deben ser coherentes, incluso con documentación escrita por otros, como la proporcionada por el proveedor de la plataforma.

Personalización de soporte. Particularmente por desarrolladores externos que no modificarán su código fuente. Debe descubrir e implementar puntos de extensión adecuados en su código para que estos desarrolladores puedan implementar todo tipo de funcionalidad de complemento que nunca se le pasó por la cabeza. Desafortunadamente, es normal que agregue algunas funciones de extensibilidad que pocos o ningún desarrollador externo utilizan en última instancia. (Si es posible analizar los requisitos de extensibilidad con todos los desarrolladores externos antes de tiempo o usar ciclos frecuentes de desarrollo/lanzamiento, genial, pero esto no es factible para todos los proyectos).

Aserciones, comprobaciones de depuración, failsafes , etc. Tal código no es realmente necesario para que su aplicación funcione correctamente, pero le ayudará a asegurarse de que su código funcione correctamente ahora y en el futuro cuando se realicen las revisiones.