Vorwort
Wie Sie bereits anhand des Namens verstanden haben, werde ich hier über die "höchste" Architektur sprechen. Und der Anstoß für die Entwicklung dieser ganzen Geschichte war das Buch von Robert Martin „Reine Architektur“. Wenn ich es noch nicht gelesen habe, kann ich es nur empfehlen! Der Autor enthüllt viele wichtige Themen, teilt aktiv seine reichen Lebenserfahrungen (natürlich aus einem Berufsfeld) und die daraus gewonnenen Schlussfolgerungen, verwebt gelegentlich in Kapitel der Geschichte, wie meisterhaft beschissen (und natürlich nicht nur) unsere Väter und Großväter sind In den 60er, 70er, 80er und sogar in den schneidigen 90er Jahren wurden wie Getreidekörner die beliebtesten Prinzipien von SOLID und ihre Analoga in der Welt der Komponenten gesammelt und das, was sie im letzten halben Jahrhundert gelernt haben. Während des Lesens des Buches wird die Entwicklungslinie der Softwareentwicklungsbranche gut nachverfolgt, typische Probleme, mit denen sich Jungen befassen mussten.und Methoden zu ihrer Lösung.Denken Sie nicht, dass das Nacherzählen der Zusammenfassung des Buches nicht der Zweck dieses Beitrags ist.Als nächstes werden wir über Ideen sprechen, die mich dazu veranlasst haben, ein Tool zu entwickeln (ich werde den Grad seiner Nützlichkeit für Sie bestimmen und mit großem Interesse auf Feedback, Vorschläge und konstruktive Kritik warten).Es scheint mir, dass der Artikel für alle nützlich sein wird. Diejenigen, die bereits mit dem Buch vertraut sind, können einige seiner Momente in ihrem Gedächtnis auffrischen oder einfach den ersten Teil überspringen und sich sofort mit dem Werkzeug vertraut machen. Diejenigen, die das Buch noch nicht gelesen haben, finden vielleicht im ersten Teil etwas Neues für sich.Der Einfachheit halber ist der Artikel in zwei Teile unterteilt.Im ersten werde ich über die Schlüsselideen sprechen, die in meinem Kopf den Wunsch erzeugt haben, diese ganze Sache zu automatisieren. Sind wir Programmierer oder wer am Ende? Hier werde ich viel vom Autor zitieren und aktiv Auszüge und Illustrationen aus verschiedenen Kapiteln des Buches einfügen.Der zweite Teil befasst sich fast ausschließlich mit der Beschreibung des angezeigten Tools, dessen Funktionen und schrittweisen Anleitungen.Wenn Sie sich als eine Kategorie von Menschen betrachten, die Ihnen alles zu sehr am Herzen liegen, empfehle ich Ihnen, mit dem Lesen des Nachworts zu beginnen .Teil 1
Was ist Softwarearchitektur?
Leider gibt der Autor des Buches keine einzige Definition. Es gibt eine große Anzahl verschiedener Formulierungen, und alle sind auf ihre Weise korrekt.Wir können jedoch von der anderen Seite gehen.Was ist der Zweck der Architektur?
Es gibt nur eine Antwort:Das Ziel der Softwarearchitektur besteht darin, den Arbeitsaufwand für die Erstellung und Wartung eines Systems zu reduzieren.Eine kleine Einführung ..Wo fangen viele Projekte an?
"Wir werden später in der Lage sein, die Ordnung wiederherzustellen, wir würden nur in den Markt eintreten!"Infolgedessen wurde die Ordnung nicht wiederhergestellt, da der Wettbewerbsdruck auf dem Markt nie nachlässt.„Die größte Lüge, die viele Entwickler glauben, ist, dass schmutziger Code ihnen hilft, schnell auf den Markt zu kommen, aber in Wirklichkeit wird er ihre Bewegung auf lange Sicht verlangsamen. Entwickler, die an diese Lüge glauben, zeigen Hares Arroganz und glauben, dass sie in Zukunft von der Schaffung von Unordnung zur Wiederherstellung der Ordnung übergehen können, aber sie machen einen einfachen Fehler. Tatsache ist, dass die Entstehung von Störungen unabhängig von der gewählten Zeitskala immer langsamer ist als die ständige Einhaltung der Sauberkeit. "Zwei Werte von Softwareprodukten
- Verhalten (etwas Dringendes, aber nicht immer Wichtiges)
- Architektur (etwas Wichtiges, aber nicht immer Dringendes)
Viele ertrinken oft im ersten und vernachlässigen den zweiten völlig.Typ: „Warum Zeit damit verschwenden, gründlich über Architektur nachzudenken? Hauptsache, sie funktioniert richtig!“ .Sie übersehen jedoch einen wichtigen Punkt: „Wenn ein ordnungsgemäß funktionierendes Programm die Möglichkeit einer Änderung nicht zulässt, funktioniert es nicht mehr ordnungsgemäß, wenn sich die Anforderungen ändern, und sie können es nicht ordnungsgemäß ausführen. Das heißt, das Programm wird unbrauchbar.Wenn das Programm nicht richtig funktioniert, aber leicht geändert werden kann, kann es ordnungsgemäß funktionieren und seine Leistung beibehalten, wenn sich die Anforderungen ändern. Das heißt, das Programm bleibt immer nützlich. “Diese Aussage hat mir gefallen:"Wenn Sie der Meinung sind, dass gute Architektur teuer ist, versuchen Sie es mit schlechter Architektur." (Brian Foote und Joseph Yoder)Es stellt sich heraus, dass es wichtig ist , von Anfang an auf die Sauberkeit und Architektur des Codes im Allgemeinen zu achten. Wenn jedoch mit der Reinheit des Codes alles relativ klar ist (alle möglichen schlechten Gerüche im Code ausspähen und korrigieren, außer dass die Tools voller intelligenter IDEs, statischer Analysatoren und anderer zweifellos wichtiger Abfälle sind), ist dies bei der Architektur nicht ganz so (zumindest nicht) am wenigsten ich).Wie können Sie etwas kontrollieren, das so vage ist, dass es schwierig ist, es durch einen einzigen Wortlaut zu definieren, dass es eine sehr vielseitige Idee hat und jede Sekunde, verdammt, Scheiße, es sieht und versucht, es auf seine eigene Weise zu interpretieren, wenn Sie nicht Vangas Enkel sind, hat die Show „Intuition Und sind nicht besonders sensibler fünfter Punkt? Dann wirft der Autor des Buches ein paar wertvolle Gedanken zum Nachdenken auf ... Lassen Sie es uns klären.Warum hast du dir SOLID ausgedacht und warum reicht es nicht alleine aus?
Wir alle kennen wahrscheinlich die Prinzipien von SOLID.Ihr Ziel ist es, Softwarestrukturen auf mittlerer Ebene zu erstellen, die:- tolerant gegenüber Veränderungen;
- einfach und verständlich;
- bilden die Basis für Komponenten, die in vielen Softwaresystemen eingesetzt werden können.
Aber: "So wie gute Ziegel eine unbrauchbare Wand bilden können, können gut gestaltete Komponenten des durchschnittlichen Niveaus ein unbrauchbares System erzeugen."Daher gibt es in der Welt der Komponenten Analoga von SOLID-Prinzipien sowie übergeordnete Prinzipien zum Erstellen von Architekturen.Ich werde diese Themen sehr oberflächlich ansprechen, weitere Details finden Sie im Buch. Lass uns gehen!Konnektivität von Komponenten und ihre bestimmenden Prinzipien
„Zu welcher Komponente gehört diese oder jene Klasse? Diese wichtige Entscheidung muss in Übereinstimmung mit den festgelegten Prinzipien der Softwareentwicklung getroffen werden. Leider sind solche Entscheidungen besonderer Natur und werden fast ausschließlich auf der Grundlage des Kontextes getroffen. “REP: Prinzip der Wiederverwendung / Freigabeäquivalenz - Das Prinzip der Äquivalenz von Wiederverwendung und Freigabe.In Bezug auf Architektur und Design bedeutet dieses Prinzip, dass die Klassen und Module, aus denen eine Komponente besteht, zu einer verbundenen Gruppe gehören müssen. Eine Komponente kann nicht einfach eine zufällige Mischung aus Klassen und Modulen enthalten. Es sollte ein Thema oder Ziel geben, das allen Modulen gemeinsam ist.Zu einer Komponente kombinierte Klassen und Module müssen gemeinsam freigegeben werden.KPCh: Common Closure Principle - das Prinzip des konsequenten Wandels.Dies ist das Prinzip der SRP (Single Responsibility), das für Komponenten umformuliert wurde.Klassen, die sich aus den gleichen Gründen und zur gleichen Zeit ändern, sollten in einer Komponente enthalten sein. Verschiedene Komponenten sollten Klassen enthalten, die sich zu unterschiedlichen Zeiten und aus verschiedenen Gründen ändern.CRP: Common Reuse Principle - Das Prinzip der gemeinsamen Wiederverwendung.Dieses Prinzip ähnelt dem ISP (Interface Segregation).Erzwingen Sie nicht, dass Benutzer von Komponenten davon abhängen, was sie nicht benötigen.Das Prinzip besagt, dass Klassen, die nicht eng miteinander verbunden sind, nicht in einer Komponente enthalten sein sollten.„Vielleicht haben Sie bereits bemerkt, dass die drei Prinzipien verbundener Komponenten miteinander in Konflikt geraten. Die Prinzipien der Wiederverwendungsäquivalenz (REP) und des konsequenten Wandels (CCP) sind inklusive: Beide streben danach, die Komponenten so groß wie möglich zu machen. Das Wiederverwendungsprinzip (CRP) ist außergewöhnlich und bemüht sich, die Komponenten so klein wie möglich zu halten. Die Aufgabe eines guten Architekten ist es, diesen Widerspruch zu lösen. “
„In der Vergangenheit haben wir uns die Konnektivität einfacher angesehen, als es die Prinzipien der Wiederverwendungsäquivalenz (REP), der konsistenten Änderung (CCP) und der gemeinsamen Wiederverwendung (CRP) vermuten lassen. Sobald wir dachten, dass Konnektivität nur ein Attribut ist, führt ein Modul eine und nur eine Funktion aus. Die drei Prinzipien der Komponentenkonnektivität beschreiben jedoch eine viel komplexere Vielfalt. Bei der Auswahl von Klassen für die Aufnahme in Komponenten müssen Sie die gegensätzlichen Kräfte berücksichtigen, die mit der einfachen Wiederverwendung und Entwicklung verbunden sind. Es ist keine leichte Aufgabe, ein Gleichgewicht dieser Kräfte basierend auf den Anforderungen der Anwendung zu finden. Außerdem wird das Gleichgewicht fast immer ständig verschoben. Das heißt, die Partition, die heute als erfolgreich angesehen wird, kann nach einem Jahr nicht erfolgreich sein. Als Konsequenz,Die Zusammensetzung der Komponenten wird sich mit ziemlicher Sicherheit im Laufe der Zeit ändern, und der Schwerpunkt des Projekts wird sich von einer einfachen Entwicklung zu einer einfachen Wiederverwendung verschieben. “Komponentenkompatibilität
„Die folgenden drei Prinzipien definieren die Regeln für die Beziehung zwischen Komponenten. Und wieder sind wir mit Widersprüchen zwischen einfacher Entwicklung und logischer Organisation konfrontiert. Die Kräfte, die die Architektur der Komponentenstruktur beeinflussen, sind technisch, politisch und volatil. “ADP: Acyclic Dependencies Principle - das Prinzip der Azyklizität von Abhängigkeiten.Schleifen im Komponentenabhängigkeitsdiagramm sind nicht zulässig!
Von der im Diagramm angezeigten Komponente aus bewegen Sie sich entlang der Pfeile, die die Richtung der Abhängigkeit angeben. Sie können nicht zum ursprünglichen Punkt zurückkehren. Dies ist ein azyklisch orientierter Graph (DAG - Directed Acyclic Graph).
In diesem Bild haben wir eine Abhängigkeit, die zum Auftreten eines Zyklus führt. Die daraus resultierende zyklische Abhängigkeit kann immer gebrochen werden.Methoden zum Aufheben zyklischer Abhängigkeiten
1. Durch Anwendung von DIP (Abhängigkeitsinversionsprinzip)
2. Einführung der neuen Komponente
„Die zweite Lösung beinhaltet die Abhängigkeit der Struktur der Komponenten von sich ändernden Anforderungen. In der Tat wächst und ändert sich die Struktur der Komponentenabhängigkeiten, wenn die Anwendung wächst. Daher muss es ständig auf Zyklen überprüft werden. Wenn sich Zyklen bilden, müssen sie auf die eine oder andere Weise unterbrochen werden. Manchmal ist es dafür notwendig, neue Komponenten zu erstellen, wodurch die Struktur der Abhängigkeiten wächst. “Top-Down-Design oder vielmehr seine Unpraktikabilität
„Die Komponentenstruktur kann nicht von oben nach unten entworfen werden. Diese Schlussfolgerung wird nicht sofort gezogen, sobald sie mit dem Entwurf des Systems beginnen, aber dies geschieht unweigerlich mit dem Wachstum und der Änderung des Systems.In Anbetracht eines großen Blockdiagramms wie der Struktur von Komponentenabhängigkeiten glauben wir, dass die Komponenten irgendwie die Funktionen des Systems darstellen müssen. In Wirklichkeit ist dies jedoch kein unverzichtbares Attribut von Komponentenabhängigkeitsdiagrammen.Tatsächlich spiegeln die Abhängigkeitsdiagramme der Komponenten die Funktionen der Anwendung nur schwach wider. In größerem Maße spiegeln sie die Bequemlichkeit der Montage und Wartung der Anwendung wider. Dies ist der Hauptgrund, warum sie zu Beginn der Projektentwicklung nicht entworfen wurden. Während dieses Zeitraums muss keine Software erfasst und gewartet werden, sodass keine Build- und Wartungskarte erstellt werden muss. Mit dem Aufkommen einer zunehmenden Anzahl von Modulen in den frühen Phasen der Implementierung und des Designs steigt jedoch die Notwendigkeit, Abhängigkeiten zu verwalten. Darüber hinaus besteht der Wunsch, die Auswirkungen von Änderungen so weit wie möglich zu begrenzen. Daher beginnen wir, die Prinzipien der Einzelverantwortung (SRP) und der koordinierten Änderung (CCP) zu berücksichtigen und Klassen zu kombinieren. das wird sich wahrscheinlich zusammen ändern.Eine der Hauptaufgaben einer solchen Abhängigkeitsstruktur ist die Isolierung der Variabilität. Wir brauchen keine Komponenten, die sich oft aus den kleinsten Gründen ändern und andere Komponenten betreffen, die sonst völlig stabil wären. Beispielsweise sollten kosmetische Änderungen an der Benutzeroberfläche keine Auswirkungen auf Geschäftsregeln haben. Das Hinzufügen und Ändern von Berichten sollte keine Auswirkungen auf allgemeine Richtlinien haben. Folglich wird von Architekten ein Komponentenabhängigkeitsdiagramm erstellt und erstellt, um stabile und wertvolle Komponenten vor dem Einfluss flüchtiger Komponenten zu schützen.Während sich die Anwendung entwickelt, beginnen wir uns Gedanken über die Erstellung wiederverwendbarer Elemente zu machen. In diesem Stadium beginnt das Prinzip der gemeinsamen Wiederverwendung (CRP) die Zusammensetzung der Komponenten zu beeinflussen. Schließlich beginnen wir mit dem Aufkommen von Schleifen, das Prinzip der Abhängigkeitsazyklizität (ADP) anzuwenden. Infolgedessen beginnt sich der Abhängigkeitsgraph von Komponenten zu ändern und zu wachsen.Ein Versuch, die Abhängigkeitsstruktur von Komponenten früher als Klassen zu entwerfen, schlägt wahrscheinlich fehl. Derzeit wissen wir fast nichts über die Abstimmung von Änderungen, wir stellen uns nicht vor, welche Elemente wiederholt verwendet werden können, und wir werden mit ziemlicher Sicherheit Komponenten erstellen, die zyklische Abhängigkeiten bilden. Daher sollte die Struktur der Komponentenabhängigkeiten zusammen mit dem logischen Entwurf des Systems wachsen und sich entwickeln. “Hey, bist du noch hier? Mann, das ist wichtig, du musst zumindest Hallo dazu sagen, um die Bedeutung des nächsten Teils einzugeben. Es wird ein rohes Tutorial über die Verwendung von Tulza geben.SDP: Prinzip stabiler Abhängigkeiten - das Prinzip stabiler Abhängigkeiten.Abhängigkeiten sollten auf Stabilität gerichtet sein!„Was versteht man unter„ Nachhaltigkeit “? Stellen Sie sich eine Münze vor, die auf einer Kante steht. Ist ihre Position stabil? Höchstwahrscheinlich werden Sie mit "Nein" antworten. Wenn Sie es jedoch vor Vibrationen und Windstößen schützen, kann es beliebig lange in dieser Position bleiben. Das heißt, Nachhaltigkeit hängt nicht direkt mit der Häufigkeit von Änderungen zusammen. Die Münze ändert sich nicht, aber kaum jemand wird sagen, dass sie sich am Rand in einer stabilen Position befindet.Das erklärende Wörterbuch besagt, dass Nachhaltigkeit „die Fähigkeit ist, den eigenen Zustand unter äußeren Einflüssen aufrechtzuerhalten“. Nachhaltigkeit hängt mit dem Arbeitsaufwand zusammen, der zur Änderung des Zustands erforderlich ist. Einerseits befindet sich eine Münze, die auf einer Kante steht, in einem instabilen Zustand, da das Umwerfen nur einen geringen Aufwand erfordert. Auf der anderen Seite befindet sich der Tisch in einem sehr stabilen Zustand, da das Umkippen wesentlich umfangreicher ist.Was hat das alles mit Software zu tun? Es gibt viele Faktoren, die die Änderung einer Komponente erschweren, z. B. Größe, Komplexität und Klarheit. Aber wir werden all diese Faktoren außer Acht lassen und uns auf etwas anderes konzentrieren. Es gibt eine todsichere Möglichkeit, die Änderung einer Softwarekomponente zu erschweren, indem viele andere Komponenten erstellt werden, die davon abhängen. Eine Komponente mit vielen eingehenden Abhängigkeiten ist sehr stabil, da das Abgleichen von Änderungen mit allen abhängigen Komponenten einen erheblichen Aufwand erfordert. "
Wie ist die Stabilität des Bauteils zu bewerten? Der Autor schlägt vor, die Anzahl seiner eingehenden und ausgehenden Abhängigkeiten zu berechnen und auf ihrer Grundlage das Maß für seine Stabilität zu berechnen.- Fan-in ( ): . , .
- Fan-out ( ): . , .
- I: : I = Fan-out ÷ (Fan-in + Fan-out). [0, 1]. I = 0 , I = 1 – .
Dieses Prinzip besagt also, dass die Metrik der I-Komponente größer sein sollte als die Metriken der I-Komponenten, die davon abhängen. Das heißt, die Metriken, die ich in Richtung der Abhängigkeit verringern sollte.Es ist wichtig zu beachten, dass ein solches System nicht geändert werden kann, wenn alle Komponenten des Systems so stabil wie möglich sind. Daher müssen nicht alle Komponenten stabil sein.Mann, schlafe nicht ein, ich bin in der Nähe. Nur noch ein bisschen übrig!SAP: Prinzip der stabilen Abstraktionen - das Prinzip der Stabilität von Abstraktionen. Die Stabilität einer Komponente ist proportional zu ihrer Abstraktheit.„Einige Teile von Softwaresystemen sollten sich sehr selten ändern. Diese Stücke repräsentieren hochrangige architektonische und andere wichtige Entscheidungen. Niemand möchte, dass solche Entscheidungen volatil sind. Daher muss sich Software, die Regeln auf hoher Ebene kapselt, in stabilen Komponenten befinden (I = 0). Volatile (I = 1) sollte nur veränderlichen Code enthalten - einen Code, der einfach und schnell geändert werden kann.Wenn Sie jedoch Regeln auf hoher Ebene in stabile Komponenten einfügen, wird die Änderung des Quellcodes, der sie implementiert, erschwert. Dies kann die gesamte Architektur unflexibel machen. Wie kann eine Komponente mit maximaler Stabilität (I = 0) so flexibel gemacht werden, dass sie bei Änderungen stabil bleibt? Die Antwort liegt im Prinzip der Offenheit / Schließung (OCP). Dieses Prinzip besagt, dass es möglich und notwendig ist, Klassen zu erstellen, die flexibel genug sind, damit sie unverändert vererbt (erweitert) werden können. Welche Klassen entsprechen diesem Prinzip? Abstrakt.SAP (das Prinzip der Stabilität von Abstraktionen) stellt eine Verbindung zwischen Stabilität und Abstraktheit her. Einerseits sagt er, dass eine stabile Komponente auch abstrakt sein muss, damit ihre Stabilität die Expansion nicht behindert, und andererseits sagt er, dass eine instabile Komponente konkret sein muss, weil die Instabilität es einfach macht, ihren Code zu ändern.Das heißt, eine stabile Komponente sollte aus Schnittstellen und abstrakten Klassen bestehen, damit sie leicht erweitert werden kann. Die für die Erweiterung verfügbaren ausfallsicheren Komponenten sind flexibel genug, um die Architektur nicht übermäßig einzuschränken.Die Prinzipien der Stabilität von Abstraktionen (SAP) und stabilen Abhängigkeiten (SDP) entsprechen zusammen dem Prinzip der Abhängigkeitsinversion (DIP) für Komponenten. Dies ist richtig, weil das SDP-Prinzip erfordert, dass Abhängigkeiten auf Nachhaltigkeit ausgerichtet sind, und das SAP-Prinzip besagt, dass Nachhaltigkeit Abstraktheit impliziert. Das heißt, Abhängigkeiten sollten auf Abstraktheit gerichtet sein.Das DIP-Prinzip ist jedoch für Klassen formuliert, und im Fall von Klassen gibt es keine Mitteltöne. Die Klasse ist entweder abstrakt oder nicht. Die Prinzipien von SDP und SAP gelten für Komponenten und ermöglichen eine Situation, in der eine Komponente teilweise abstrakt oder teilweise stabil ist. “Wie kann man die Abstraktheit einer Komponente messen? Auch hier ist alles sehr einfach.Der Wert des Maßes für die abstrakte Komponente wird durch das Verhältnis der Anzahl ihrer Schnittstellen und abstrakten Klassen zur Gesamtzahl der Klassen bestimmt.- Nc: Die Anzahl der Klassen in der Komponente.
- Na: Die Anzahl der abstrakten Klassen und Schnittstellen in der Komponente.
- A: abstrakt. A = Na ÷ Nc .
Der Wert der Metrik A variiert im Bereich von 0 bis 1. 0 bedeutet das vollständige Fehlen abstrakter Elemente in der Komponente, und 1 bedeutet, dass die Komponente nur abstrakte Klassen und Schnittstellen enthält.Abhängigkeit zwischen I und AWenn Sie in der Grafik (Y - Abstraktion, X - Instabilität) „gute“ Komponenten beider Typen darstellen: abstrakt stabil und konkret instabil, erhalten wir Folgendes:
Aber, weil Die Komponenten weisen unterschiedliche Abstraktions- und Stabilitätsgrade auf, die bei weitem nicht in diese beiden Punkte (0, 1) oder (1, 0) fallen. Da nicht verlangt werden kann, dass sich alle Komponenten in ihnen befinden, müssen wir davon ausgehen, dass in der Grafik A / I Es gibt einige Punkte, die die optimalen Positionen für die Komponenten bestimmen.Dieser Satz kann abgeleitet werden, indem Bereiche definiert werden, in denen sich die Komponenten nicht befinden sollten, dh Ausschlusszonen definiert werden.
SchmerzzoneBetrachten Sie die Komponenten in der Nähe des Punktes (0, 0).Sie sind sehr stabil und spezifisch. Solche Komponenten sind seitdem unerwünscht sind zu hart. Sie können nicht erweitert werden, weil sie nicht abstrakt sind und es aufgrund ihrer großen Stabilität sehr schwierig ist, sie zu ändern. Je mehr wir die Komponente ändern, die in die Schmerzzone gelangt, desto mehr Schmerz bringt sie mit sich. Dies ist auf die Komplexität seiner Änderung zurückzuführen.Richtig konstruierte Komponenten sollten sich normalerweise nicht in der Nähe des Punktes (0, 0) befinden.In der Realität gibt es jedoch Software-Entitäten, die in diese Zone fallen. Das Datenbankschema ist beispielsweise so spezifisch wie möglich und viele Abhängigkeiten erstrecken sich darauf. Dies ist einer der Gründe, warum Änderungen am Datenbankschema normalerweise mit großen Schmerzen verbunden sind.Nutzlose ZoneBetrachten Sie die Komponenten in der Nähe des Punktes (1, 1).Solche Komponenten sind auch unerwünscht, weil Sie sind so abstrakt wie möglich und haben keine Abhängigkeiten. Sie sind einfach nutzlos. Oft sind dies abstrakte Klassen, die nie implementiert wurden.Wie vermeide ich es, in Sperrzonen zu gelangen?Platzieren Sie Komponenten in der Nähe oder auf der Hauptsequenz. Solche Komponenten sind für ihre Stabilität nicht „zu abstrakt“ und für ihre Abstraktheit nicht „zu instabil“. Sie sind nicht nutzlos und verursachen nicht viel Schmerz. Andere Komponenten hängen im Ausmaß ihrer Abstraktheit von ihnen ab, und sie selbst hängen im Ausmaß der Spezifität von anderen ab.Die wünschenswertesten Positionen für die Komponenten sind die Endpunkte der Hauptsequenz. In großen Systemen gibt es jedoch immer mehrere Komponenten, die nicht abstrakt genug und nicht stabil genug sind. Solche Komponenten weisen hervorragende Eigenschaften auf, wenn sie sich auf oder in der Nähe der Hauptsequenz befinden.Der Abstand zur HauptsequenzDa es wünschenswert ist, dass sich die Komponente auf oder in der Nähe der Hauptsequenz befindet, ist es möglich, eine Metrik zu bestimmen, die den Abstand der Komponente vom Ideal ausdrückt.- D: Entfernung. D = | A + I - 1 | . Diese Metrik nimmt Werte aus dem Bereich [0, 1] an. Ein Wert von 0 zeigt an, dass sich die Komponente direkt in der Hauptsequenz befindet. Der Wert 1 gibt an, dass sich die Komponente im maximalen Abstand von der Hauptsequenz befindet.
Wenn Sie diese Metrik übernehmen, können Sie das gesamte Design in der Nähe der Hauptsequenz untersuchen. Die Metrik D kann für jede Komponente berechnet werden. Jede Komponente mit einem Metrikwert D, der weit von Null entfernt ist, muss überarbeitet und umstrukturiert werden.
Fazit des Autors (Robert Martin)
„Mit den in diesem Kapitel beschriebenen Abhängigkeitsverwaltungsmetriken können Sie die Konsistenz der Abhängigkeitsstruktur und der Entwurfsabstraktion mit dem, was ich als„ gutes “Design bezeichne, quantifizieren. Die Erfahrung zeigt, dass es gute und schlechte Abhängigkeiten gibt. Diese Bewertung spiegelt diese Erfahrung wider. Metriken sind jedoch nicht die ultimative Wahrheit. Dies sind nur Messungen, die auf einem beliebigen Standard basieren. Diese Metriken sind bestenfalls unvollständig, aber ich hoffe, Sie finden sie nützlich. “Mann, ich bin froh, wenn du noch bei mir bist. Das ist alles mit dem ersten Teil. Obwohl es immer noch viele Themen gibt und die detaillierten Gedanken des Autors unberührt blieben. Der Hauptzweck meines Artikels ist jedoch nicht, das Buch noch einmal zu erzählen, sonst würden Sie sich auf jeden Fall mehr freuen, das Original zu lesen. Ich, wandere, und so ging schon spezifisch zu weit mit der Menge an Inhalten, aber ich werde Bastard sein, ich habe versucht, nicht aufzublasen, wie ich konnte. Runden!Zweiter Tag. Umm, d.h. Teil 2
Einführung
Worüber habe ich dort so lange gerieben? "Ah, ja ... Wir sind wie Architekten, oder wir wollen sie wirklich sein, oder?"Was haben wir? - Eine miserable Projektion oder vielleicht ein monströses System, PROJECT, seine Mutter, na ja, oder schließlich gibt es noch keine Nifigur, aber wir reiben uns nur die Hände, schauen auf den Kalender und finden heraus, wie gut wir reden müssen.Es gibt keine uns, ich arbeite alleine! Oder vielleicht wollten wir mit einem Kumpel in der Garage einen neuen Apfel ausfüllen, warum nicht? Entweder sind wir die Armee und wir sind alle Teil einer starken Firma, wir arbeiten hart, wie die Schwarzen der Armen zu Hause (das heißt natürlich Afroamerikaner, verstehen Sie), oder wir treten leise, damit wir nicht gefeuert werden. Für ein fettes Gehalt mit einem Bonus, Keksen und einem Blick aus Moskau-Stadt oder für bloße Begeisterung, für eine Idee und einen Anteil an einem Startup, das natürlich die Hölle ist, wenn es abhebt.Tatsächlich spielt es keine Rolle. Was wichtig ist, ist Folgendes: Wir alle wollen am Ende einfach, dass sich unsere Idee nicht vorzeitig verbiegt, zumindest nicht vor unserer Abreise, und dafür gibt es alle Chancen. Ja, ja ...Und was tun Sie jetzt, fragen Sie? Wenn Sie also keinen großen Bruder im Büro haben, kann Bruder nicht auf ein drittes Auge verzichten.Zusammenfassung des ersten Teils
Im letzten Teil des Artikels haben wir ein wenig über Metriken gesprochen, mit denen Architekten ihre Anzahl in Zahlen messen können , um den Qualitätsgrad der Architektur ihres Systems widerzuspiegeln.A - Abstraktion der KomponenteI - Instabilität der KomponenteD - Abstand zur Hauptsequenz in der Grafik A / I Erogene Zonen der Schmerz- und Sinnlosigkeitszonen wurdenaufgedeckt . Wir kamen zu dem Schluss, dass A im Idealfall proportional zu einer Abnahme und dementsprechend einer Zunahme von I zunehmen und abnehmen sollteWerkzeug- und Testprojekt. Einführung in das Thema
Fuf, alles scheint wie eine Theorie zu sein ... Jetzt können Sie sich sogar die Hände schmutzig machen, um Details zu erfahren .Und so habe ich jetzt nicht über abstrakte Pferde in einem Vakuum zu reiben, und Sie haben das Ende der Lesung weniger Grund, mich Mudiloy zu nennen, wegen dem Sie so viel Zeit gefickt haben, ich hatte Prosrat ein wenig von ihm verbringen und eine Demo vorbereiten Projekt, das, sobstna, wir jetzt hara-kiri machen werden. Ich betone, dass dies ein DEMO-Projekt für die „super begabten“ Typen ist, die zweifellos Kommentare abgeben und in Bezug auf die Details abhängen möchten .Ich habe es in ungefähr einem halben Tag grob gesagt auf dem Knie meiner Freundin zerhackt. Schließlich kann ich die Details der Kampfprojekte, mit denen ich arbeiten muss, nicht der Öffentlichkeit zugänglich machen ... Die Jungs im Wrack werden es nicht verstehen, sie werden es mir zeigen, aber brauche ich es? Nun, wenn Sie ein einfacher Junge sind, nicht einer der "besonders herausragenden", dann bin ich für eine so lange Einführung mies, ich musste nur das Risiko eingehen und die potenzielle Gefahr der Zucht in den Kommentaren der Basare über nichts verringern.Das Projekt selbst liegt also hier: github.com/Chetkov/php-clean-architecture-example-project .In Zukunft könnte er ein vollwertiger Online-Shop werden. Ich bin sicherlich ein wilder Perfektionist, aber Sie müssen ein völliger Unsinn seinSonnenfresser und Langleber leiden nicht nur an Schlaflosigkeit, um so viel Zeit mit dem „experimentellen Kaninchen“ zu verbringen und Süßigkeiten daraus zu machen. Wie Sie verstehen, wird dieses Projekt jedoch niemals zu seinem logischen Abschluss gebracht , wie alle anderen auch Kampfprojekte.Obwohl es nicht so schlimm ist. Im Moment hat es: Benutzer, Produkt und Bestellung sowie Szenarien: Benutzerregistrierung, Passwortänderung, Hinzufügen eines Produkts und Buchen einer Bestellung .Das Projekt funktioniert mehr oder weniger, Sie können es selbst klonen und Skripte aus dem Sandbox-Ordner ausführen, obwohl ich dies tatsächlich nicht einmal tun konnte, weil Für die Analyse der Architektur ist die Bedienbarkeit des Projekts nicht erforderlich.In Zukunft werde ich Links zu bestimmten Commits erstellen, um die im Artikel beschriebenen technischen Punkte sofort zu beheben.Ausgangszustand. Ich nehme an, Sie haben es bereits geschafft, sich mit der Struktur vertraut zu machen. So können wir weitermachen.Wir enthalten PHP Clean Architecture :composer require v.chetkov/php-clean-architecture:0.0.3
Wir erstellen und konfigurieren die KonfigurationsdateiVisualisierung zur Analyse
Wir führen in der Konsole (im Projektstamm) aus:vendor/bin/phpca-build-reports
odervendor/bin/phpca-build-reports /path/to/phpca-config.php
Und als Antwort bekommen wir:Report: /path/to/reports-dir/index.html
Der Bericht besteht aus 3 Bildschirmen:1. Allgemeine Informationen zum System
Dieser Bildschirm zeigt Folgendes an:Das gleiche A / I- Diagramm zeigt die Dispersion der Komponenten:
Grafik, die die Entfernung von Komponenten aus der Hauptsequenz zeigt:
Und ein Diagramm, das die Beziehungen zwischen den Komponenten zeigt: Die
Pfeile geben die Richtung der Abhängigkeiten an, und die Zahlen darauf geben die Stärke der Verbindung an.weil Moderne IDEs bieten eine einfache Möglichkeit zum Refactor (sie selbst finden und korrigieren alle Bereiche, in denen die Methode oder Klasse explizit aufgerufen wird, z. B. beim Umbenennen oder Übertragen in einen anderen Namespace). Ich habe die Anzahl der Elemente des Abhängigkeitsmoduls verwendet, die vom abhängigen Modul für die Kommunikationsstärke verwendet werden.Zum Beispiel: die Elemente des Dienste - Modul etwa 12 Elemente des Know - Modell - Modul und die Infrastruktur - Elemente kennen 1 Element von Dienstleistungen . Usw.Übrigens, was ist * undefiniert *? Bro, die erwartete Frage. Dies ist ein Modul, das automatisch für alle Elemente erstellt wird, die während der Systemanalyse keinem der bekannten Elemente zugeordnet werden konnten (d. H. Den in der Konfigurationsdatei aufgeführten).Wenn Sie die Konfiguration jedoch folgendermaßen korrigieren:
Bei der Analyse des Systems werden auch über Composer verbundene Pakete berücksichtigt (sie selbst werden nicht gescannt, aber das Bild wird viel vollständiger).Übrigens müssen Sie in vendor_path den Pfad zum Vendor-Verzeichnis und in ausgeschlossenen Pfaden zu den Verzeichnissen von Paketen angeben, die wir ausschließen möchten (z. B. wenn wir ein Paket in der Hauptkonfiguration von Modulen zum Scannen beschreiben).Nach dem Aktivieren von vendor_based_modules Das Diagramm hat sich geändert, obwohl wir die Konfiguration der Module selbst nicht geändert haben
2. Detaillierte Informationen zur Komponente
Hier sehen wir auch:- Diagramm der Verbindungen , jedoch nicht des gesamten Systems, sondern nur der beteiligten Komponenten
- A / I-Diagramm, das nur die aktuelle Komponente zeigt
- Wichtige Modulfunktionen
und auch- Ausgehendes Abhängigkeitsdiagramm mit der Anzahl und Liste der Dateien im aktuellen Modul, abhängig von den Dateien anderer Module.
- Und ein Diagramm der eingehenden Abhängigkeiten , das die Anzahl und Liste der Dateien in anderen Modulen zeigt, abhängig vom aktuellen Modul.
Die letzten beiden Grafiken sind meiner Meinung nach besonders interessant, weil Es ist leicht, unerwünschte Abhängigkeiten von ihnen zu finden, aber dazu später mehr.3. Detaillierte Informationen zum Komponentenelement
Hier sehen Sie:- Hauptmerkmale des Elements, wie Typabstraktion, Instabilität, Grundelement, zu welcher Komponente gehört, und der Zugriffsmodifikator .
"Che, ein Klassenzugriffsmodifikator in PHP?" - Sie sagen, Sie bohren mit Ihrem Finger ein Loch in den Schläfenbereich, oder? Nehmen Sie sich Zeit, ich weiß, dass es keine Privatstunden in der Hitze gibt, aber es wäre cool, wenn sie es wären? Im Allgemeinen dazu später mehr.- Abhängigkeitsdiagramm , das die Interaktion des betrachteten Elements mit anderen Elementen des Systems widerspiegelt
- Und Tablets mit ausgehenden und eingehenden Abhängigkeiten
Wenn die Beschreibung der Bildschirme fertig ist, gehen Sie zu den Konfigurationen, um auszuwählen, wie sie konfiguriert werden können.Einstellmöglichkeiten
Begrenzen des maximal zulässigen Abstands zur Hauptsequenz (für alle Komponenten)Versuchen wir zunächst, alle Komponenten auf den maximal zulässigen Abstand zur Hauptsequenz einzustellen. Es wäre dumm zu denken, dass sie alle auf der Hauptdiagonale liegen werden, weil die Welt nicht perfekt ist, also lasst uns realistisch sein. Ich mache 0.3
Starten Sie den Berichterstellungsbefehl neu und sehen Sie sofort die Verletzung auf der Hauptseite. Die Modellkomponente überschreitet den zulässigen Abstand um 0,192
Begrenzung des maximal zulässigen Abstands zur Hauptsequenz (zu einer bestimmten Komponente)Es ist großartig, aber nehmen wir an, dass es die Modellkomponente ist, die diese Einschränkung verletzen kann. Verschiedene Dinge passieren ... Schließlich haben wir oft schon keine idealen Systeme, mit denen wir arbeiten, sie unterstützen und verbessern müssen. Jeder versteht, dass niemand in der Lage sein wird, diese Distanz schnell zu verringern, selbst wahrscheinlich mit einem Gott (ich hoffe, er wird mir vergeben).Meiner Meinung nach geht es hauptsächlich darum, den aktuellen Zustand zu verbessern, auf Verbesserungen hinzuarbeiten und die Situation zu kontrollieren, um sie nicht zu verschlimmern.Gehen Sie erneut zur Konfiguration und legen Sie max_allowable_distance nur für ein bestimmtes Modul fest. Ich fixiere auf seinen aktuellen Wert 0,492
ZBS, jetzt ist wieder alles normal.
Aber wenn er mit etwas ** ka Vasya wieder etwas raucht und schlimmer wird - hau ihm die Hände ab! Eine CI / CD, die das Ausführen des Befehls phpca-check enthält (wir werden später darauf eingehen ), schimpft mit ihm, möglicherweise sogar mit einer Schimpfwortsprache, und natürlich werden Fehler hervorgehoben.KomponentenabhängigkeitskontrolleWas wäre sonst noch schön in unserem Arsenal zu haben, um mit schlechter Architektur umzugehen? Natürlich Abhängigkeitskontrolle. Wer über wen Bescheid wissen kann oder umgekehrt, sollte es nicht wissen.Was denkst du, kann der sehr zentrale Teil des Systems, sagen wir Domain , so dass DDDowski durchaus etwas über eine stinkende Infrastruktur wissen kann ?Natürlich JA, für einige ist es direkt ein Attribut des Erfolgs (nun, ich spreche von denen, die HTML mit Geschäftslogik mischen). Aber schließlich sollte ich nicht ... Ich bin sicher xs, aber alle möglichen klugen Kerle in Büchern sagen, dass dies kein Patsansky ist.Dann lassen Sie uns so aufrühren ... Alles ist an der gleichen Stelle, in der Konfiguration der Einschränkungen für das Modell .
Hmm ... Bisher alle Regeln, weilModell über Infrastruktur weiß wirklich nichts ...Na dann lass uns Spaß haben ... Dummheit ist sicherlich selten, aber ich habe mir nichts Besseres ausgedacht. Krch, zum Zeitpunkt der Erstellung des Benutzers werden wir SMS "senden" und zum Zeitpunkt der Erstellung der Bestellung "senden" E-Mails. Und dies durch spezifische Implementierungen von Benachrichtigern, die in der Infrastruktur liegen .github.com/Chetkov/php-clean-architecture-example-project/commit/6bad365176b30999035967319a9c07fae69fabf9Nun schauen wir uns den Bericht an ... Wie wir sehen können, heben die Grafiken auf verschiedenen Seiten des Berichts diesen Zusammenhang als unzulässig hervor.Zuhause.
Komponentenbericht.
In den Diagrammen des Modells "ausgehende Abhängigkeiten" und "eingehende Abhängigkeiten"Infrastruktur sehen wir sofort Elemente, die gegen die eingeführte Regel verstoßen.
In den Tabellen der "ausgehenden Abhängigkeiten" von Modellelementen und "eingehenden Abhängigkeiten" von Infrastrukturelementen ist dies ebenfalls der Fall.PHPCAEP \ Model \ User \ User
PHPCAEP \ Infrastructure \ Notification \ Sms \ SmsNotifier
sowie im Diagramm der Elementbeziehungen. Ich denke in Zukunft, es ganz loszuwerden, weil es ist nicht sehr informativ (vor allem für aktiv verwendete Klassen, wegen der Länge des Namen der Knoten + ihre große Anzahl)
ähnliche Aktionen mit dem allowed_dependencies getan werden können Config .
Das Ergebnis ist völlig entgegengesetzt.Es ist möglich, eine Konfiguration zu erstellen, die für das Modul angibt und verboten istund erlaubt (wenn es einen Wunsch gibt, werden wir in den Kommentaren ausführlicher darauf eingehen). Es ist noch nicht möglich , eine Komponente sowohl in verboten als auch in erlaubt anzugeben ... Es gab Überlegungen, eine Konfiguration einzuführen, um die Priorität anzuzeigen, aber bisher habe ich dies nicht getan und bin nicht sicher, was ich tun werde. Es hängt alles von Ihrem Feedback ab. Vielleicht ist das alles verschwendet?Öffentliche / private Klasse in PHPOkay, wir haben gelernt, wie man den Wissensbereich von Komponenten einschränkt und kontrolliert. Schon nicht schlecht. Was kommt als nächstes?Und dann noch ein Problem. Der Feind schläft nicht, obwohl in den meisten Fällen dieser Feind wir selbst oder unsere Kumpels im Büro sind.Es passiert doch, du hast ein Mädchen getroffen, geredet, etwas über sie herausgefunden, vielleicht sogar umworben, aber verdammt, es klappt nicht für dich. Wir sind Freunde und all das ... Sie kann dich küssen, wenn sie dich trifft, sie kann dir zuhören und dich mit einem freundlichen Wort unterstützen, aber sie gibt dir nichts zu töten . Also, wovon rede ich ... Ah, hier ... Es geht nur um Zugänglichkeit.Aber im Code ständig ... Verbinden Sie ein neues Paket, kein Tag ist vergangen, aber es wird bereits verwendet, sondern direkt an alle Ortevon allen Seiten. Die Hälfte Ihrer Codebasis ist bereits an die verschiedenen Klassen gebunden. Kurz gesagt, er hat eine sehr enge Beziehung zu den anderen. Vielleicht ist dies in manchen Situationen die Norm, aber nicht in allen, oder?Sie: „Alles ist gut, es ist schüchtern. Wie kann man das Problem lösen? “Ich: "Lassen Sie nur Klassen für die Interaktion und beschränken Sie den Zugriff auf den Rest."Sie: "Aber in PHP gibt es keine Zugriffsmodifikatoren für Klassen."Ich: "Ich stimme zu, aber es gibt eine saubere PHP-Architektur ."Ein Beispiel wird nun wieder von Drogenabhängigen sein, aber was zu tun ist.In realen Projekten sind die Fälle natürlich voller Fälle, aber sie können eine Flasche zum Ablassen der Informationen mitbringen und sie bitten, sich zu setzen. Deshalb muss man komponieren.Nehmen wir an, dass es im Modell aus irgendeinem Grund nur zwei Klassen gibt, über die andere Bescheid wissen dürfen ... Benutzer und Reihenfolge, der Rest sollte ausgeblendet sein.
Was haben wir jetzt?Verlassen Sie sich auf die Hauptleitung.
Sie können sofort sehen, welche Komponenten überprüft werden müssen.Wir klettern, um zu sehen, was mit der Infrastruktur nicht stimmt .
In der Grafik „Ausgehende Abhängigkeiten“ sehen wir Elemente, die gegen die Regel verstoßen:
Auf der Seite mit den Elementinformationen ebenfalls.
Wir erhalten genau das gegenteilige Ergebnis, wenn wir private_elements in der Konfiguration angeben .
Zum Beispiel verbieten wir jedem, etwas über Fio zu wissen.Jetzt auf der Haupt-
Seite : Auf der Dienst Komponente Informationsseite :
Und auf der Elementinformationsseite PHPCAEP \ Model \ User \ Fio :
Überwachung von Verstößen gegen die Grundsätze von ADP und SDPVielleicht müssen wir dennoch die Möglichkeit hervorheben, Überprüfungen einzubeziehen:- für Verstöße gegen das ADP-Prinzip, d.h. für das Vorhandensein von zyklischen Abhängigkeiten im Diagramm ( check_acyclic_dependencies_principle )
- und für Verstöße gegen das SDP-Prinzip, d.h. für Abhängigkeiten, die von stabileren zu weniger stabilen Modulen geleitet werden ( check_stable_dependencies_principle )
Dies funktioniert aber bisher nur in phpca-check und wird im Bericht nicht angezeigt. Ich denke, ich werde es in Zukunft korrigieren.Automatische Steuerung in CI / CD
Die ganze Zeit habe ich über den ersten Teil gesprochen - Visualisierung. Und die Analyse, die auf ihrer Basis durchgeführt werden kann.Es ist an der Zeit, unsere Freunde govnokodera ehrenwerte Kollegen leiden zu lassen.Wir starten in der Konsole (im Projektstamm):vendor/bin/phpca-check
odervendor/bin/phpca-check /path/to/phpca-config.php
Es wird davon ausgegangen, dass das Ausführen dieses Befehls dem CI / CD-Prozess Ihres Projekts hinzugefügt wird. In diesem Fall blockiert der Fehler die weitere Montage.Das Skript endet mit einem Fehler und wirft ungefähr Folgendes aus:
Ich gebe den Zahn, die Liste wird in einem realen Projekt viel länger sein.Nachbesprechung- Verstoß gegen das Prinzip der Azyklizität von Abhängigkeiten (ADP)
- Ähnlich, aber der Zyklus ist etwas kürzer
- 2 Modellelemente (aufgelistet) hängen von der Infrastruktur ab , die von der Konfiguration nicht zugelassen wird
- Wieder ADP-Verletzung
- Eine weitere Schleifen- und ADP-Verletzung
- SDP-Verletzung, weil Ein nachhaltigeres Modell hängt von einer weniger nachhaltigen Infrastruktur ab
- Wieder zyklische Abhängigkeit, sei es falsch
- 1 Dienstleistungen Element (börsennotiert) , hängt von nicht-öffentlicher Fio
Ungefähr dieses Ergebnis haben wir dank unserer Bemühungen und sorgfältigen Regierungskodierung .Jetzt lass uns alles in den Arsch drehen. Nun, d.h. nicht alles, ich verlasse die config natürlich. Ich regiere nur den Code.Für den Anfang ist es sinnvoll, Dateien zu reparieren, die gegen die Regeln für die folgenden Abhängigkeiten verstoßen. In diesem Projekt werden die meisten Zyklen wahrscheinlich von selbst verschwinden, aber in realen Fällen muss definitiv länger gebastelt werden (obwohl dies vom Grad der Vernachlässigung des Systems und den Einstellungen der Konfiguration abhängt).FehlerbehebungIch habe eine zuvor erfundene Sucht entfernt.github.com/Chetkov/php-clean-architecture-example-project/commit/f6bbbff1313bb4a22dfb6061f347ef007ba3b422fRestart Verkäufer / bin / phpca-Check
Nun, es gibt nur eine Config zu bearbeiten, weil Ein Beispiel wurde wirklich von einem Drogenabhängigen erfunden.
Wieder Vendor / Bin / Phpca-Check
Und die CI / CD ging weiter!Das ist alles.Nachwort
Fangen Sie ein Fünftel, wenn Sie es bis zum Ende lesen. Wenn nicht, schnüffeln Sie mit dem Fuß auf der Straße (das haben Sie sowieso nicht gesehen).Aber im Ernst, danke für Ihre Zeit, es spielt keine Rolle, ob Sie in der Mitte zusammengeführt oder gelesen, in jede Zeile vertieft und jeden Bildschirm analysiert oder beide Teile diagonal durchgeblättert haben. Danke trotzdem.Ich entschuldige mich noch einmal, wenn etwas nicht stimmte.Vielleicht scheint meine Art der Präsentation jemandem zu imposant oder respektlos zu sein. Ich wollte den Artikel nur leicht verwässern und wollte niemanden beleidigen. Ich denke, ohne das wäre es zu trocken und schwer zu lesen gewesen.Ich bin sehr daran interessiert, Ihre Meinung zu erfahren. Wenn Sie Gedanken, Ideen, Vorschläge oder Einwände haben, lassen Sie uns dies in Kommentaren diskutieren.Sauberer Code und flexible Architektur für Sie!