Anwendungen mit schwerer Vererbung. Unterstützung oder Restaurierung?

Hallo Habr! Auf dem Luxoft TechFest am 28. Januar sprach Mikhail Zankovich, Senior Team Lead bei Luxoft , über Anwendungen mit schwerer Vererbung. Heute teilt er zusätzliche Gedanken mit, die in den Inhalt dieses Berichts verwickelt sind und während des Treffens eine ziemlich hitzige Diskussion ausgelöst haben.



Welche Emotionen und Assoziationen ruft der Satz "Wir haben ein Legacy-Projekt" in Ihnen hervor? Meistens - mangelnde Struktur, Chaos, jede Menge Code ohne Papiere, Horror, architektonische Anarchie, Ekel, ein Meer von Krücken, muss man rennen! Meine Gefühle: „Oh! Endlich etwas Interessantes. Lass es funktionieren! " Ich vermute, dass dies eine sehr ungewöhnliche Reaktion ist.

In diesem Artikel werde ich versuchen, eine andere Ideologie der Arbeit mit dem Erbe aufzudecken. Lassen Sie es uns als "Software-Wiederherstellung" bezeichnen. Ich habe nicht vor, Ihre Einstellung zu Legacy zu ändern, aber wenn Sie es schaffen, zumindest einen Anflug von Zweifel daran zu säen, dass Legacy interessant sein könnte, werde ich mich freuen.

Typisches Erbe

Was ist Vermächtnis? Nach meiner Erfahrung können Sie die folgende Checkliste für die Einhaltung älterer Produkte erstellen:

• .
  
  .. , , .

• .
  
  , black-box. . .
• .
  
  , .
• .
  
  . / ..

All dies führt dazu, dass es mit jeder Version immer schwieriger wird, ein solches Projekt zu pflegen, genau wie das Ausarbeiten neuer Funktionen / neuer Anforderungen. Jede Änderung wird zu einem Reverse Engineering mit obligatorischen Regressionstests usw. Infolgedessen wird die Wartung des Projekts teuer und in seiner aktuellen Form „eingefroren“, wobei Änderungen minimiert werden.



Aber warum erscheinen ältere Produkte?



Selten schafft ein Team bewusst und zielgerichtet ein Produkt von geringer Qualität. Meistens ist dies das Ergebnis von Möglichkeiten, die durch die aktuelle Situation im Projekt begrenzt sind.



Es gibt keine klaren Anforderungen - es gibt keine Möglichkeit eines ausgewogenen Designs der Anwendungsfunktionalität.



Ständig wechselnde Anforderungen, unklare Formulierungen, enge Implementierungsfristen und eine ständig wachsende technische Verschuldung sind deutliche Anzeichen für agile Entwicklungsprozesse in einem Team, das sich nicht vollständig an diese „agilen“ Ansätze anpassen konnte. Und von "flexibel" funktionieren nur "sich schnell ändernde Anfragen aus dem Geschäft".



Dies führt häufig zu einer erhöhten Rotation innerhalb des Teams, was sich wiederum nicht positiv auf die Qualität auswirkt. Stellen Sie sich vor, ein neuer Spezialist tritt dem Team bei, zwei oder drei Monate lang vertieft er sich nur in den Prozess, dann implementiert er anderthalb oder zwei Monate lang eine Art von Funktionalität und bereitet sich darauf vor, das Projekt zu verlassen. Er interessiert sich nicht für ein Qualitätsprodukt, eine vollständige Dokumentation seines Teils, den Wissenstransfer an Kollegen usw. Fachwissen ist verschwommen.



Irgendwann wird eine fatale Entscheidung getroffen: Es ist einfacher zu ersetzen / auszuschalten als zu begleiten. Und das Projekt tritt in die Phase „geringer Wartungsaufwand“ ein, wenn es auf der Basis von Resten unterstützt wird, um Änderungen zu minimieren und zusätzliche „Krücken“ zu erstellen, die neue Anforderungen schnell, aber schlecht implementieren. Warum hohe Qualität? Das Produkt wird sich ändern. In diesem Modus kann das Produkt viele Jahre überleben, mit "Krücken" überwachsen und monströser werden.



Zusammenfassend lassen sich die folgenden Hauptgründe für die Entstehung von Legacy-Produkten identifizieren:

• enge Fristen für die Implementierung der Funktionalität;
• Fehlen klarer Anforderungen / sich stark ändernde Anforderungen;
• erhöhte Rotation innerhalb des Teams;
• unsachgemäße Planung des Lebenszyklus.

