Ist ein Architekturbeschreibungsdokument ein Verstoß gegen das DRY-Prinzip?

11

Das DRY-Prinzip (Wiederholen Sie sich nicht) besagt, dass "jedes Wissen eine einzige, eindeutige, maßgebliche Darstellung innerhalb eines Systems haben muss". Meistens bezieht sich dies auf Code, wird aber häufig auch auf die Dokumentation ausgedehnt.

Es wird gesagt, dass jedes Softwaresystem eine Architektur hat, ob Sie es gewählt haben oder nicht. Mit anderen Worten, die von Ihnen erstellte Software hat eine Struktur und diese "wie erstellt" -Struktur ist die Architektur der Software. Ist das Erstellen einer Architekturbeschreibung dieses Systems eine Verletzung des DRY-Prinzips, da ein erstelltes Softwaresystem mit einer Architektur geliefert wird? Wenn Sie die Architektur kennen müssen, können Sie sich immer nur den Code ansehen ...

— Michael
quelle

Glauben Sie tatsächlich, dass Sie die Architektur anhand des Codes erkennen können? Der Code informiert Sie über alle funktionalen und nicht funktionalen Anforderungen, die Kompromisse bei der Architektur, Bereitstellungsprobleme, den Geschäftskontext, Anwendungsfallszenarien usw. usw. Wenn Sie Code WIRKLICH sagen können, ist das ein verdammt triviales System.

— Luis.espinal

@ luis.espinal, Es ist möglich, statische und dynamische Strukturen vom Code bzw. vom laufenden System zu unterscheiden. Ob diese Strukturen der Architektur eines Systems entsprechen, hängt von Ihrer Denkrichtung ab. Wie Sie bereits betont haben, fehlen Ihnen immer noch einige große Teile, einschließlich aller architektonischen Treiber und Gründe für Entwurfsentscheidungen.

— Michael

