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

Question

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

#1 da (11 voti)
#2 da (7 voti)
#3 da (4 voti)
#4 da (2 voti)
#5 da (1 voti)

11

Il principio DRY (Non ripeterti) afferma che "ogni conoscenza deve avere un singolo , rappresentazione non ambigua e autorevole all'interno di un sistema. " La maggior parte delle volte si riferisce al codice, ma spesso viene esteso anche alla documentazione.

Si dice che ogni sistema software ha un'architettura sia che lo si scelga o no. In altre parole, il software che costruisci ha una struttura e quella struttura "così costruita" è l'architettura del software. Dal momento che un sistema software costruito viene fornito con un'architettura, sta creando una descrizione di architettura di quel sistema una violazione del Principio di DRY? Dopo tutto, se hai bisogno di conoscere l'architettura, puoi sempre guardare codice ...

agile architecture documentation dry

posta Michael 09.10.2010 - 21:34

fonte

5 risposte

Leggi altre domande sui tag agile architecture documentation dry

Gli sviluppatori, i tester e gli utenti aziendali dovrebbero avere uno script di test unificato? Perché Apple consente solo i framework statici su iOS?

score 11 · Answer 1

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

Geez, se solo potessi conoscere l'architettura esaminando il codice, in primo luogo non ci sarebbero cose come "documenti di descrizione dell'architettura". Non è una replica, è 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 abbracci ASCIUTTO.

score 7 · Answer 2

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

Inoltre, penso che non sia scritto bene. "Non ripeterti" non sembra coprire l'altrettanto importante caso in cui per fare 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 scelte sensate a riguardo. La ragione per cui è male dover apportare modifiche coordinate in più punti è che tu, l'editor, commetti degli errori. Non sei affidabile al 100% per apportare le modifiche senza errori. Se devi fare 10 diverse modifiche al testo sorgente, e ne ottieni solo 9, hai inserito un bug . Ecco perché organizzare il testo sorgente per minimizzare il numero di modifiche coordinate è una buona cosa. Minimizza i bug.

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

score 4 · Answer 3

Una descrizione dell'architettura o una descrizione della progettazione del software violano DRY. Tuttavia, in una grande organizzazione, in cui i progetti durano anni, gli sviluppatori vanno e vengono, e il sistema è troppo grande per consentire a una sola persona di mantenere tutti i dettagli nella propria testa, è un documento critico. La quantità di "ripetizione" necessaria per mantenerla sincronizzata vale la pena per lo sforzo che salva durante il prossimo aggiornamento o manutenzione.

score 2 · Answer 4

Una descrizione di architettura non viola il principio di DRY.

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

Il tuo documento di architettura dovrebbe essere come il primo paragrafo di un notiziario: è uno schema, un riassunto, una tabella di marcia del progetto.

score 1 · Answer 5

Se date la data del documento, allora descrive l'architettura al momento della scrittura.

Mentre il codice rappresenta l'architettura al momento attuale.

Due cose separate - non la stessa conoscenza.

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