Am Anfang ist es immer schwierig, sich in einem großen und alten Projekt zurechtzufinden. Architecture Assessment ist eine der Aktivitäten eines Architekten. Man muss in der Regel mit großen, alten Projekten arbeiten, und die Ergebnisse müssen innerhalb einer Woche präsentiert werden.
Wie bewertet man ein Projekt mit mehr als 100.000 Codezeilen innerhalb einer Woche und liefert dabei wirklich nützliche Ergebnisse für den Kunden?
Die meisten Architekten und Technologieleiter haben mit solchen Projektbewertungen zu tun gehabt. Es kann wie ein halbformeller Prozess aussehen oder wie ein separater Service, wie es in unserer Firma gemacht wird, auf jeden Fall hatten die meisten von Ihnen damit zu tun.
Das Original in englischer Sprache für Ihre nicht-russischsprachigen Freunde finden Sie hier: .
Unser Ansatz in der Firma
Ich werde Ihnen erklären, wie das in unserer Firma funktioniert und wie ich in solchen Situationen verfahren, aber Sie können diesen Ansatz leicht an die Bedürfnisse Ihres Projekts und Ihrer Firma anpassen.
Es gibt zwei Arten von Architecture Assessments.
Intern – wir führen es normalerweise für Projekte innerhalb der Firma durch. Jedes Projekt kann aus mehreren Gründen eine Architektur-Bewertung anfordern:
- Das Team denkt, dass ihr Projekt ideal ist, und das ist verdächtig. Wir hatten solche Fälle, und oft sind in solchen Projekten die Dinge alles andere als perfekt.
- Das Team möchte sein Projekt und seine Entscheidungen überprüfen.
- Das Team weiß, dass alles schlecht ist. Sie können sogar die Hauptprobleme und Ursachen aufzählen, wollen aber eine vollständige Liste der Probleme und Verbesserungsvorschläge erhalten.
Extern – das ist ein formellerer Prozess als die interne Bewertung. Der Kunde kommt immer nur in einem Fall, wenn alles schlecht ist – sehr schlecht. In der Regel erkennt der Kunde, dass es globale Probleme gibt, kann aber die Ursachen nicht richtig bestimmen und in Einzelteile zerlegen.
Die Architektur-Bewertung für externe Kunden ist ein komplizierterer Fall. Der Prozess sollte formalierter sein. Die Projekte sind immer groß und alt. Sie enthalten viele Probleme, Bugs und fehlerhaften Code. Der Bericht über die durchgeführte Arbeit muss innerhalb von einigen Wochen maximal vorliegen, wobei die Hauptprobleme und Verbesserungsvorschläge enthalten sein müssen. Daher, wenn wir die externe Bewertung eines Projekts verstehen, wird die interne ein Klacks sein. Lassen Sie uns den kompliziertesten Fall betrachten.
Die Architektur-Bewertung eines Enterprise-Projekts
Ein typisches Projekt zur Bewertung ist ein großes, älteres Enterprise-Projekt mit vielen Problemen. Der Kunde kommt zu uns und bittet uns, sein Projekt zu reparieren. Es ist wie mit einem Eisberg: Der Kunde sieht nur die Spitze seiner Probleme und ahnt nicht, was sich unter Wasser (tief im Code) befindet.
Probleme, über die der Kunde sich beschweren kann und von denen er wissen könnte:
- Leistungsprobleme
- Probleme mit der Benutzerfreundlichkeit der Anwendung (Usability)
- Lange Bereitstellungszeiten
- Fehlende Unit- und andere Tests
Probleme, von denen der Kunde wahrscheinlich nichts ahnt, die aber im Projekt vorhanden sein könnten:
- Sicherheitsprobleme
- Entwurfsprobleme
- Falsche Architektur
- Algorithmenfehler
- Ungeeignete Technologien
- Technische Schulden
- Falscher Entwicklungsprozess
Formeller Architektur-Bewertungsprozess
Dies ist ein formeller Prozess, den wir im Unternehmen befolgen, aber Sie können ihn an Ihr Unternehmen und Ihr Projekt anpassen.
Anfrage des Kunden
Der Kunde bittet um eine Bewertung der Architektur des aktuellen Projekts. Die verantwortliche Person auf unserer Seite sammelt grundlegende Informationen über das Projekt und wählt die benötigten Experten aus. Abhängig vom Projekt können dies unterschiedliche Experten sein.
Solution Architect – die Hauptperson, die für die Bewertung und Koordination verantwortlich ist (und oft die einzige).
Stack-spezifische Experten – .Net, Java, Python und andere technische Spezialisten je nach Projekt und Technologien
Cloud-Experten – dies können Azure-, GCP- oder AWS-Cloud-Architekten sein.
Infrastruktur – DevOps, Systemadministratoren usw.
Weitere Experten – wie Big Data, Machine Learning, Performance Engineer, Sicherheits-Experte, QA-Leiter.
Informationen zum Projekt sammeln
Sie sollten so viele Informationen wie möglich über das Projekt sammeln. Sie können je nach Situation verschiedene Techniken verwenden:
- Fragebögen und andere Kommunikationsmethoden per E-Mail. Die ineffektivste Methode.
- Online-Meetings.
- Spezielle Tools für den Informationsaustausch wie: Google-Dokumente, Confluence, Repositories usw.
- „Persönliche“ Meetings vor Ort. Die effektivste und teuerste Methode.
Was müssen Sie vom Kunden erhalten?
Grundinformationen. Worum es in dem Projekt geht. Sein Ziel und Wert. Hauptziele und Pläne für die Zukunft. Geschäftsziele und Strategien. Wichtige Probleme und gewünschte Ergebnisse.
Projektinformationen. Technologiestack, Frameworks, Programmiersprachen. On-Premise oder Cloud-Deployment. Wenn das Projekt in der Cloud ist, welche Dienste werden genutzt? Welche Architektur- und Designmuster wurden angewendet?
Nicht-funktionale Anforderungen. Alle Anforderungen, die mit der Leistung, Verfügbarkeit und Benutzerfreundlichkeit des Systems zusammenhängen. Sicherheitsanforderungen usw.
Grundlegende Use-Cases und Datenflüsse.
Zugriff auf den Quellcode. Der wichtigste Teil! Sie sollten unbedingt Zugang zu den Repositories und der Dokumentation erhalten, wie das Projekt aufgebaut wird.
Zugriff auf die Infrastruktur. Es wäre gut, Zugang zur Stage- oder Produktionsinfrastruktur zu bekommen, um mit einem 'lebenden' System zu arbeiten. Es ist ein großer Vorteil, wenn der Kunde Tools zur Überwachung der Infrastruktur und Leistung hat. Über diese Tools werden wir im nächsten Abschnitt sprechen.
Dokumentation. Wenn der Kunde Dokumentation hat, ist das ein guter Anfang. Sie kann veraltet sein, aber es ist trotzdem ein guter Anfang. Glauben Sie niemals der Dokumentation – überprüfen Sie sie mit dem Kunden, an der realen Infrastruktur und im Quellcode.
Prozess der Architekturbeurteilung
Wie können wir eine so große Menge an Informationen in so kurzer Zeit verarbeiten? Zuerst einmal, arbeiten Sie parallel.
DevOps sollte sich die Infrastruktur ansehen. Der Tech Lead sollte den Code überprüfen. Der Performance Engineer sollte die Leistungskennzahlen betrachten. Der Datenbankspezialist sollte tiefer in die Datenstrukturen einsteigen.
Aber das ist der ideale Fall, wenn Sie viele Ressourcen haben. Normalerweise führen ein bis drei Personen die Projektbewertung durch. Sie können die Bewertung selbst durchführen, was oft der Fall ist, wenn Sie über das nötige Wissen und die Erfahrung in allen Projektbereichen 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 ausreichender Erfahrung werden Sie schnell die Qualität der Dokumentation beurteilen können. Was dort wahr ist und was offensichtlich nicht mit der Realität übereinstimmt. Manchmal stoßen Sie auf eine Architektur in der Dokumentation, die in der realen Welt niemals funktionieren wird. Das ist ein Anlass für Sie, darüber nachzudenken, wie es tatsächlich im Projekt umgesetzt wurde.
Nützliche Werkzeuge zur Automatisierung der Projektbewertung
Codebewertung ist eine einfache Übung. Sie können statische Code-Analysewerkzeuge verwenden, die Design-, Leistungs- und Sicherheitsprobleme aufzeigen. Hier sind einige davon:
ist ein großartiges Werkzeug für Architekten. Es zeigt Ihnen das Gesamtbild, die Abhängigkeiten zwischen Modulen und potenzielle Bereiche für Refactoring. Wie bei allen guten Werkzeugen kostet es gutes Geld, aber gleichzeitig können Sie die 30-tägige Testversion nutzen.
ist ein altbewährtes Tool. Ein Werkzeug zur statischen Code-Analyse. Es ermöglicht, schlechten Code, Bugs und Sicherheitsprobleme in mehr als 20 Programmiersprachen zu identifizieren.
Alle Cloud-Anbieter haben Überwachungstools für die Infrastruktur. Dies ermöglicht Ihnen, die Effizienz der Infrastruktur hinsichtlich Kosten und Leistung korrekt zu bewerten. Für AWS ist das . Für Azure ist das einfach .
Zusätzliche Leistungsüberwachung und Protokollierung helfen, Leistungsprobleme auf allen Ebenen zu finden. Von ineffizienten Abfragen in der Datenbank über das Backend bis hin zum Frontend. Selbst wenn der Kunde diese Werkzeuge zuvor nicht installiert hat, können Sie sie relativ schnell in das bestehende System integrieren, um Leistungsprobleme zu ermitteln.
Wie immer kosten gute Werkzeuge entsprechend viel. Ich kann Ihnen ein paar kostenpflichtige Werkzeuge empfehlen. Natürlich können Sie auch Open Source verwenden, aber das wird mehr Zeit in Anspruch nehmen. Und das sollte im Voraus geschehen, nicht während der Bewertung der Architektur.
ist ein Werkzeug zur Bewertung der Anwendungsleistung.
ist ein Cloud-Service zur Überwachung von Systemen.
Für Sicherheitstests gibt es viele Werkzeuge. Diesmal empfehle ich Ihnen ein kostenloses Werkzeug zum Scannen von Systemen.
ist ein Werkzeug zur Überprüfung von Webanwendungen auf die Einhaltung von Sicherheitsstandards.
Wir bringen alles zusammen.
Wir erstellen einen Bericht.
Beginnen Sie Ihren Bericht mit den gesammelten Daten vom Kunden. Beschreiben Sie die Projektziele, Einschränkungen und nicht-funktionale Anforderungen. Danach sollten alle Eingabedaten erwähnt werden: Quellcode, Dokumentation, Infrastruktur.
Der nächste Schritt. Geben Sie alle Probleme an, die Sie manuell oder mit automatisierten Werkzeugen gefunden haben. Große automatisch generierte Berichte fügen Sie am Ende in den Anhang ein. Hier sollten kurze und prägnante Beweise für gefundene Probleme stehen.
Priorisieren Sie die gefundenen Probleme nach der Skala Fehler, Warnung, Info. Sie können Ihre eigene Skala wählen, aber diese ist allgemein anerkannt.
Als echter Architekt sind Sie verpflichtet, Empfehlungen zur Behebung der gefundenen Probleme zu geben. Beschreiben Sie Verbesserungen und den geschäftlichen Nutzen, den der Kunde erhalten wird. Wie man den geschäftlichen Nutzen von wir bereits zuvor besprochen haben.
Bereiten Sie einen Fahrplan mit kleinen Iterationen vor. Jede Iteration sollte Zeit für die Durchführung, eine Beschreibung, die benötigte Anzahl an Ressourcen zur Verbesserung, den technischen und geschäftlichen Wert enthalten.
Wir beenden die Architekturbeurteilung und liefern dem Kunden den Bericht.
Versenden Sie nie einfach den Bericht per E-Mail. Dieser könnte entweder überhaupt nicht gelesen oder gelesen und ohne angemessene Erklärung nicht verstanden werden. Kurz gesagt – persönliche Kommunikation hilft, Missverständnisse zwischen Menschen zu beseitigen. Sie sollten ein Meeting mit dem Kunden vereinbaren und über die gefundenen Probleme sprechen, wobei der Schwerpunkt auf den signifikantesten liegt. Es ist wichtig, den Kunden auf Probleme hinzuweisen, von denen er vielleicht nicht einmal wusste. Dazu gehören Sicherheitsprobleme, und erklären Sie, wie diese das Geschäft beeinträchtigen können. Zeigen Sie Ihren Fahrplan mit Verbesserungen und diskutieren Sie verschiedene Optionen, die besser für den Kunden geeignet sind. Das können Zeit, Ressourcen und Arbeitsumfang sein.
Fassen Sie am Ende Ihres Meetings die Ergebnisse zusammen und senden Sie dem Kunden Ihren Bericht.
Abschließend
Die Bewertung der Architektur ist ein komplexer Prozess. Um die Bewertung ordnungsgemäß durchzuführen, müssen Sie über ausreichende Erfahrung und Kenntnisse verfügen.
Es ist möglich, dem Kunden innerhalb einer Woche nützliche Ergebnisse für ihn und sein Geschäft zu liefern. Selbst wenn Sie dies alleine tun.
Nach meinen Erfahrungen wurden viele Verbesserungen mitten im Prozess gestoppt oder wurden manchmal nie begonnen. Diejenigen, die sich für einen goldenen Mittelweg entschieden und nur einen Teil der Verbesserungen umgesetzt haben, die maximalen Nutzen für das Geschäft mit minimalem Aufwand bringen, haben die Qualität ihres Produkts erheblich verbessert. Diejenigen, die nichts taten, könnten ihr Projekt nach ein paar Jahren ganz schließen.
Ihr Ziel ist es, dem Kunden die größten Verbesserungen zum minimalen Preis zu zeigen.
Weitere Artikel aus dem Bereich kann man in Ruhe lesen.
Ich wünsche Ihnen sauberen Code und gute architektonische Lösungen.
Unsere Facebook-Gruppe — .
Quelle: habr.com
