Un documento di descrizione di architettura è una violazione del principio DRY?

11

Il principio DRY (Don't Repeat Yourself) afferma che "ogni pezzo di conoscenza deve avere una rappresentazione unica, inequivocabile e autorevole all'interno di un sistema". Il più delle volte questo si riferisce al codice, ma spesso viene esteso anche alla documentazione.

Si dice che ogni sistema software abbia un'architettura che tu l'abbia scelta o no. In altre parole, il software che costruisci ha una struttura e quella struttura "come costruita" è l'architettura del software. Poiché un sistema software integrato viene fornito con un'architettura, la creazione di una descrizione dell'architettura di tale sistema costituisce una violazione del principio DRY? Dopotutto, se hai bisogno di conoscere l'architettura, puoi sempre guardare il codice ...

— Michael
fonte

Credi davvero di poter discernere l'architettura guardando il codice? Il codice ti dirà tutti i requisiti funzionali e non funzionali, i compromessi architetturali, i problemi di implementazione, il contesto aziendale, gli scenari di casi d'uso, ecc. Ecc.? Se il tuo codice può VERAMENTE dirtelo, quello è un inferno di un sistema banale.

— luis.espinal,

@ luis.espinal, È possibile distinguere rispettivamente le strutture statiche e dinamiche dal codice e dal sistema in esecuzione. Se tali strutture siano equivalenti all'architettura di un sistema dipenderà dalla tua scuola di pensiero. Come hai sottolineato, ti mancheresti comunque alcuni grossi pezzi, inclusi i driver di architettura e le motivazioni alla base delle decisioni di progettazione.

— Michael,

Quale vera scuola di pensiero identifica le strutture derivate dal codice con l'architettura di un sistema? Se sappiamo che ci mancheranno alcuni grossi pezzi inclusi eventuali driver di architettura, quindi ci manca l'intera architettura. Ciò dimostra in modo banale che le strutture statiche e dinamiche che possono essere discernute dal solo codice non rappresentano l'intera architettura (indipendentemente dalla scuola di pensiero). Se guardiamo a definizioni piuttosto ben definite di sistemi e architettura software (es. SEI o INCOSE), sono chiari in quanto il codice è solo una frazione di un'architettura.

— luis.espinal,

caso in questione. L'architettura di un sistema potrebbe richiedere la distribuzione su un numero specifico di macchine, con le interfacce esterne disattivate e attivate in un ordine specifico. Le strutture statiche e dinamiche derivate dal solo codice difficilmente riusciranno a catturarlo (se non del tutto). Chiaramente, tuttavia, fanno parte degli aspetti operativi e di distribuzione di un'architettura di sistema. E qualsiasi struttura derivata dal codice riguarderà solo la realizzazione di aspetti statici di un'architettura di un'applicazione software (o componente). Non può mai essere per un'architettura di sistema .

— luis.espinal,

1

@ luis.espinal, ti invito a inviare una risposta a questa domanda! Sembra che tu porti una prospettiva eccellente che penso possa aggiungere un valore reale a questo argomento. Stai predicando al coro su questo, quindi perché non creare una risposta che spieghi completamente il tuo pensiero in modo che tutti possano trarne beneficio? È per questo che ho posto la domanda in primo luogo.

— Michael,

11

La duplicazione dei tuoi pensieri in codice viola il principio DRY?

Accidenti, se potessi semplicemente conoscere l'architettura guardando il codice, in primo luogo non ci sarebbero cose come "documenti descrittivi dell'architettura". Non è una ripetizione, è un altro livello di descrizione del sistema , che non può essere banalmente dedotto dal codice e viceversa. Quindi ha il pieno diritto di esistere anche se si abbraccia DRY.

— P rasato
fonte

7

Non prendere DRY come una regola dura e veloce. È una buona cosa, ma puoi solo approssimarlo in pratica.

Inoltre penso che non sia ben scritto. "Non ripetere te stesso" non sembra coprire il caso altrettanto importante che per apportare un cambiamento semantico o funzionale dovresti modificare il testo sorgente in più punti, dicendo cose diverse ma coordinate.

Piuttosto che prenderlo come un comandamento da non violare, è meglio capire perché è una buona idea e fare delle scelte sensate al riguardo. Il motivo per cui è male dover apportare modifiche coordinate in più punti è che tu, l'editor, fai degli errori. Non sei affidabile al 100% per apportare le modifiche senza errori. Se devi apportare 10 diverse modifiche al testo sorgente e ne ottieni solo 9, hai inserito un bug . Ecco perché organizzare il testo di partenza per ridurre al minimo il numero di modifiche coordinate è una buona cosa. Riduce al minimo i bug.

Non apparteniamo a una religione in cui DRY è uno dei comandamenti. È solo un modo utile, sebbene leggermente fuorviante, di incapsulare un po 'di buon senso.

— Mike Dunlavey
fonte

4

Un Architettura Descrizione o Design del software Descrizione fa violare SECCO. Tuttavia, in una grande organizzazione, in cui i progetti negli ultimi anni, gli sviluppatori vanno e vengono, e il sistema è troppo grande per chiunque per tenere tutti i dettagli nella testa, è un documento critico. La quantità di "ripetizione" necessaria per mantenerlo sincronizzato è assolutamente valsa la pena per lo sforzo che risparmia durante il prossimo aggiornamento o manutenzione.

— AShelly
fonte

1

Questa è un'applicazione incomprensibile o cieca di DRY. Una descrizione architettonica non è una violazione di essa. Se si dovesse applicare ciecamente DRY in questo modo, allora qualsiasi cosa tranne il codice ne costituisce una violazione ... e chiaramente questa non era l'intenzione di coloro che ne avevano idea.

— luis.espinal,

2

Una descrizione dell'architettura non viola il principio DRY.

Il tuo sistema software ha un'architettura, certo. Ed è distribuito su molti file, in molte classi, con molti estranei e dettagli che non sono necessari per una panoramica.

Il tuo documento di architettura dovrebbe essere come il primo paragrafo di un reportage: è una struttura, un riepilogo, una tabella di marcia del progetto.

— Frank Shearar
fonte

1

Se esci con il documento, questo descrive l'architettura al momento della scrittura.

Considerando che il codice rappresenta l'architettura al momento attuale.

Due cose separate - non la stessa conoscenza.

Finché affermi che il documento rappresenta l'architettura al momento della stesura, non stai duplicando la conoscenza IMO perché è diversa conoscenza se riguarda il sistema in un altro momento.

— Nessuno
fonte

Il codice non rappresenta mai l'architettura. È solo una manifestazione dell'architettura. Il codice che è stato cambiato oggi potrebbe ancora rappresentare l'architettura di ieri. Inoltre, potrebbe non rappresentare l'architettura prevista (o contrattualmente richiesta), che è ciò di cui ti devi preoccupare di più. Il codice non ti dice se è giusto o sbagliato, solo che funziona. Per sapere se è giusto o sbagliato, è necessario esaminare l' architettura prevista e i requisiti che hanno guidato il sistema.

— luis.espinal,