¿Es un documento de descripción de arquitectura una violación del Principio DRY?

11

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 ...

— Miguel
fuente

¿Realmente crees que puedes discernir la arquitectura mirando el código? El código le indicará todos los requisitos funcionales y no funcionales, las compensaciones arquitectónicas, los problemas de implementación, el contexto comercial, los escenarios de casos de uso, etc. Si el código realmente puede decirle eso, es un sistema trivial infernal.

— luis.espinal

@ luis.espinal, es posible discernir estructuras estáticas y dinámicas del código y el sistema en ejecución, respectivamente. Si esas estructuras son equivalentes a la arquitectura de un sistema dependerá de su escuela de pensamiento. Como ha señalado, aún se perderían algunos fragmentos grandes, incluidos los controladores arquitectónicos y la razón detrás de las decisiones de diseño.

— Michael

¿Qué verdadera escuela de pensamiento equipara las estructuras derivadas del código con la arquitectura de un sistema? Si sabemos que echaremos de menos algunos fragmentos grandes, incluidos los controladores arquitectónicos, entonces nos falta toda la arquitectura. Esto demuestra trivialmente que las estructuras estáticas y dinámicas que se pueden discernir del código solo no representan la totalidad de una arquitectura (independientemente de la escuela de pensamiento). Si observamos definiciones bastante bien establecidas de sistemas y arquitectura de software (es decir, SEI o INCOSE), son claros en que el código es solo una fracción de una arquitectura.

— luis.espinal

caso en punto. La arquitectura de un sistema puede requerir que implemente en un número específico de máquinas, con las interfaces externas apagadas y encendidas en un orden específico. Las estructuras estáticas y dinámicas derivadas del código solo difícilmente capturarán eso (si es que lo hacen). Sin embargo, claramente son parte de los aspectos operativos y de implementación de una arquitectura de sistema. Y cualquier estructura derivada del código solo pertenecerá a la realización de aspectos estáticos de una arquitectura de aplicación de software (o componente). Nunca puede ser para una arquitectura de sistemas .

— luis.espinal

1

@ luis.espinal, ¡te invito a enviar una respuesta a esta pregunta! Parece que traes una excelente perspectiva que creo que agregaría un valor real a este tema. Estás predicando al coro sobre esto, entonces, ¿por qué no crear una respuesta que explique completamente tu pensamiento para que todos puedan beneficiarse? Es por eso que hice la pregunta en primer lugar.

— Michael

11

¿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.

— P Shved
fuente

7

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.

— Mike Dunlavey
fuente

4

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.

— AShelly
fuente

1

Esa es una aplicación errónea o ciega de DRY. Una descripción arquitectónica no es una violación de la misma. Si uno aplicara DRY a ciegas de esta manera, entonces cualquier cosa que no sea el código es una violación de él ... y claramente esta no era la intención de aquellos a quienes se les ocurrió la idea.

— luis.espinal

2

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.

— Frank Shearar
fuente

1

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.

— Nadie
fuente

El código nunca representa la arquitectura. Es solo una manifestación de la arquitectura. El código que se cambió hoy todavía podría representar la arquitectura de ayer. Además, es posible que no represente la arquitectura prevista (o requerida por contrato), que es lo que más le preocupa. El código no le dice si está bien o mal, solo que se ejecuta. Para saber si es correcto o incorrecto, primero debe analizar la arquitectura prevista y los requisitos que impulsaron el sistema.

— luis.espinal