⬇️ 🛌 😻 Lesen und Korrigieren von 100.000 Codezeilen pro Woche 🤴 🌧️ 📉

Am Anfang ist es immer schwierig, das große und alte Projekt herauszufinden. Die Bewertung der Architektur ist eine der Aktivitäten des Architekten. Normalerweise müssen Sie mit großen, alten Projekten arbeiten und die Ergebnisse müssen in einer Woche vorliegen.

So bewerten Sie ein Projekt mit einer Größe von 100.000 oder mehr Codezeilen pro Woche und liefern dem Kunden wirklich nützliche Ergebnisse.

Die meisten Architekten und diese Leiter sind auf ähnliche Projektevaluierungen gestoßen. Es kann wie ein semi-formaler Prozess oder als separater Service aussehen, wie er in unserem Unternehmen durchgeführt wird, jedenfalls haben sich die meisten von Ihnen damit befasst.

Das Original-Englisch für Ihre nicht russischsprachigen Freunde ist hier: Architekturbewertung in einer Woche .

Der Ansatz in unserem Unternehmen

Ich werde Ihnen sagen, wie es in unserem Unternehmen funktioniert und wie ich in solchen Situationen agiere, aber Sie können diesen Ansatz leicht an die Bedürfnisse Ihres Projekts und Ihres Unternehmens anpassen.

Es gibt zwei Arten der Architekturbewertung.

Intern - normalerweise machen wir das für Projekte innerhalb des Unternehmens. Jedes Projekt kann aus mehreren Gründen eine Architekturbewertung anfordern:

Das Team findet das Projekt perfekt und das ist verdächtig. Wir hatten solche Fälle und oft ist in solchen Projekten alles andere als perfekt.
Das Team möchte sein Projekt und seine Entscheidungen testen.
Das Team weiß, dass alles schlecht ist. Sie können sogar die Hauptprobleme und -ursachen auflisten, möchten jedoch eine vollständige Liste der Probleme und Empfehlungen zur Verbesserung des Projekts.

Extern ist ein formellerer Prozess als interne Bewertung. Ein Kunde kommt immer nur in einem Fall, wenn alles schlecht ist - sehr schlecht. Normalerweise versteht der Client, dass es globale Probleme gibt, kann die Ursachen jedoch nicht richtig ermitteln und in Komponenten aufteilen.

Die Bewertung der Architektur für einen externen Client ist ein komplexerer Fall. Der Prozess sollte formeller sein. Projekte sind immer groß und alt. Sie haben viele Probleme, Fehler und krummen Code. Ein Bericht über die geleistete Arbeit sollte innerhalb von maximal wenigen Wochen vorliegen, wo die Hauptprobleme und Verbesserungsvorschläge vorliegen sollten. Wenn wir uns also mit der externen Bewertung des Projekts befassen, dann ist es intern ein paar Unsinn. Betrachten Sie den schwierigsten Fall.

Bewertung der Architektur eines Unternehmensprojekts

Ein typisches Evaluierungsprojekt ist ein großes, altes Unternehmensprojekt mit vielen Problemen. Ein Kunde kommt zu uns und bittet ihn, sein Projekt zu reparieren. Es ist wie bei einem Eisberg, der Kunde sieht nur die Spitze seiner Probleme und weiß nicht, was sich unter Wasser befindet (im hinteren Teil des Codes).

Probleme, über die sich der Kunde beschweren kann und die er möglicherweise kennt:

Performance-Probleme
Usability-Probleme
Lange Bereitstellung
Fehlende Einheit und andere Tests

Probleme, die dem Kunden höchstwahrscheinlich nicht bekannt sind, aber möglicherweise im Projekt vorhanden sind:

Sicherheitsprobleme
Designprobleme
Falsche Architektur
Algorithmische Fehler
Unangemessene Technologie
Technische Schulden
Ungültiger Entwicklungsprozess

Bewertungsprozess für die formale Architektur

Dies ist ein formaler Prozess, den wir im Unternehmen einhalten. Sie können ihn jedoch je nach Unternehmen und Projekt selbst anpassen.

Kundenanfrage

Der Client bittet darum, die Architektur des aktuellen Projekts zu bewerten. Die verantwortliche Person unsererseits sammelt grundlegende Informationen über das Projekt und wählt die erforderlichen Experten aus. Je nach Projekt können dies unterschiedliche Experten sein.

Solution Architect ist die Hauptperson, die für die Bewertung und Koordination verantwortlich ist (und oft die einzige).
Stapelspezifische Experten - .Net, Java, Python und andere technische Experten, abhängig von den Projekt- und
Cloud-Expertentechnologien - können Azure-, GCP- oder AWS-Cloud-Architekten sein.
Infrastruktur - DevOps, Systemadministrator usw.
Andere Experten sind Big Data, maschinelles Lernen, Performance Engineer, Sicherheitsexperte und QS-Leiter.

