Am Anfang ist es immer schwierig, ein großes und altes Projekt zu verstehen. Architektur ist eine der Tätigkeiten einer Architektenbewertung. Normalerweise muss man mit großen, alten Projekten arbeiten und die Ergebnisse müssen innerhalb einer Woche geliefert werden.
So evaluieren Sie ein Projekt mit 100 oder mehr Codezeilen in einer Woche und liefern dennoch Ergebnisse, die für den Kunden wirklich nützlich sind.
Die meisten Architekten und technischen Leiter sind mit ähnlichen Projektbewertungen konfrontiert. Dies kann wie ein halbformeller Prozess aussehen oder wie eine separate Dienstleistung, wie sie in unserem Unternehmen durchgeführt wird. Die meisten von Ihnen haben dies auf die eine oder andere Weise getan.
Das Original auf Englisch für Ihre nicht Russisch sprechenden Freunde finden Sie hier: .
Der Ansatz unseres Unternehmens
Ich erzähle Ihnen, wie es in unserem Unternehmen funktioniert und wie ich mich in ähnlichen Situationen verhalte. Sie können diesen Ansatz jedoch problemlos an die Bedürfnisse Ihres Projekts und Unternehmens anpassen.
Es gibt zwei Arten der Architekturbewertung.
Intern – Wir machen das meist für Projekte innerhalb des Unternehmens. Jedes Projekt kann aus mehreren Gründen eine Architekturbewertung erfordern:
- Das Team hält sein Projekt für perfekt und das ist verdächtig. Wir hatten solche Fälle und oft ist bei solchen Projekten alles andere als ideal.
- Das Team möchte sein Projekt und seine Lösungen testen.
- Das Team weiß, dass es schlecht läuft. Möglicherweise listen sie sogar die Hauptprobleme und -ursachen auf, möchten aber eine vollständige Liste der Probleme und Empfehlungen zur Verbesserung des Projekts.
Externe ist ein formellerer Prozess als eine interne Bewertung. Der Kunde kommt immer nur in einem Fall, wenn alles schlecht ist – sehr schlecht. Normalerweise versteht der Kunde, dass es globale Probleme gibt, kann aber die Ursachen nicht richtig identifizieren und sie in Komponenten zerlegen.
Die Bewertung einer Architektur für einen externen Kunden ist ein komplexerer Fall. Der Prozess sollte formeller sein. Die Projekte sind immer groß und alt. Sie haben viele Probleme, Fehler und fehlerhaften Code. Innerhalb weniger Wochen sollte ein Bericht über die geleistete Arbeit vorliegen, der die wesentlichen Probleme und Verbesserungsvorschläge enthalten sollte. Wenn wir uns also mit der externen Bewertung des Projekts befassen, wird die interne Bewertung ein Kinderspiel sein. Betrachten wir den schwierigsten Fall.
Bewertung der Architektur von Unternehmensprojekten
Ein typisches zu evaluierendes Projekt ist ein großes, altes Unternehmensprojekt mit vielen Problemen. Ein Kunde kommt zu uns und bittet uns, sein Projekt zu reparieren. Es ist wie bei einem Eisberg: Der Kunde sieht nur die Spitze seiner Probleme und hat keine Ahnung, was sich unter Wasser (in den Tiefen des Codes) befindet.
Probleme, über die sich der Kunde möglicherweise beschwert und die ihm möglicherweise bekannt sind:
- Performance-Probleme
- Probleme mit der Benutzerfreundlichkeit
- Langfristiger Einsatz
- Fehlende Unit- und andere Tests
Probleme, die dem Kunden höchstwahrscheinlich nicht bekannt sind, aber möglicherweise im Projekt vorhanden sind:
- Sicherheitsprobleme
- Designprobleme
- Falsche Architektur
- Algorithmusfehler
- Ungeeignete Technologien
- Technische Schulden
- Falscher Entwicklungsprozess
Formaler Architekturüberprüfungsprozess
Dabei handelt es sich um einen formellen Prozess, den wir als Unternehmen befolgen. Sie können ihn jedoch je nach Unternehmen und Projekt anpassen.
Anfrage eines Kunden
Der Kunde bittet darum, die Architektur des aktuellen Projekts zu bewerten. Der Verantwortliche auf unserer Seite sammelt grundlegende Informationen über das Projekt und wählt die notwendigen Experten aus. Je nach Projekt kann es sich hierbei um unterschiedliche Experten handeln.
Solution Architect – die Hauptperson, die für die Beurteilung und Koordinierung verantwortlich ist (und oft die einzige Person).
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, Systemadministrator usw.
Andere Experten – wie Big Data, maschinelles Lernen, Leistungsingenieur, Sicherheitsexperte, QA-Leiter.
Sammeln von Informationen über das Projekt
Sie sollten so viele Informationen wie möglich über das Projekt sammeln. Je nach Situation können Sie unterschiedliche Techniken anwenden:
- Fragebögen und andere Kommunikationsmethoden per Post. Der ineffektivste Weg.
- Online-Meetings.
- Spezielle Tools zum Informationsaustausch wie: Google Doc, Confluence, Repositories usw.
- „Live“-Meetings vor Ort. Der effektivste und teuerste Weg.
Was sollten Sie vom Kunden bekommen?
Grundinformation. Worum geht es in dem Projekt? Sein Zweck und Wert. Hauptziele und Pläne für die Zukunft. Geschäftsziele und -strategien. Hauptprobleme und gewünschte Ergebnisse.
Projekt Information. Technologie-Stack, Frameworks, Programmiersprachen. Bereitstellung vor Ort oder in der Cloud. Wenn sich das Projekt in der Cloud befindet, welche Dienste werden verwendet. Welche Architektur- und Designmuster wurden verwendet?
Nicht-funktionale Anforderungen. Alle Anforderungen beziehen sich auf Leistung, Verfügbarkeit und Benutzerfreundlichkeit des Systems. Sicherheitsanforderungen usw.
Grundlegende Anwendungsfälle und Datenflüsse.
Zugriff auf Quellcode. Der wichtigste Teil! Sie sollten auf jeden Fall Zugriff auf die Repositories und die Dokumentation zum Erstellen des Projekts erhalten.
Zugang zur Infrastruktur. Es wäre schön, Zugang zur Bühnen- oder Produktionsinfrastruktur zu haben, um mit dem Live-System arbeiten zu können. Es ist ein großer Erfolg, wenn der Kunde über Tools zur Überwachung der Infrastruktur und Leistung verfügt. Wir werden im nächsten Abschnitt über diese Tools sprechen.
Dokumentation. Wenn der Kunde über Dokumentation verfügt, ist dies ein guter Anfang. Es mag veraltet sein, aber es ist immer noch ein guter Anfang. Vertrauen Sie niemals der Dokumentation – testen Sie sie mit dem Client, auf realer Infrastruktur und im Quellcode.
Architekturbewertungsprozess
Wie kann man so viele Informationen in so kurzer Zeit verarbeiten? Parallelisieren Sie zunächst die Arbeit.
DevOps sollte sich die Infrastruktur ansehen. Technischer Einstieg in den Code. Leistungsingenieur zum Anzeigen von Leistungsmetriken. Ein Datenbankspezialist sollte tiefer in Datenstrukturen eintauchen.
Dies ist jedoch ein Idealfall, wenn Sie über viele Ressourcen verfügen. Typischerweise bewerten ein bis drei Personen ein Projekt. Sie können den Kostenvoranschlag sogar selbst durchführen, was häufig der Fall ist, wenn Sie über die entsprechenden 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 Menge an Erfahrung können Sie die Qualität der Dokumentation schnell erkennen. Was ist wahr und was stimmt eindeutig nicht mit der Realität überein? Manchmal sieht man in der Dokumentation Architektur, die im wirklichen Leben nie funktionieren wird. Dies ist ein Anstoß für Sie, darüber nachzudenken, wie es in der Realität im Projekt umgesetzt wurde.
Nützliche Tools zur Automatisierung der Projektbewertung
Die Codeauswertung ist eine einfache Übung. Sie können statische Code-Analysatoren verwenden, die Ihnen Design-, Leistungs- und Sicherheitsprobleme aufzeigen. Hier sind einige davon:
ist ein großartiges Werkzeug für einen Architekten. Es zeigt Ihnen das Gesamtbild, Abhängigkeiten zwischen Modulen und potenzielle Bereiche für eine Umgestaltung. Wie alle guten Tools kostet es gutes Geld, Sie können jedoch eine 30-Tage-Testversion nutzen.
- ein gutes altes Werkzeug. Ein Tool zur statischen Codeanalyse. Ermöglicht die Identifizierung von fehlerhaftem Code, Fehlern und Sicherheitsproblemen für mehr als 20 Programmiersprachen.
Alle Cloud-Anbieter verfügen über Tools zur Infrastrukturüberwachung. Dadurch können Sie die Effektivität Ihrer Infrastruktur im Hinblick auf Kosten und Leistung richtig bewerten. Für AWS ist dies der Fall . Für Azure ist das einfach .
Zusätzliche Leistungsüberwachung und -protokollierung helfen dabei, Leistungsprobleme auf allen Ebenen zu finden. Angefangen bei einer Datenbank mit ineffektiven Abfragen, dem Backend und endend mit dem Frontend. Auch wenn der Kunde diese Tools noch nicht installiert hat, können Sie sie relativ schnell in das bestehende System integrieren, um Leistungsprobleme zu erkennen.
Wie immer lohnt sich gutes Werkzeug. Ich kann ein paar kostenpflichtige Tools empfehlen. Natürlich können Sie Open Source verwenden, aber das wird mehr Zeit in Anspruch nehmen. Und dies sollte im Vorfeld erfolgen, nicht während des Architekturbewertungsprozesses.
– ein Tool zur Bewertung der Anwendungsleistung
– Cloud-Systemüberwachungsdienst
Für Sicherheitstests stehen zahlreiche Tools zur Verfügung. Dieses Mal empfehle ich Ihnen ein kostenloses System-Scan-Tool.
– ein Tool zum Scannen von Webanwendungen auf Einhaltung von Sicherheitsstandards.
Lassen Sie uns alles zu einem Ganzen zusammenfügen.
Erstellen eines Berichts
Beginnen Sie Ihren Bericht mit den Daten, die Sie vom Kunden gesammelt haben. Beschreiben Sie die Projektziele, Einschränkungen und nichtfunktionalen Anforderungen. Danach sollten alle Eingabedaten erwähnt werden: Quellcode, Dokumentation, Infrastruktur.
Nächster 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. Es sollten kurze und prägnante Hinweise auf die festgestellten Probleme gegeben werden.
Priorisieren Sie die gefundenen Probleme auf der Fehler-, Warnungs- und Informationsskala. Sie können Ihren eigenen Maßstab wählen, dies ist jedoch der allgemein akzeptierte.
Als echter Architekt liegt es in Ihrer Verantwortung, Empfehlungen zur Behebung der festgestellten Probleme zu geben. Beschreiben Sie die Verbesserungen und den Geschäftswert, den der Kunde erhält. So zeigen Sie den Geschäftswert auf wir haben es vorhin besprochen.
Bereiten Sie eine Roadmap mit kleinen Iterationen vor. Jede Iteration sollte die Zeit bis zur Fertigstellung, eine Beschreibung, die Menge der für die Verbesserung benötigten Ressourcen, den technischen Wert und den geschäftlichen Wert enthalten.
Wir führen die Architekturbewertung durch und stellen dem Kunden einen Bericht zur Verfügung
Versenden Sie niemals einfach einen Bericht. Es kann sein, dass es überhaupt nicht gelesen wird oder dass es ohne entsprechende Erklärung nicht gelesen und verstanden werden kann. Kurz gesagt, Live-Kommunikation hilft, Missverständnisse zwischen Menschen zu beseitigen. Sie sollten ein Treffen mit dem Kunden vereinbaren und über die festgestellten Probleme sprechen und sich dabei auf die wichtigsten konzentrieren. Es lohnt sich, den Klienten auf Probleme aufmerksam zu machen, die ihm vielleicht gar nicht bewusst sind. Besprechen Sie beispielsweise Sicherheitsprobleme und erläutern Sie, wie diese sich auf das Unternehmen auswirken könnten. Zeigen Sie Ihre Roadmap mit Verbesserungen und besprechen Sie verschiedene Optionen, die für den Kunden besser geeignet sind. Dies können Zeit, Ressourcen oder Arbeitsaufwand sein.
Als Zusammenfassung Ihres Meetings senden Sie Ihren Bericht an den Kunden.
Abschließend
Architekturbewertung ist ein komplexer Prozess. Um die Beurteilung ordnungsgemäß durchführen zu können, müssen Sie über ausreichende Erfahrung und Kenntnisse verfügen.
Es ist möglich, dem Kunden in nur einer Woche nützliche Ergebnisse für ihn und sein Unternehmen zu liefern. Auch wenn du es alleine schaffst.
Meiner Erfahrung nach wurden viele Verbesserungen mittendrin heruntergeladen und manchmal nie gestartet. Wer für sich die goldene Mitte wählte und nur einen Teil der für das Unternehmen nützlichsten Verbesserungen bei minimalem Arbeitsaufwand vornahm, verbesserte die Qualität seines Produkts deutlich. Wer nichts tat, konnte das Projekt nach ein paar Jahren ganz beenden.
Ihr Ziel ist es, dem Kunden maximale Verbesserungen zum minimalen Preis zu zeigen.
Weitere Artikel aus der Rubrik Sie können in aller Ruhe lesen.
Ich wünsche Ihnen sauberen Code und gute Architekturentscheidungen.
Unsere Facebook-Gruppe - .
Source: habr.com