Benutzerdefinierte Analyse-Regeln: Ihre Architektur, Ihre Standards

Architekturanalysen sind seit dem Start eine der beliebtesten Funktionen von Archyl. Richten Sie den Analysator auf Ihre Architektur und er identifiziert potenzielle Probleme: Single Points of Failure, zirkuläre Abhängigkeiten, verwaiste Elemente, fehlende Dokumentation. Teams sagen uns, es ist, als hätten sie einen Senior-Architekten, der ihr Systemdesign kontinuierlich überprüft.

Aber wir hörten immer wieder dasselbe Feedback: "Diese Warnung trifft auf uns nicht zu."

Vielleicht teilen Ihre Microservices absichtlich eine Datenbank während einer schrittweisen Migration. Vielleicht hat eine Komponente viele eingehende Abhängigkeiten, weil es eine gemeinsam genutzte Utility-Bibliothek ist—kein Kopplungsproblem, sondern gute Code-Wiederverwendung. Oder Ihr Team hat entschieden, dass acht Verbindungen zu einem Service in Ordnung sind, obwohl unser Standardschwellenwert es markiert.

Generische Regeln können Ihren Kontext nicht berücksichtigen. Also geben wir Ihnen die Kontrolle.

Sieben Regeln, Ihre Schwellenwerte

Archyl ermöglicht es Ihnen jetzt, die Analyse-Regeln anzupassen, die Ihre Architektur untersuchen. Wir haben sieben Muster identifiziert, die für die Architekturgesundheit wichtig sind, und Sie können jetzt jedes an die Standards Ihres Teams anpassen.

Der Single Point of Failure-Detektor findet Elemente, von denen zu viele andere Komponenten abhängen. Standardmäßig markieren wir alles mit drei oder mehr eingehenden Abhängigkeiten, aber wenn Ihre Architektur absichtlich bestimmte Belange zentralisiert, können Sie diesen Schwellenwert auf fünf, zehn oder was auch immer sinnvoll ist, erhöhen. Kritische Infrastruktur wie Datenbanken erhält immer besondere Aufmerksamkeit—wir haben gelernt, dass eine Datenbank, die zum SPOF wird, fast immer wissenswert ist.

Die Hohe-Kopplung-Analyse betrachtet beide Richtungen: Elemente, die von zu vielen Dingen abhängen (ausgehend) und Elemente, von denen zu viele Dinge abhängen (eingehend). Die Standardwerte—sechs ausgehend, vier eingehend—funktionieren für die meisten Codebasen gut, aber ein Plattform-Team, das gemeinsam genutzte Bibliotheken erstellt, möchte möglicherweise höhere Schwellenwerte als ein Produktteam, das fokussierte Features erstellt.

Überverbundene Elemente fangen ein anderes Problem ab: Komponenten, die so viele Gesamtverbindungen haben, dass sie schwer zu verstehen sind. Acht Verbindungen mögen für Ihr API-Gateway in Ordnung sein, aber besorgniserregend für einen Domain-Service. Passen Sie den Schwellenwert an Ihre Architekturmuster an.

Zirkuläre Abhängigkeiten sind fast immer problematisch—sie erschweren Tests, verursachen Initialisierungsprobleme und signalisieren unklare Grenzen. Diese Regel ist binär: ein oder aus. Wenn Sie absichtlich zirkuläre Referenzen aus irgendeinem Grund verwenden, schalten Sie sie aus. Die meisten Teams lassen sie aktiviert.

Verwaiste Elemente finden Architekturkomponenten ohne jegliche Verbindungen. Manchmal ist das ein Dokumentationsversehen; manchmal ist es ein veralteter Service, den Sie vergessen haben zu entfernen. Die Regel markiert sie, damit Sie entscheiden können.

Sicherheitsmuster erkennen besorgniserregende Architekturentscheidungen wie externe Systeme mit direktem Datenbankzugriff. Dies sind Ergebnisse mit kritischem Schweregrad, über die die meisten Teams sofort Bescheid wissen möchten.

Fehlende Dokumentation hilft bei der Aufrechterhaltung der Abdeckung, aber bei einer Codebasis mit Tausenden von Komponenten erzeugt das Markieren jedes undokumentierten Elements Rauschen. Sie können einen Schwellenwert setzen—Dokumentation nur prüfen, wenn Sie weniger als 20 Komponenten haben, oder 50, oder 500. Skalieren Sie die Regel auf Ihre Architekturgröße.

Organisationsweite Konsistenz

Diese Einstellungen gelten für Ihre gesamte Organisation, nicht pro Projekt. Wir haben diese Entscheidung absichtlich getroffen.