Sammlung von Projektinformationen

Sie sollten so viele Informationen wie möglich über das Projekt sammeln. Sie können je nach Situation unterschiedliche Techniken anwenden:

Fragebögen und andere Kommunikationsmittel per Post. Der ineffizienteste Weg.
Online-Meetings.
Spezielle Tools für den Informationsaustausch wie: Google Doc, Confluence, Repositorys usw.
Live-Meetings vorhanden. Der effektivste und teuerste Weg.

Was soll vom Kunden erhalten werden?

Grundinformation. Worum geht es in dem Projekt? Sein Zweck und Wert. Die Hauptziele und Pläne für die Zukunft. Geschäftsziele und -strategien. Die Hauptprobleme und das gewünschte Ergebnis.

Informationen zum Projekt . Technologischer Stack, Frameworks, Programmiersprachen. On-Premise- oder Cloud-Bereitstellung. Wenn sich das Projekt in der Cloud befindet, welche Dienste werden verwendet? Welche Architektur- und Designmuster wurden verwendet?

Keine funktionalen Anforderungen . Alle Anforderungen in Bezug auf Leistung, Verfügbarkeit und Benutzerfreundlichkeit des Systems. Sicherheitsanforderungen usw.

Grundlegende Juskeys und Datenströme.

Zugriff auf den Quellcode . Der wichtigste Teil! Sie sollten auf jeden Fall Zugriff auf Repositorys und Dokumentationen zum Zusammenstellen eines Projekts erhalten.

Zugang zur Infrastruktur . Es wäre schön, Zugang zur Bühne oder Produktionsinfrastruktur zu erhalten, um mit einem Live-System arbeiten zu können. Dies ist ein großer Erfolg, wenn der Kunde über Tools zur Überwachung der Infrastruktur und Produktivität verfügt. Wir werden im nächsten Abschnitt über diese Tools sprechen.

Dokumentation . Wenn der Client über Dokumentation verfügt, ist dies ein guter Anfang. Es mag veraltet sein, aber es ist immer noch ein guter Anfang. Glauben Sie niemals der Dokumentation - überprüfen Sie sie mit dem Kunden, auf einer realen Infrastruktur und im Quellcode.

Architekturbewertungsprozess

Wie kann man dann in so kurzer Zeit so viele Informationen verarbeiten? Parallelisieren Sie zunächst die Arbeit.

DevOps sollte sich mit der Infrastruktur befassen. Ich führe diese in den Code. Leistungsingenieur siehe Leistungsmetriken. Ein Datenbankspezialist sollte sich eingehender mit Datenstrukturen befassen.

Dies ist jedoch ein idealer Fall, wenn Sie über viele Ressourcen verfügen. In der Regel wird ein Projekt von ein bis drei Personen bewertet. Sie können sogar selbst eine Bewertung durchführen, was häufig der Fall ist, wenn Sie über die erforderlichen Kenntnisse und Erfahrungen in allen Bereichen des Projekts verfügen. In diesem Fall müssen Sie alle Prozesse so weit wie möglich automatisieren.

Leider müssen Sie die Dokumentation manuell lesen. Mit der richtigen Erfahrung können Sie die Qualität der Dokumentation schnell verstehen. Was dort wahr ist und was eindeutig nicht mit der Realität übereinstimmt. Manchmal finden Sie eine solche Architektur in der Dokumentation, die im wirklichen Leben niemals funktioniert. Dies ist ein Auslöser, über den Sie nachdenken müssen, aber wie wird dies in der Realität im Projekt durchgeführt?

Nützliche Tools zur Automatisierung der Projektevaluierung

Das Auswerten eines Codes ist eine einfache Übung. Sie können statische Code-Analysatoren verwenden, um Design-, Leistungs- und Sicherheitsprobleme anzuzeigen. Hier einige davon:

Struktur 101 ist ein großartiges Werkzeug für einen Architekten. Es zeigt Ihnen das Gesamtbild, die Beziehung zwischen den Modulen und den potenziellen Bereichen für das Refactoring. Wie alle guten Tools kostet es viel Geld, gleichzeitig können Sie die 30-Tage-Testversion verwenden.

SonarQube ist ein gutes altes Tool. Tool zur statischen Code-Analyse. Ermöglicht das Erkennen von fehlerhaftem Code, Fehlern und Sicherheitsproblemen für mehr als 20 Programmiersprachen.

Alle Cloud-Anbieter verfügen über Tools zur Infrastrukturüberwachung. Auf diese Weise können Sie die Effektivität der Infrastruktur in Bezug auf Kosten und Leistung korrekt bewerten. Für AWS ist dies ein vertrauenswürdiger Berater . Für Azure ist es nur ein Azure Advisor .