Welche wahre Denkschule setzt Code-abgeleitete Strukturen mit der Architektur eines Systems gleich? Wenn wir wissen, dass wir einige große Teile vermissen werden, einschließlich aller Architekturtreiber, dann fehlt uns die gesamte Architektur. Dies beweist trivial, dass die statischen und dynamischen Strukturen, die allein vom Code unterschieden werden können, nicht die gesamte Architektur darstellen (unabhängig von der Denkrichtung). Wenn wir uns ziemlich gut etablierte Definitionen von Systemen und Softwarearchitekturen ansehen (dh SEIs oder INCOSE's), sie sind klar darin, dass Code nur ein Bruchteil einer Architektur ist.

— Luis.espinal

ein typisches Beispiel. Die Architektur eines Systems erfordert möglicherweise die Bereitstellung auf einer bestimmten Anzahl von Computern, wobei externe Schnittstellen in einer bestimmten Reihenfolge ein- und ausgeschaltet werden. Statische und dynamische Strukturen, die nur aus Code abgeleitet werden, werden dies (wenn überhaupt) kaum erfassen. Diese sind jedoch eindeutig Teil der Bereitstellungs- und Betriebsaspekte einer Systemarchitektur. Und jede von Code abgeleitete Struktur bezieht sich nur auf die Realisierung statischer Aspekte einer Softwareanwendungs- (oder Komponenten-) Architektur. Es kann nie eine sein Systeme Architektur.

— Luis.espinal

1

@ luis.espinal, ich lade Sie ein, eine Antwort auf diese Frage einzureichen! Es hört sich so an, als würden Sie eine hervorragende Perspektive einbringen, von der ich denke, dass sie diesem Thema einen echten Mehrwert verleihen würde. Sie predigen dem Chor darüber. Warum also nicht eine Antwort erstellen, die Ihr Denken vollständig erklärt, damit jeder davon profitieren kann? Deshalb habe ich die Frage überhaupt gestellt.

— Michael

11

Verstößt das Duplizieren Ihrer Gedanken in Code gegen das DRY-Prinzip?

Meine Güte, wenn Sie die Architektur nur anhand von Code kennen könnten, gäbe es überhaupt keine "Architekturbeschreibungsdokumente". Es ist keine Wiederholung, es ist eine andere Ebene der Systembeschreibung , die nicht trivial aus dem Code abgeleitet werden kann und umgekehrt. Es hat also sein volles Existenzrecht, selbst wenn Sie DRY annehmen.

— P Shved
quelle

7

Nehmen Sie DRY nicht als feste Regel. Es ist eine gute Sache, aber Sie können es in der Praxis nur annähern.

Ich denke auch, dass es nicht gut geschrieben ist. "Wiederhole dich nicht" scheint nicht den ebenso wichtigen Fall abzudecken, dass du, um eine semantische oder funktionale Änderung vorzunehmen, den Quelltext an mehreren Stellen bearbeiten und verschiedene, aber koordinierte Dinge sagen müsste.

Anstatt es als Gebot zu betrachten, nicht verletzt zu werden, ist es besser zu verstehen, warum es eine gute Idee ist, und vernünftige Entscheidungen darüber zu treffen. Der Grund, warum es schlecht ist, an mehreren Stellen koordinierte Änderungen vornehmen zu müssen, ist, dass Sie als Editor Fehler machen. Sie sind nicht 100% zuverlässig, um die Änderungen fehlerfrei vorzunehmen. Wenn Sie 10 verschiedene Quelltextänderungen vornehmen müssen und nur 9 davon richtig sind, haben Sie einen Fehler hinzugefügt . Aus diesem Grund ist es eine gute Sache, den Quelltext so anzuordnen, dass die Anzahl der koordinierten Änderungen minimiert wird. Es minimiert Fehler.

Wir gehören keiner Religion an, in der DRY eines der Gebote ist. Es ist nur eine praktische, wenn auch leicht irreführende Möglichkeit, den gesunden Menschenverstand zusammenzufassen.

— Mike Dunlavey
quelle

4

Eine Architekturbeschreibung oder Software-Designbeschreibung verstößt gegen DRY. In einer großen Organisation, in der Projekte in den letzten Jahren durchgeführt wurden, kommen und gehen Entwickler, und das System ist zu groß, als dass eine Person alle Details im Kopf behalten könnte. Es ist ein kritisches Dokument. Die Menge an "Wiederholungen", die erforderlich sind, um die Synchronisierung aufrechtzuerhalten, lohnt sich für den Aufwand, der beim nächsten Update oder bei der nächsten Wartung eingespart wird.

— AShelly
quelle

1

Das ist ein Missverständnis oder eine blinde Anwendung von DRY. Eine architektonische Beschreibung ist keine Verletzung davon. Wenn man DRY blind auf diese Weise anwendet, dann ist alles andere als der Code eine Verletzung davon ... und dies war eindeutig nicht die Absicht derer, die auf die Idee gekommen sind.

— Luis.espinal

2

Eine Architekturbeschreibung verstößt nicht gegen das DRY-Prinzip.

Ihr Softwaresystem verfügt natürlich über eine Architektur. Und es ist über viele Dateien verteilt, in vielen Klassen, mit vielen überflüssigen und Details, die für eine Übersicht nicht erforderlich sind.

Ihr Architekturdokument sollte wie der erste Absatz eines Nachrichtenberichts sein: Es ist eine Gliederung, eine Zusammenfassung, eine Roadmap des Projekts.

— Frank Shearar
quelle

1

Wenn Sie das Dokument datieren, beschreibt es die Architektur zum Zeitpunkt des Schreibens.

Während der Code die Architektur im gegenwärtigen Moment darstellt.

Zwei getrennte Dinge - nicht dasselbe Wissen.

Solange Sie angeben, dass das Dokument die Architektur zum Zeitpunkt des Schreibens darstellt, duplizieren Sie das IMO-Wissen nicht, da es sich um ein anderes Wissen handelt, wenn es sich zu einem anderen Zeitpunkt um das System handelt.

— Niemand
quelle

Code repräsentiert niemals Architektur. Es ist nur eine Manifestation der Architektur. Code, der heute geändert wurde, könnte immer noch die Architektur von gestern darstellen. Darüber hinaus stellt es möglicherweise nicht die beabsichtigte (oder vertraglich erforderliche) Architektur dar, worüber Sie sich am meisten Sorgen machen müssen. Der Code sagt Ihnen nicht, ob er richtig oder falsch ist, sondern nur, dass er ausgeführt wird. Um zu wissen, ob es richtig oder falsch ist, müssen Sie sich zunächst die beabsichtigte Architektur und die Anforderungen ansehen , die das System angetrieben haben.

— Luis.espinal