Architekturstandards sollten konsistent sein. Wenn Ihr Plattform-Team entscheidet, dass vier eingehende Abhängigkeiten der Schwellenwert für hohe Kopplung ist, sollte dieser Standard überall gelten. Neue Projekte erben automatisch die Regeln der Organisation. Teams können nicht versehentlich (oder absichtlich) lockerere Standards setzen, die technische Schulden verursachen.

Die Einstellungen leben in Ihrer Organisationskonfiguration. Jeder mit Bearbeitungsberechtigungen kann sie anpassen, und Änderungen werden sofort wirksam—Archyl analysiert Ihre Architektur mit den neuen Regeln neu und aktualisiert das Analyse-Dashboard.

Der Regeln-Tab

Wir haben einen dedizierten Regeln-Bereich zur Analyseseite hinzugefügt. Jede Regel erscheint als Karte mit einem Umschalter und, wo zutreffend, Schwellenwerteingaben.

Für schwellenwertbasierte Regeln sehen Sie den aktuellen Wert, den erlaubten Bereich und den Standard. Schieben Sie den Schwellenwert nach oben, um permissiver zu sein, nach unten, um strenger zu sein. Die Oberfläche validiert Ihre Eingaben—Sie können keine unmöglichen Werte setzen oder Konfigurationen erstellen, die keinen Sinn ergeben.

Für binäre Regeln wie die Erkennung zirkulärer Abhängigkeiten ist es ein einfacher Ein/Aus-Schalter. Die Karte erklärt, was die Regel erkennt, damit Sie eine informierte Entscheidung treffen können, ob sie für Ihre Codebasis wichtig ist.

Wenn Sie Einstellungen ändern, erscheint unten auf der Seite eine Speichern-Schaltfläche. Klicken Sie darauf, und Archyl führt sofort die Analyse mit Ihrer neuen Konfiguration erneut durch. Innerhalb von Sekunden sehen Sie die aktualisierten Analysen, die Ihre benutzerdefinierten Regeln widerspiegeln.

Es gibt auch eine Zurücksetzen-Schaltfläche, die alle Standardwerte wiederherstellt, wenn Sie neu anfangen möchten.

Was Sich in der Praxis Ändert

Mit anpassbaren Regeln wird das Analyse-Dashboard wirklich nützlich statt einer Quelle für Alert-Müdigkeit.

Teams sagen uns, dass sie früher auf die Analysen geschaut haben, eine Wand von Warnungen sahen, die sie bereits entschieden hatten zu ignorieren, und den Tab geschlossen haben. Jetzt konfigurieren sie die Regeln passend zu ihren tatsächlichen Standards, und wenn eine Analyse erscheint, ist es etwas, das es wert ist, untersucht zu werden.

Die Schweregrade helfen bei der Priorisierung. Single Points of Failure in kritischer Infrastruktur werden als Kritisch angezeigt. Zirkuläre Abhängigkeiten sind Hoch. Überverbundene Elemente sind Mittel. Fehlende Dokumentation ist Niedrig. Sie können sich zuerst auf die roten Punkte konzentrieren, wissend, dass Ihre Schwellenwerte auf Ihren Kontext kalibriert sind.

Und weil Analysen automatisch aktualisiert werden, wenn sich Regeln ändern, können Sie experimentieren. Neugierig, wie Ihre Architektur mit strengeren Kopplungsregeln aussieht? Passen Sie den Schwellenwert an, speichern Sie und sehen Sie. Zu viel Rauschen? Drehen Sie es zurück. Die Feedback-Schleife ist sofort.

Erste Schritte

Benutzerdefinierte Analyse-Regeln sind auf allen Plänen verfügbar. Navigieren Sie zu Analysen, klicken Sie auf den Regeln-Tab und beginnen Sie mit der Anpassung.

Wir empfehlen, mit den Standardwerten zu beginnen und basierend auf dem, was Sie sehen, anzupassen. Wenn eine bestimmte Regel Warnungen generiert, die Sie konsequent ignorieren, ist das ein Signal, entweder die zugrunde liegende Architektur zu korrigieren oder den Schwellenwert anzupassen. Beides sind gültige Entscheidungen—das Ziel ist, Analysen umsetzbar zu machen, nicht willkürliche Metriken zu verfolgen.

Ihre Architektur hat ihre eigenen Eigenschaften, ihre eigenen absichtlichen Kompromisse, ihre eigene Definition von "gut genug". Jetzt kann Ihre Governance das widerspiegeln.

Möchten Sie sehen, wie KI-gestützte Analysen funktionieren? Lesen Sie über KI-gestützte Architektur-Entdeckung, um zu verstehen, wie Archyl Ihre Codebasis analysiert und Architekturempfehlungen generiert.