Wir fügen hier den Grad der beruflichen Entwicklung von Spezialisten in diesem Moment hinzu. Öffnen Sie Ihr Projekt vor fünf oder zehn Jahren. Ich bin sicher, Sie können leicht Elemente finden, die Sie jetzt anders implementieren würden.



Wir nehmen also als Axiom: "Der Code wird nicht von Natur aus schlecht erstellt". Dies bedeutet, dass jedes Produkt eine Idee hatte. Und wenn der Code in Produktion ging, funktionierte er und befriedigte die damaligen Anforderungen des Unternehmens.

Escort Ansatz

Die Aufgaben der Kunden sind recht einfach: das Erbe funktionsfähig zu halten, ohne die aktuellen Geschäftsprozesse zu stören (von denen einige im Allgemeinen niemandem bekannt sind), während die Funktionalität gemäß den neuen Anforderungen entsprechend dem Budget entwickelt wird ist höchstwahrscheinlich begrenzt.



Der typische Ansatz eines Teams, das ein Projekt startet, besteht darin, die Situation langsam, aber sicher weiter zu verschlimmern. Berühren Sie nicht zu viel, ändern Sie nur das, was gefragt wird, und nur, wenn Sie gefragt werden. Wenn das Modul funktioniert, aber eine Änderung der Logik erfordert - lassen Sie es und berühren Sie es nicht - ist es besser, ein anderes zu erstellen, aber mit der erforderlichen Logik. Das Chaos wächst, die App wird komplizierter.

Der Ansatz des Restaurators

Der Ansatz eines Software-Restaurators besteht darin, herauszufinden, welche Art von Mechanismus sich davor befindet. Was war die Hauptidee hinter seinen Schöpfern. Versuchen Sie, alles Unnötige abzuschneiden und das Beste zu behalten. Wenn Sie die vorhandene Struktur ändern, ist sie äußerst vorsichtig und achtet auf die Details. Kein einziges Detail, das sich auf das System auswirkt, sollte aus der Sicht des Restaurators ausgeblendet werden. Die eingeführten Änderungen werden zuerst gemäß der Wartungslogik ausgearbeitet, und dann wird eine Analyse durchgeführt, um die Möglichkeit der Implementierung einer vollwertigen Lösung zu bestimmen.



Dies ist eine schwierige und zeitaufwändige Aufgabe. Nicht jeder Entwickler ist bereit und vor allem wirklich in der Lage, Wiederherstellungen durchzuführen. Die Anforderungen an das Niveau des Restaurators sind um eine Größenordnung höher als für einen normalen Entwickler. Ohne Erfahrung in realen Projekten, ohne zu verstehen, wie sich Systeme entwickeln können, ohne Kollision nicht nur mit den besten Ansätzen in der Praxis, sondern auch mit eindeutig erfolglosen Implementierungen, macht eine Wiederherstellung keinen Sinn.

Anstelle des typischen ersten Drangs „Ja, das sind Krücken! Hier muss alles neu geschrieben werden! " - Ein echter Restaurator wird die Frage stellen: „Warum wurde das so gemacht? Wie genau war geplant, es zu benutzen? " Und erst nachdem sichergestellt wurde, dass es keine offensichtlichen Voraussetzungen für die Erstellung eines solchen Codes gab, kann der Restaurator ausrufen: „Ja, das sind Krücken! Hier muss alles neu geschrieben werden! “Und mit einem Gefühl der Leistung kann er unnötiges Wachstum auf dem verknöcherten Framework der Software wirklich abbrechen und das Objekt der Wiederherstellung besser und von höherer Qualität machen.



Dies kommt jedoch selten vor, obwohl es dem Restaurator unbeschreibliche Freude bereitet. Meistens müssen Sie das Gewirr von Abhängigkeiten zwischen verschiedenen Modulen entwirren. Es ist nicht ungewöhnlich, dass sich die Gewinde weit über den Verantwortungsbereich der zu zerlegenden Komponente (und manchmal des Systems) hinaus erstrecken. Und all diese Feinheiten der Modulbeziehungen müssen bei der Wiederherstellung berücksichtigt werden.







Somit arbeitet der Software-Restaurator an der Schnittstelle von Entwicklung, Architektur, Geschäftsanalyse, Test und Medizin. Und es ist schwer zu sagen, welche Fähigkeiten aus den ausgewiesenen Bereichen die höchste Priorität haben. Es muss ein gewisses Gleichgewicht zwischen ihnen bestehen, gewürzt mit dem ehrlichen Wunsch, sich auf die Wiederherstellung einzulassen. Was hat Medizin damit zu tun? Das Hauptprinzip des Restaurators ist also „primum non nocere“ - erstens keinen Schaden anrichten.



