El Principio DRY (No te repitas) establece que "cada conocimiento debe tener una representación autoritaria, inequívoca y única dentro de un sistema". La mayoría de las veces esto se refiere al código, pero a menudo también se extiende a la documentación.
Se dice que cada sistema de software tiene una arquitectura, lo elijas o no. En otras palabras, el software que construye tiene una estructura y esa estructura "tal como está construida" es la arquitectura del software. Dado que un sistema de software incorporado viene con una arquitectura, ¿crear una descripción de la arquitectura de ese sistema es una violación del Principio DRY? Después de todo, si necesita conocer la arquitectura, siempre puede mirar el código ...
agile
documentation
architecture
dry
Miguel
fuente
fuente
Respuestas:
¿Duplicar tus pensamientos en código viola el principio DRY?
Cielos, si pudieras conocer la arquitectura mirando el código, en primer lugar no habría "documentos de descripción de arquitectura". No es una repetición, es otro nivel de descripción del sistema , que no puede deducirse trivialmente del código, y viceversa. Por lo tanto, tiene todo el derecho de existir, incluso si acepta DRY.
fuente
No tome DRY como una regla dura y rápida. Es algo bueno, pero solo puedes aproximarlo en la práctica.
También creo que no está bien escrito. "No te repitas" no parece cubrir el caso igualmente importante de que para hacer un cambio semántico o funcional tendrías que editar el texto fuente en varios lugares, diciendo cosas diferentes pero coordinadas.
En lugar de tomarlo como un mandamiento para no ser violado, es mejor entender por qué es una buena idea y tomar decisiones sensatas al respecto. La razón por la que es malo tener que realizar ediciones coordinadas en varios lugares es que usted, el editor, comete errores. No es 100% confiable para hacer los cambios sin error. Si tiene que hacer 10 cambios de texto fuente diferentes, y solo obtiene 9 de ellos correctamente, ha introducido un error . Es por eso que organizar el texto fuente para minimizar el número de cambios coordinados es algo bueno. Reduce al mínimo los errores.
No pertenecemos a una religión en la que DRY sea uno de los mandamientos. Es una manera práctica, aunque un tanto engañosa, de encapsular algo de sentido común.
fuente
Una Arquitectura Descripción o Diseño Descripción del software hace violar SECO. Sin embargo, en una organización grande, donde los proyectos duraron años, los desarrolladores van y vienen, y el sistema es demasiado grande para que una persona pueda tener todos los detalles en su cabeza, es un documento crítico. La cantidad de "repetición" necesaria para mantenerlo sincronizado vale la pena por el esfuerzo que ahorra durante la próxima actualización o mantenimiento.
fuente
Una descripción de arquitectura no viola el principio DRY.
Su sistema de software viene con una arquitectura, claro. Y se extiende sobre muchos archivos, en muchas clases, con muchos detalles extraños y innecesarios para una visión general.
Su documento de arquitectura debe ser como el primer párrafo de un informe de noticias: es un resumen, un resumen, una hoja de ruta del proyecto.
fuente
Si fecha el documento, describe la arquitectura en el momento de la escritura.
Mientras que el código representa la arquitectura en el momento presente.
Dos cosas separadas, no el mismo conocimiento.
Siempre que declare que el documento representa la arquitectura en el momento de la escritura, no está duplicando el conocimiento IMO porque su conocimiento es diferente si se trata del sistema en otro momento.
fuente