Zusätzliche Leistungsüberwachung und -protokollierung können Ihnen dabei helfen, Leistungsprobleme auf allen Ebenen zu finden. Ausgehend von einer Datenbank mit ineffizienten Abfragen, einem Backend und endend mit einem Frontend. Auch wenn der Client diese Tools noch nicht installiert hat, können Sie sie schnell in Ihr vorhandenes System integrieren, um Leistungsprobleme zu identifizieren.

Gute Werkzeuge sind es wie immer wert. Ich kann ein paar kostenpflichtige Tools empfehlen. Natürlich können Sie Open Source verwenden, aber dafür benötigen Sie mehr Zeit. Dies sollte im Voraus erfolgen und nicht bei der Bewertung der Architektur.

New Relic - Tool
zur Bewertung der Anwendungsleistung Datadog - Cloud-basierter Schwesterüberwachungsdienst

Es gibt viele Tools für Sicherheitstests. Dieses Mal empfehle ich Ihnen einen kostenlosen System-Scan-Tool.

OWASP ZAP ist ein Tool zum Scannen von Webanwendungen auf Einhaltung von Sicherheitsstandards.

Alles zusammenfügen.

Wir bereiten einen Bericht vor

Beginnen Sie Ihren Bericht mit Kundendaten. Beschreiben Sie die Ziele des Projekts, Einschränkungen und nicht funktionale Anforderungen. Danach sollten alle eingehenden Daten als Quellcode, Dokumentation und Infrastruktur angegeben werden.

Der nächste Schritt. Listen Sie alle Probleme auf, die Sie manuell oder mithilfe automatisierter Tools gefunden haben. Platzieren Sie große automatisch generierte Berichte am Ende im Anwendungsbereich. Hier sollte ein kurzer und prägnanter Beweis für die gefundenen Probleme sein.
Priorisieren Sie die auf der Fehler-, Warn- und Infoskala festgestellten Probleme. Sie können Ihre eigene Waage wählen, dies wird jedoch allgemein akzeptiert.

Als echter Architekt müssen Sie Empfehlungen zur Behebung der gefundenen Probleme geben. Beschreiben Sie die Verbesserungen und den Wert für das Unternehmen, den der Kunde erhalten wird. Wie man den Geschäftswert von zeigtArchitektur-Refactoring, das wir zuvor besprochen haben.

Bereiten Sie eine Roadmap mit kleinen Iterationen vor. Jede Iteration sollte Zeit für die Ausführung, Beschreibung, Menge der für Verbesserungen erforderlichen Ressourcen, technischen Wert und Wert für das Geschäft enthalten.

Wir beenden die Architekturbewertung und liefern dem Kunden einen Bericht

Senden Sie niemals einfach einen Bericht per Post. Es kann ohne angemessene Erklärung überhaupt gelesen oder gelesen oder nicht verstanden werden. Kurz gesagt, die Kommunikation hilft, Missverständnisse zwischen Menschen zu beseitigen. Sie sollten ein Meeting mit dem Kunden vereinbaren und über die festgestellten Probleme sprechen, wobei Sie sich auf die wichtigsten konzentrieren sollten. Es lohnt sich, den Kunden auf Probleme zu achten, die er möglicherweise nicht einmal vermutet. B. Sicherheitsprobleme und erläutern, wie sie sich auf ein Unternehmen auswirken können. Zeigen Sie Ihre Roadmap mit Verbesserungen und diskutieren Sie verschiedene Optionen, die für den Kunden besser geeignet sind. Es kann Zeit, Ressourcen, Arbeitsaufwand sein.

Senden Sie als Zusammenfassung Ihrer Kundgebung Ihren Bericht an den Kunden.

Abschließend

Die Bewertung der Architektur ist ein komplexer Prozess. Um eine Bewertung ordnungsgemäß durchführen zu können, müssen Sie über genügend Erfahrung und Wissen verfügen.

Es ist real - dem Kunden in nur einer Woche nützliche Ergebnisse für ihn und sein Unternehmen zu liefern. Auch wenn du es alleine machst.

Aufgrund meiner Erfahrung wurden viele Verbesserungen in der Mitte heruntergeladen und manchmal nie gestartet. Diejenigen, die sich für einen Mittelweg entschieden und nur einen Teil der Verbesserungen vorgenommen haben, die für Unternehmen mit minimalem Arbeitsaufwand am nützlichsten waren, haben die Qualität ihres Produkts erheblich verbessert. Diejenigen, die nach ein paar Jahren nichts unternommen haben, konnten das Projekt vollständig abschließen.

Ihr Ziel ist es, dem Kunden maximale Verbesserung zum niedrigsten Preis zu zeigen.

Weitere Artikel aus dem Bereich Architektur können Sie nach Belieben lesen.

Ich wünsche Ihnen sauberen Code und gute architektonische Lösungen.

Unsere Facebook-Gruppe ist Software Architecture and Development .

Lesen und Korrigieren von 100.000 Codezeilen pro Woche