Tatsächlich wird dieser Ansatz anhand spezifischer Beispiele weiter betrachtet, wobei das typische Erbe, das von den früheren technischen Eigentümern von Systemen geerbt wurde, schrittweise zerlegt und wiederhergestellt wird. Lassen Sie uns anhand konkreter Beispiele sehen, warum alle oben genannten Fähigkeiten wichtig sind.

Wiederherstellung des Data Warehouse

Was speichert das System?



Bei der Landung in einem neuen Projekt achtet der Restaurator auf die vom System verarbeiteten Objekte. Es dauert mindestens einige Monate, bis Sie vollständig in Geschäftsabläufe und Quellcode eingetaucht sind, insbesondere wenn keine normale Dokumentation vorhanden ist.



Eine der ersten Aufgaben eines Restaurators besteht darin, die Wirksamkeit des Tresors zu beurteilen. Können Sie etwas verbessern, ohne sich auf ein Verständnis der Geschäftsprozesse verlassen zu müssen? Ein typischer Schmerzpunkt eines Data Warehouse hängt hauptsächlich mit dem Volumen dieser Daten zusammen. Je größer das Volumen ist, desto höher sind die Betriebskosten des Systems.



Der zweite Schmerzpunkt ist das Wachstum dieses Volumens, was sich in erster Linie negativ auf die Leistung des Systems auswirkt. Höchstwahrscheinlich gibt es bereits einige Methoden, um Informationen im System zu speichern, aber wie effektiv sind sie?



Alle hier betrachteten Praktiken sind eher auf klassisches RDBMS anwendbar, aber der Ansatz ist für No-SQL-Lösungen nicht sehr unterschiedlich.



Eine der Haupttaktiken des Restaurators in dieser Richtung ist die Erstellung einer Überwachung von Informationsspeicherobjekten. Bei klassischem DBMS Tabellenüberwachung.



Es wird ein Framework benötigt, mit dem die Systemmetadaten regelmäßig Daten zu zwei trivialen Parametern erfassen können - der Datenmenge und der Anzahl der Elemente in jeder Tabelle. Die Frequenz muss manuell ausgewählt werden (mehr dazu weiter unten), basierend auf den Eigenschaften des Systems. Eine typische Anlaufzeit von 24 Stunden reicht für die Basisanalyse aus.



Daten analysieren



Was tun mit den Daten? Wonach schauen? Der erste Moment besteht darin, die "schwersten Objekte" zu identifizieren. In der Praxis funktioniert die Standardregel 20/80 - nicht mehr als 20 Prozent der Objekte belegen mehr als 80 Prozent des Speicherplatzes. Auf diese Weise können Sie den Analysebereich in der ersten Phase erheblich einschränken.



Je länger und detaillierter solche Statistiken gesammelt werden, desto deutlicher spiegelt sich das Verhalten des Systems wider. Die Erfahrung hat gezeigt, dass der empfohlene Zeitraum mindestens zwei Wochen beträgt. Die Hauptidee besteht darin, arbeitsfreie Tage / Zeiträume zu "verknüpfen", innerhalb derer Mechanismen zum Bereinigen und Archivieren von Informationen am häufigsten implementiert werden.



Das Framework ist also geschrieben und der Restaurator wartet zwei Wochen auf die Ergebnisse? Natürlich nicht. Es kämpft nicht gegen die Ideologie des Restaurators. Mit dem ersten Datenblock in der Hand können Sie einige grundlegende Analysen durchführen. Nämlich - um das Verhältnis des belegten Raums zur Anzahl der gespeicherten Objekte (Zeilen) zu sehen. Je größer dieser Wert ist, desto wahrscheinlicher ist es, dass hier BLOB-Felder gespeichert werden. Und genau diese Tabellen und Felder werden für den Restaurator zum Gegenstand von Forschung und Analyse.



Schlüsselfragen: Wie oft greifen Geschäftsprozesse tatsächlich auf diese Objekte zu? Der Eigentümer des Systems, das vorhandene Team, kann solche Punkte beleuchten. Und plötzlich (und in der Praxis sehr oft) stellt sich heraus, dass solche Felder Informationen speichern, die für das Unternehmen nicht wichtig sind: Speicherauszüge von Objekten / Nachrichten zur Analyse durch das Entwicklungsteam, Benutzerkommentare, die nur beim Erstellen eines Auftrags angezeigt werden usw.



