Zu Beginn ist es oft schwierig, sich in einem großen und alten Projekt zurechtzufinden. Die Architekturprüfung ist eine der Aktivitäten eines Architekten. In der Regel muss man 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 Technischen Leiter sind bereits mit solchen Projektbewertungen konfrontiert worden. Das kann wie ein halbformeller Prozess aussehen oder als ein separater Service, wie es in unserem Unternehmen der Fall ist. So oder so, die meisten von Ihnen haben schon damit zu tun gehabt.
Das Original in englischer Sprache für Ihre nicht russischsprachigen Freunde finden Sie hier: .
Unser Ansatz in der Firma
Ich werde Ihnen erläutern, wie das in unserem Unternehmen funktioniert und wie ich in solchen Situationen vorgehe, aber Sie können diesen Ansatz leicht an die Bedürfnisse Ihres Projekts und Unternehmens anpassen.
Es gibt zwei Arten der Architekturprüfung.
Intern – wir führen sie normalerweise für Projekte innerhalb des Unternehmens durch. Jedes Projekt kann eine Architekturprüfung aus verschiedenen Gründen anfordern:
- Das Team ist überzeugt, dass ihr Projekt perfekt ist, was verdächtig wirkt. In der Vergangenheit hatten wir solche Fälle, und oft ist in solchen Projekten alles andere als perfekt.
- Das Team möchte sein Projekt und seine Lösungen überprüfen.
- Das Team ist sich bewusst, dass vieles schiefgeht. Sie können sogar die Hauptprobleme und Ursachen auflisten, wollen aber eine vollständige Liste der Probleme und Empfehlungen zur Verbesserung des Projekts erhalten.
Extern – das ist ein formellerer Prozess als eine interne Bewertung. Ein Kunde kommt immer nur dann, wenn alles schlecht – sehr schlecht – ist. Normalerweise erkennt der Kunde, dass es globale Probleme gibt, kann aber die Ursachen nicht richtig identifizieren und in Bestandteile zerlegen.
Die Bewertung der Architektur für einen externen Kunden ist ein komplexerer Fall. Der Prozess muss formeller gestaltet werden. Die Projekte sind immer groß und alt. Sie haben viele Probleme, Fehler und schlechten Code. Der Bericht über die Durchführung muss innerhalb weniger Wochen maximal erstellt werden, wobei die Hauptprobleme und Empfehlungen zur Verbesserung aufgeführt werden müssen. Wenn wir also mit der externen Bewertung des Projekts klarkommen, wird die interne Bewertung ein Kinderspiel sein. Betrachten wir den schwierigsten Fall.
Bewertung der Architektur eines Enterprise-Projekts
Ein typisches Projekt zur Bewertung ist ein großes, altes Enterprise-Projekt mit vielen Problemen. Der Kunde kommt zu uns und bittet darum, sein Projekt zu reparieren. Es ist wie mit einem Eisberg: Der Kunde sieht nur die Spitze seiner Probleme und ahnt nicht, was unter Wasser (im tiefen Code) verborgen ist.
Probleme, über die der Kunde klagen könnte und von denen er wissen könnte:
- Leistungsprobleme
- Usability-Probleme
- Lange Deployment-Zeiten
- Fehlende Unit- und andere Tests
Probleme, von denen der Kunde wahrscheinlich nichts ahnt, die jedoch im Projekt vorhanden sein könnten:
- Sicherheitsprobleme
- Entwurfsprobleme
- Falsche Architektur
- Algorithmische Fehler
- Ungeeignete Technologien
- Technische Schulden
- Falscher Entwicklungsprozess
Formeller Architektur-Bewertungsprozess
Dies ist ein formeller Prozess, den wir in der Firma befolgen, aber Sie können ihn je nach Ihrem Unternehmen und Projekt anpassen.
Anfrage des Kunden
Der Kunde bittet um eine Einschätzung der Architektur des aktuellen Projekts. Eine verantwortliche Person von unserer Seite sammelt grundlegende Informationen über das Projekt und wählt die erforderlichen Experten aus. Je nach 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 – das können Azure-, GCP- oder AWS-Cloud-Architekten sein.
Infrastruktur – DevOps, Systemadministrator usw.
Andere Experten – wie Big Data, Machine Learning, Performance Engineer, Security Expert, QA Lead.
Informationssammlung über das Projekt
Sie sollten so viele Informationen wie möglich über das Projekt sammeln. Je nach Situation können Sie verschiedene Techniken verwenden:
- Fragebögen und andere Kommunikationsmittel per E-Mail. Der ineffektivste Weg.
- Online-Meetings.
- Spezielle Informationsaustausch-Tools wie: Google Doc, Confluence, Repositories usw.
- »Live«-Treffen vor Ort. Der effektivste und teuerste Weg.
Was müssen Sie vom Kunden erhalten?
Grundlegende Informationen. Über das Projekt. Sein Ziel und Wert. Hauptziele und Pläne für die Zukunft. Geschäftliche Ziele und Strategien. Hauptprobleme und gewünschte Ergebnisse.
Projektdetails. Technologischer Stack, Frameworks, Programmiersprachen. On-Premise oder Cloud-Deployment. Falls das Projekt in der Cloud ist, welche Dienste verwendet werden. Welche Architekturmuster und Designmuster angewendet wurden.
Nicht-funktionale Anforderungen. Alle Anforderungen, die mit der Leistung, Verfügbarkeit und Benutzerfreundlichkeit des Systems zusammenhängen. Sicherheitsanforderungen usw.
Basis-Use-Cases und Datenflüsse.
Zugang zum Quellcode. Der wichtigste Teil! Sie sollten unbedingt Zugriff auf die Repositories und die Dokumentation erhalten, um das Projekt zusammenzustellen.
Zugang zur 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 Monitoring-Tools für 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 mag zwar veraltet sein, aber es ist trotzdem ein guter Start. Glauben Sie niemals der Dokumentation – überprüfen Sie sie mit dem Kunden, an der realen Infrastruktur und im Quellcode.
Architekturbeurteilungsprozess
Wie geht man mit einer so großen Menge an Informationen in so kurzer Zeit um? Zuerst sollten Sie die Arbeit parallelisieren.
Der DevOps-Spezialist sollte sich die Infrastruktur ansehen. Der Tech-Lead sollte in den Code schauen. Der Performance-Ingenieur sollte die Leistungsmetriken überprüfen. Der Datenbankspezialist sollte die Datenstrukturen eingehender untersuchen.
Aber das ist der ideale Fall, wenn Sie viele Ressourcen zur Verfügung haben. In der Regel führen ein bis drei Personen die Projektbewertung durch. Sie können sogar selbst eine Bewertung durchführen, was oft passiert, 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 ausreichender Erfahrung können Sie die Qualität der Dokumentation ziemlich schnell einschätzen. Was wahr ist und was offensichtlich nicht mit der Realität übereinstimmt. Manchmal begegnen Sie in der Dokumentation einer Architektur, die in der realen Welt nie funktionieren wird. Das sollte Sie zum Nachdenken anregen, wie es in Projekten tatsächlich umgesetzt wird.
Nützliche Werkzeuge zur Automatisierung der Projektbewertung
Codebewertung ist eine einfache Übung. Sie können statische Codeanalysatoren einsetzen, die Probleme in Design, Leistung und Sicherheit aufzeigen. Hier sind einige von ihnen:
ist ein ausgezeichnetes Werkzeug für Architekten. Es gibt Ihnen einen Überblick, zeigt die Abhängigkeiten zwischen Modulen und potenzielle Bereiche für Refactoring. Wie alle guten Werkzeuge hat es seinen Preis, allerdings können Sie eine 30-tägige Testversion nutzen.
ist ein bewährtes Werkzeug. Ein statisches Codeanalyse-Tool. Es ermöglicht die Identifizierung von schlechtem Code, Bugs und Sicherheitsproblemen in mehr als 20 Programmiersprachen.
Alle Cloud-Anbieter verfügen über Tools zur Überwachung der Infrastruktur. Damit können Sie die Effizienz der Infrastruktur hinsichtlich Kosten und Leistung korrekt bewerten. Für AWS ist das . Für Azure ist es einfach .
Zusätzliche Leistungsüberwachung und Protokollierung helfen, Leistungsprobleme auf allen Ebenen zu identifizieren. Vom Datenbankmanagement mit ineffizienten Abfragen über das Backend bis hin zur Benutzeroberfläche. Selbst wenn der Kunde diese Tools nicht zuvor installiert hat, können Sie sie recht schnell in das bestehende System integrieren, um Leistungsschwächen zu identifizieren.
Wie immer kosten gute Tools ihr Geld. Ich kann ein paar kostenpflichtige Tools empfehlen. Natürlich können Sie auch Open Source nutzen, aber das wird mehr Zeit in Anspruch nehmen. Und das sollte im Voraus geschehen, nicht während der Evaluierung der Architektur.
– Performance-Assessment-Tool für Anwendungen
– Cloud-Service zur Überwachung von Systemen
Es gibt viele Werkzeuge zur Sicherheitsüberprüfung. Diesmal empfehle ich Ihnen ein kostenloses Werkzeug zum Scannen des Systems.
– ein Werkzeug zum Scannen von Webanwendungen auf die Einhaltung von Sicherheitsstandards.
Lassen Sie uns alles zusammenfassen.
Erstellen Sie den Bericht
Beginnen Sie Ihren Bericht mit den gesammelten Kundendaten. Beschreiben Sie die Projektziele, Einschränkungen und nicht-funktionale Anforderungen. Danach sollten alle Eingabedaten wie Quellcode, Dokumentation und Infrastruktur erwähnt werden.
Der nächste Schritt. Geben Sie alle Probleme an, die Sie manuell oder mit automatisierten Werkzeugen gefunden haben. Große automatisch generierte Berichte sollten ans Ende in den Anhang gelegt werden. Hier sollten kurze und prägnante Beweise für die gefundenen Probleme stehen.
Priorisieren Sie die gefundenen Probleme nach einer Skala von Fehler, Warnung, Info. Sie können Ihre eigene Skala wählen, aber dies ist die allgemein akzeptierte.
Als wahrer Architekt sind Sie verpflichtet, Empfehlungen zur Behebung der gefundenen Probleme abzugeben. Beschreiben Sie Verbesserungen und den geschäftlichen Nutzen, den der Kunde erhält. Wie man den geschäftlichen Wert von zeigt, haben wir zuvor diskutiert.
Erstellen Sie einen Roadmap mit kleinen Iterationen. Jede Iteration sollte Zeitaufwand, Beschreibung, benötigte Ressourcen zur Verbesserung, technischen Wert und geschäftlichen Wert enthalten.
Wir beenden die Bewertung der Architektur und stellen dem Kunden einen Bericht zur Verfügung.
Versenden Sie den Bericht niemals einfach per E-Mail. Er könnte entweder gar nicht gelesen oder gelesen, aber nicht verstanden werden, ohne ausreichende Erklärung. Kurz gesagt – persönliche Kommunikation hilft, Missverständnisse zwischen den Menschen auszuräumen. Sie sollten ein Meeting mit dem Kunden ansetzen und über die gefundenen Probleme sprechen, wobei Sie den Fokus auf die bedeutendsten legen. Achten Sie darauf, den Kunden auf Probleme hinzuweisen, von denen er möglicherweise nicht einmal wusste. Dazu gehören Sicherheitsprobleme, und erklären Sie, wie sie das Geschäft beeinträchtigen können. Zeigen Sie Ihren Roadmap mit Verbesserungen und diskutieren Sie verschiedene Optionen, die besser zum Kunden passen. Dazu können Zeit, Ressourcen, Umfang der Arbeiten gehören.
Fassen Sie am Ende Ihres Meetings Ihren Bericht für den Kunden zusammen.
Zusammenfassung
Die Bewertung der Architektur ist ein komplexer Prozess. Um die Bewertung korrekt durchzuführen, benötigen Sie ausreichend Erfahrung und Wissen.
Es ist tatsächlich möglich, dem Kunden innerhalb einer Woche nützliche Ergebnisse für ihn und sein Geschäft zu liefern – selbst wenn man dies alleine tut.
Meiner Erfahrung nach wurden viele Verbesserungen in der Mitte gestoppt oder begannen nie richtig. Diejenigen, die sich für den goldenen Mittelweg entschieden und nur die Verbesserungen umsetzten, die für das Geschäft am vorteilhaftesten waren und zugleich minimalen Aufwand erforderten, konnten die Qualität ihres Produkts erheblich steigern. Die, die nichts unternahmen, könnten nach ein paar Jahren das Projekt komplett einstellen.
Ihr Ziel ist es, dem Kunden maximale Verbesserungen zu einem minimalen Preis zu zeigen.
Weitere Artikel aus diesem Abschnitt kann man in der Freizeit lesen.
Ich wünsche Ihnen sauberen Code und gute Architekturentscheidungen.
Unsere Facebook-Gruppe – .
Quelle: habr.com
