Frage

Ich beginne meine Abschlussarbeit und das Thema wird „Agile Architekturen“ sein.

Im Wesentlichen beginnt es mit einer Beschreibung traditioneller Softwareentwicklungsmethoden und der anschließenden Entstehung agiler Methoden und endet mit Empfehlungen und einem Entwurf einer flexiblen Anwendungsarchitektur, die sich leicht an die inhärenten Änderungen bei der Softwarekonstruktion anpassen lässt.

Meine Frage ist: Welche Muster und Designpraktiken würden Sie für eine solche Architektur empfehlen?Ich interessiere mich für Muster, die eine Maximierung der Klassenentkopplung wie Abhängigkeitsinjektion, hohe Wartbarkeit und maximale Abstraktion vom spezifischen Problem ermöglichen.

War es hilfreich?

Lösung

Ich empfehle Folgendes:

  1. Repository-Muster
  2. Spezifikationsmuster
  3. Abhängigkeitsspritze
  4. Domänengesteuertes Design

Im Grunde alles, was die ALT.NET-Crowd predigt.

Andere Tipps

Auf jeden Fall IoC-Praktiken und vertragsbasiert Programmieren im Allgemeinen würde für mich ganz oben auf der Liste stehen.Aus Erfahrung würde ich jedoch davor warnen, zu sehr vom Problem abzustrahieren, nur um der Abstraktion willen.Z.B.Abstrahieren, weil man es kann, und nicht, weil irgendjemand jemals in der Lage sein wird, diese Abstraktion zu nutzen.Ich habe gesehen, dass diese Art von Architektur schlecht wurde und einem System einfach einen zu hohen Grad an Komplexität hinzufügte, was die Wartung des Systems verschlechterte.

Eine Art Feedbackschleife rund um Ihren Entwicklungsprozess – seien es Unit-Tests, kontinuierliche Integration und/oder „Scrum“-Meetings.Mir ist klar, dass das nicht wirklich in den Bereich agiler „Architekturen“ fällt, aber wenn Sie keinen agilen Prozess haben, spielt der Grad einer „agil-orientierten“ Architektur keine Rolle.

Eine wesentliche Designmethode, die ich vorschlagen würde, besteht darin, zuerst ein funktionales End-to-End-System zu erstellen Skelett Ihrer Architektur.Um es so früh wie möglich durch echtes Feedback zu validieren.

Dies bezeichnen die Pragmatischen Programmierer als „Tracer Bullets“ und Alistair Cockburn als „wandelndes Skelett".

Können Sie auch definieren, worin sich eine Anwendung befindet? Der Kontext Ihrer Dissertation ?Denken Sie nur darüber nach Anwendungssoftware oder Haben Sie auch mit komplexeren Systemen zu tun?

Das ist eine interessante Frage.Kann eine Architektur isoliert agil erstellt werden?Wenn wir uns etwas wie XP ansehen, bin ich etwas skeptisch.Oder vielleicht habe ich es falsch verstanden, aber das hat mich nie davon abgehalten, es zu erweitern ...

Um einen Ansatz zu verfolgen, den ich besser kenne, werden wir in XP innerhalb sehr kurzer Zeit, nachdem wir ein Projekt gestartet haben, eine Art Struktur haben;Tatsächlich ungefähr zu dem Zeitpunkt, an dem die erste Geschichte fertig ist.Während des anfänglichen Schreibens der Geschichte haben wir begonnen, eine Vorstellung davon zu bekommen, was wir bauen könnten – es ist unvermeidlich:Programmierer neigen dazu, in Codes zu denken.Aber zu weit vorauszudenken führt uns hinein YAGNI Gebiet.

Ich dachte irgendwie, dass ein Großteil der Architektur einer Anwendung, die in einer agilen Umgebung entwickelt wurde, voraussichtlich durch ständige und gezielte Umgestaltung entstehen würde, um Duplikate zu beseitigen.

Vielleicht besteht die Frage auch darin, zu beurteilen, ob es bestimmte Merkmale – oder Merkmalsklassen – gibt, die Architekturen, die als Ergebnis eines agilen Prozesses entwickelt wurden, tendenziell aufweisen.Und dann denke ich, dass es davon abhängt, welche Art von App wir erstellen, obwohl einige der bereits erwähnten Prinzipien (von denen ich einige sogar verstehe) wahrscheinlich sein müssen.

Meiner Meinung nach predigt Agile keine „Architekturen“ als solche.Agile ist eine Methodik, die auf Grundprinzipien basiert, die sich auf das Projektmanagement, Release-Zyklen und die allgemeine Entwicklungspraxis auswirken, aber sicherlich nicht auf die Softwarearchitektur.

Alle hier aufgeführten Softwaremuster könnten mithilfe eines starken Wasserfallprozesses verwendet werden, der für die agile Entwicklung ein Gräuel ist.

Agil zu sein bedeutet, dass man Veränderungen annimmt, d. h.Anpassung an veränderte Anforderungen und Designentscheidungen und Akzeptanz von Refactoring usw.Viele Dinge würden auf „traditionelle“ Weise missbilligt, da Sie etwas berühren, das funktioniert/zuvor vereinbart wurde.

Bei Methoden wie XP wird versucht, die Qualität durch das Schreiben von Unit-Tests hoch zu halten.Stellen wir uns vor, wir wären uns alle einig, Unit-Tests zu schreiben.

Hier können Sie nun eine Architektur einführen, damit das System testbar oder testfreundlich ist, da nicht alle Systeme testbar sind.Machen Sie beispielsweise die mittlere Schicht aufrufbar und trennen Sie die UI-Schicht von der Geschäftslogik usw.

Wenn Robert Martin etwas dazu zu sagen hat (und er hat das ursprüngliche Agile-Manifest beim IIRC-Treffen einberufen), dann hat Architektur absolut alles mit Agilität zu tun.Der gesamte erste Abschnitt seines Buches Agile Softwareentwicklung, Prinzipien, Muster und Praktiken geht es um die SOLIDE Architekturprinzipien.Dies war in manchen Kreisen etwas umstritten, aber ich verstehe nicht, warum.Wenn Ihre Codebasis spröde und stark gekoppelt ist, kann sie nicht sehr offen für Änderungen sein, was das Markenzeichen von Agilität ist.Die konzeptionelle Trennung von Prozess und Code-Praxis ist eine sehr unflexible Vorgehensweise.

Grundsatz 1 des Manifests:„Wir legen Wert auf Einzelpersonen und Interaktionen über Prozesse und Tools.“

Agile „Prozesse“ als eine von der Architektur der Codebasis getrennte Abstraktion zu definieren, verstößt meiner Meinung nach gegen den Geist dieses ersten Prinzips.

Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top