Der nächste Schritt: Wenn die Daten nicht häufig verwendet werden oder keinen eindeutigen Geschäftswert haben, können Sie sie in das Archiv verschieben. Gleichzeitig ein grundlegender Ansatz, bei dem ein monolithischer Tisch in Teile geteilt wird, Blobs auf ein billigeres / langsameres Medium verschoben werden, während gleichzeitig die ursprüngliche Schnittstelle des Tisches erhalten bleibt (der Hauptpunkt ist, dass es keine verlässlichen Informationen über alle gibt Prozesse, die auf diese Informationen zugreifen, was bedeutet, dass Änderungen ihnen nicht schaden sollten) - können ein interessantes und komplexes technisches Problem sein.



Eine weniger interessante, aber ebenso nützliche Aufgabe besteht darin, das integrierte Datenspeichersystem zu verwenden, um die Werte bestimmter Felder zu archivieren. Beispielsweise verfügt Sybase ASE über die Funktion ASE_Compression. Mit Mongo DB können Sie Komprimierungsoptionen für Sammlungen usw. festlegen. Nahezu jedes Datenspeichersystem bietet die Möglichkeit einer zusätzlichen Datenkomprimierung „unter der Haube“. Die Funktionalität funktioniert für externe Systeme transparent und erfordert keine drastischen Änderungen. In der Praxis (insbesondere auf Legacy-Systemen) werden solche Datenkomprimierungsoptionen standardmäßig nicht verwendet.



Natürlich muss der Restaurator bei der Anwendung der Komprimierung zunächst die Auswirkungen des Ansatzes auf die Leistung bewerten. Dazu müssen wichtige Leistungsindikatoren des Systems erarbeitet werden, oder im Extremfall müssen Elemente von Regressionstests vorhanden sein.



Im Allgemeinen gibt es einige Wochen lang etwas zu tun, während vollständige Statistiken zu Objekten gesammelt werden.



Große Statistiken: worauf zu achten ist



Nachdem der Restaurator über einen langen Zeitraum Statistiken erhalten hat, versucht er herauszufinden, was mit der Dynamik des genutzten Raums passiert. Alle Werte für eine Tabelle / ein Objekt werden auf den ursprünglichen Wert normiert. Dies ermöglicht es, die relative Zunahme der Daten genau abzuschätzen und die sich am intensivsten ändernden Objekte zu identifizieren.



Das generierte Profil entspricht höchstwahrscheinlich einem der folgenden Typen:







Profil 1 - konstanter Wert. Dies sind höchstwahrscheinlich statische Verzeichnisse, und es ist nicht so interessant, mit ihnen zu arbeiten. Der oben beschriebene Archivierungsansatz kann basierend auf der Nutzungsintensität des Verzeichnisses angewendet werden.



Kleine Volumenschwankungen - Profil 2- Sie können sowohl über ein Nachschlagewerk als auch über eine Operationstabelle sprechen, in der das Lesen / Schreiben von Daten intensiv ist. Dies sind aus Sicht des Restaurators die schwierigsten Objekte, weil Es ist notwendig, ihr Verhalten so detailliert wie möglich zu analysieren. Für diese Objekte ist es sinnvoll, die Häufigkeit der Informationserfassung zu erhöhen: nicht einmal am Tag, sondern einmal pro Stunde, einmal pro Minute. Das Hauptziel besteht darin, die Profiländerung detaillierter zu verfolgen und die Verhaltensabhängigkeiten zu verstehen.



Die Profile 3 und 4 sind von größerem Interesse. Profil 3(„Säge“) gibt eindeutig an, dass diese Tabelle regelmäßig gelöscht wird. Der wachsende Trend - jedes Mal nach der Reinigung ist das Endvolumen etwas größer als zuvor - spricht jedoch für die Ineffizienz der vorhandenen Reinigungsmechanismen. Jene. Über einen bestimmten Zeitraum werden mehr Daten im System angezeigt, als am Ende des Zeitraums gelöscht werden. Dies kann ein völlig normaler Geschäftsprozess sein, eine klassische Erhöhung der Systemlast.



Für den Restaurator ist dies jedoch vor allem ein Signal: Gibt es Bedingungen für das Löschen von Informationen? Aufgrund der Praxis bleiben höchstwahrscheinlich einige Entitäten aufgrund der komplexen Bedingungen der Datenaufbewahrung im System unverdient für immer im Speicher. Das Ziel des Restaurators ist es, solche Entitäten zu identifizieren und sie auch in regelmäßige Aktivitäten einzubeziehen.

Wenn Profil 3 zu konstantem Wachstum degeneriert, ist dies der erste Anwärter auf einen Engpass im System. Erstens gibt es keine expliziten Hinweise auf den Archivierungsprozess, und zweitens wird mit dem Datenwachstum ein Leistungsabfall erwartet.



Profil 4- Ein typisches Beispiel für eine Archivtabelle mit periodischer Datenfüllung. Bitte beachten Sie, dass das Tabellenwachstum nur an bestimmten Tagen auftritt. Es ist durchaus möglich, dass Korrelationen mit Tabellen des dritten Profils erkennbar sind. Für Archivtabellen ist es auch wichtig, das Prinzip ihrer Verwendung zu verstehen. Werden sie von Benutzern angerufen? Oder ist es eine Geschichte zu analysieren? Oder sind es Daten für Berichtssysteme? Abhängig von den Antworten auf diese Fragen ist es durchaus möglich, dass eine Entscheidung getroffen wird, die Archivtabellen in einen separaten Schaltkreis, eine separate Basis, einen separaten Abschnitt zu unterteilen. Dadurch wird der Betriebsraum frei.

Wie funktioniert es in der Praxis?

In einem der Projekte wurde eine ähnliche Übung in den ersten anderthalb Monaten nach dem Beitritt zum Projekt durchgeführt. Es waren die Objekte von Profil Nr. 3, die das Ziel waren, und sie wurden gefunden. Anwenden der beschriebenen Vorgehensweisen (Verbessern der Reinigungsbedingungen), Löschen von Daten, die nicht im System verwendet wurden usw. erlaubt, das Volumen des belegten Raums um mehr als 25% zu reduzieren und das intensive Wachstum des Speichers zu stoppen.



Infolgedessen konnten wir die ersten technischen Änderungen am Projekt vornehmen und Pläne zur Verbesserung der Funktionalität einreichen. Der Kunde war mit dem Ergebnis des Teams zufrieden und es wurde von 3 auf 9 Entwickler erweitert. Während des gesamten Jahres haben wir die Untersuchungen fortgesetzt. Die Punkte zur Verbesserung der Funktionalität wurden verwendet, um das System und seine Eigenschaften zu unterstützen.



Da uns zwei Analysten hinzugefügt wurden, begann das Team, sich auf seine eigene Entwicklung einzulassen - nicht auf Support, sondern auf die Implementierung neuer Geschäftsfunktionen. Wir entwickeln jetzt ein neues System.

Wofür ist das alles?

Wenn Sie so weit gelesen haben, suchen Sie höchstwahrscheinlich nach einer Antwort auf die Frage: "Warum ist das alles?" Zuallererst ist die Wiederherstellung ein separater Prozess, nicht wie Entwicklung, nicht wie Unterstützung, sondern wie Kombination.



Dies ist ein separater Antrieb für einen technischen Spezialisten - sich mit der Logik der Person zu befassen, die dieses Produkt erstellt hat, seine Bedeutung zu verstehen, das Produkt von unnötigen Dingen zu reinigen und es noch besser zu machen als es war. Die App sieht aus wie eine Quest mit vielen Rätseln und unbekannten Wendungen.

Nein, Sie erstellen nicht von Grund auf neu, Sie stellen ein vorhandenes Produkt wieder her, werden aber möglicherweise durch die Zeit zerstört. Unter anderem hat der Restaurator die einmalige Gelegenheit, in eine der sechs Richtungen zu pumpen (siehe Abbildung oben), während er ein echtes Produkt als Testbasis zur Hand hat. Ein Gefühl der Selbstkontrolle wird ebenfalls gefördert - nicht um in technischen Perfektionismus zu verfallen, sondern um nur die Änderungen zu überdenken und vorzunehmen, die für das System zur Verbesserung von Prozessen erforderlich sind.



All dies macht die Arbeit mit Legacy-Systemen aufregend und ungewöhnlich. Die endgültige Entscheidung für die Wiederherstellung oder Wartung liegt jedoch bei Ihnen.



Der Bericht von Mikhail Zankovich auf dem Luxoft TechFest kann hier eingesehen werden .



Der Autor des Artikels ist Mikhail ZankovichMikhailZankovich