👩🏼‍🤝‍👩🏻 👷🏼 👶 Das Biest zähmen: Legacy-Code, Tests und Sie 🤯 👩🏾‍🤝‍👩🏼 👎🏿

Legacy-Code ist ein „alter“ Code, dessen Alter sowohl 2 Monate als auch 10 Jahre betragen kann. Oft haben Entwickler darüber geschrieben, woran sich das Unternehmen vage erinnert. Vielleicht existierten sie überhaupt nicht und der Legacy-Code wurde während des Urknalls mit dem Universum geboren. Seitdem haben sich die Anforderungen dafür vielfach geändert, der Code wurde im Modus „Es war gestern notwendig“ korrigiert, und niemand hat die Dokumentation wie die Tests geschrieben. Der Legacy-Code ist verwirrend und fragil und zeigt weder den Anfang noch das Ende an. Wie soll man sich ihm nähern?

Nachfolgend Aufnahmen aus der Serie "Rick and Morty". Autoren Justin Royland und Dan Harmon.

Sie müssen mit Tests zu ihm kommen, aber sich auf Schmerzen vorbereiten. Probleme treten bereits ab dem Moment auf, an dem Sie sich für ein solches Projekt entscheiden. Sie müssen verstehen, warum Sie dies tun möchten, das Management davon überzeugen, das Testen des Legacy-Codes zu genehmigen, und Ihren Kollegen helfen. Danach stellen sich Fragen, wo die Studie beginnen soll, welche Tests zuerst ausgeführt werden sollen und wie nicht alles gebrochen werden kann. Aber die Hauptsache ist, wie man nicht verzweifelt, wenn man merkt, dass es kein Ende der Arbeit gibt.

Kirill Borisov 12 Jahre in der Branche, im Laufe der Jahre hat er einen langen Weg in Krücken, gebrochenem Code und verrottenden Rahmen alter Systeme zurückgelegt: von monolithischen Buchhaltungssystemen bis hin zu Autorisierungs-Microservices. Die Reise verlieh ihm Erfahrungen und Geschichten, die er in Form wertvoller Ratschläge teilen wird.

Ich habe einen Traum - eines Tages an einem neuen Projekt zu arbeiten. Alles wird von Anfang an gut und so frisch wie der erste Schnee: Tests, Architektur und Bedeutung. Dies ist jedoch nur ein Traum, denn seit 10 Jahren verkaufe ich mein Talent für Geld und wechsle von einem Legacy-Projekt zu einem anderen.

Während dieser Zeit habe ich keine Nerven mehr, aber ich kann Ihre retten, indem ich meine Erfahrungen mit der Interaktion mit dem Erbe teile. Ich werde Ihnen sagen, wie Sie das Biest zähmen können (Legacy-Code): Arbeiten Sie mit Code und Menschen, implementieren Sie Tests, ob dies durchgeführt werden muss und wie Entwickler damit umgehen.

Was wird hier nicht sein:

Tipps zum Schreiben von Tests. Viele Bücher, Artikel und verschiedene Videos behandeln diese Frage.
Diskussionsmethoden. BDD, TDD, ATDD - alles nach Ihrem Ermessen.
All dies kann gegen die NDA verstoßen. Menschen haben ein langes Gedächtnis und Anwälte haben lange Arme.

Was ist Legacy-Code?

Es gibt viele Definitionen. Ich glaube, dass dies ein " ziemlich alter " Code von 2 Monaten bis 10 Jahren ist. Der Legacy-Code ist verwirrend und zerbrechlich, aber wie eine riesige Schlange verschlingt sie ihren Schwanz.

Dies ermöglicht es Ihnen nicht, es ruhig zu testen. Alle Entwickler, vom Anfänger bis zum erfahrenen, wenn sie zu einem Legacy-Projekt kommen, schnappen sich eine Reihe von Tests und beeilen sich, dieses Monster zu töten. Der Speer bricht und damit Menschen. Infolgedessen bleibt ein Entwickler ohne Lebenszeichen übrig, der seit Jahrzehnten an einem Legacy-Projekt arbeitet.

Ist es möglich, dieses Biest zu überwinden? Ja, aber Vorbereitung ist erforderlich.

Ausbildung

Der Kampf gegen das Biest ist nicht so wichtig wie die Vorbereitungsphase. Es beginnt mit drei Fragen an sich.

"Warum mache ich das?" Ernsthaft, warum? Immerhin gibt es nur zwei Möglichkeiten.

, , , .
, .

Möchten Sie für den Komfort anderer oder für Ihren eigenen Ruhm arbeiten? Wenn für letztere, dann mit dem ersten Erfolg das Interesse nachlässt, werden Sie nachlassen, alles wird nachlassen. Sie werden zu etwas anderem wechseln, und die verrottenden Überreste Ihrer Bemühungen werden das Projekt für eine lange Zeit verstopfen.

"Weiß ich was ich tue?" Wenn Sie Tests geschrieben haben, wissen Sie. Wenn nicht, beherrschen Sie die Grundlagen, bevor Sie sich auf das Monster stürzen: Schreiben Sie 3-4 Tests, decken Sie einen kleinen Teil des Codes ab, füllen Sie Ihre Hand und spüren Sie die Kraft.

"Habe ich Zeit dafür?" Es ist großartig, mit guten Impulsen in den Code einzugreifen und ihn zu verbessern, um für die Zukunft zu arbeiten. Aber vielleicht gibt es dafür keine Zeit, wenn die Gegenwart brennt. Wenn ja, dann braucht das Projekt Sie, kein helles Bild der Zukunft.

Wenn Sie alle Fragen bejahen, fahren Sie mit dem nächsten Schritt fort.

Aufklärung

Untersuchen Sie die Struktur des Projekts . Haben Sie eine Vorstellung von der Struktur des Projekts, den Komponenten und dem Arbeitsprinzip? Sicher ja, aber vielleicht stimmt es nicht mit der Realität überein. Es ist wichtig zu verstehen, was Sie zu tun haben, bevor Sie mit der Arbeit beginnen. Nehmen Sie sich etwas Zeit, um das Projekt durchzugehen und es gründlich zu studieren.

Erstellen Sie ein Abhängigkeitsdiagramm . Kein Projekt lebt in einem Vakuum. Datenbanken, externe Dienste, Bibliotheken - all dies kann im Projekt verwendet werden.

Was wurde dir angetan? Sie sind möglicherweise nicht die Ersten, die gegen das Biest kämpfen. Untersuchen Sie die Praktiken der „Vorfahren“, die niedergebrannt sind und das Projekt verlassen haben.

Nach der Aufklärung gehen wir zu den Feindseligkeiten über.

Kämpfe mit der Organisation

Die erste Runde ist ein Kampf mit Ihrer Organisation. Die Hauptsache ist Ihr Manager, der direkte Chef.

Manager . Er ist nicht so beängstigend, wie er scheint. Dies ist eine gewöhnliche Person mit gewöhnlichen Bedürfnissen: Um das Projekt pünktlich und ohne unnötige Probleme zu liefern, erhalten Sie Geld und Boni dafür und leben Sie weiter.

Der Führer ist nicht gegen Ihre Verpflichtungen. Er ist dagegen, dass Sie mit Rufen zum Projekt eilen: „Tests! Tests! Tests! ” Wenn Sie dies tun, wird er Sie als die Person betrachten, die seine Zeit verbringt und den Rest verlangsamt.

Zeigen Sie den Nutzen. Der Manager spricht die Sprache des Guten, der Zeit und des Geldes. Verstehen Sie, dass sie von dem Wunsch getrieben werden, das Projekt rechtzeitig abzuschließen und mehr Ergebnisse für weniger Ressourcen zu erzielen.

Der Test sollte nicht so eingereicht werden:

- Oh, es wird cool!

Unsere Ideen sollten wie folgt beworben werden:

- Im letzten Quartal hatten wir 50 Abstürze, die in der Produktentwicklungsphase behoben werden konnten. Sie können es mithilfe von Tests beheben. Sie werden bestätigen, dass die Änderungen die Funktionalität nicht verändert haben, wenn wir dies nicht erwarten. Wir sparen die Stunden, die für die Lösung dieser Probleme aufgewendet werden, und reduzieren den Betrag der Strafe, die aufgrund eines defekten Systems gezahlt wurde.

Wenn Sie "Optimierung, Geld, Zeit sparen" sagen, sprechen Sie die Sprache des Managers. Wenn er diese Worte hört, ist er von der Idee durchdrungen. Er sieht in Ihnen nicht den nächsten tollwütigen Programmierer, der sich für frische Technologie begeistert, sondern eine Person, die daran interessiert ist, das Produkt zu verbessern. Er wird nicht alle Ihre Ideen auf einmal genehmigen, aber er wird höchstwahrscheinlich Proof Of Concept vorschlagen.

Proof of Concept erhöht die Chancen.Stellen Sie dem Manager einen separaten isolierten Code zur Verfügung, ein Subsystem, das durch Tests abgedeckt, gestartet und ausgeführt wird. Dies kann geschehen, wenn Sie einen der wunden Fehler, die bei einer bestimmten Häufigkeit auftreten, nehmen und versuchen, ihn zu erkennen und mit einem Test zu beheben. PoC wird Ihre Absichten bestätigen, zeigen, dass Sie einen Plan haben und Ihre Arbeit Ergebnisse bringt.

Versprich nicht viel. Für den Manager sind die Zahlen wichtig: Was sind die Ergebnisse, das Timing und durch welche Kräfte. Aber der Manager ist eine Kreatur, die nach Ergebnissen gierig ist. Versprechen Sie von Anfang an nicht zu viel. Wenn Sie versprechen, alle Probleme auf einmal zu lösen, wird der Manager damit die Behörden kontaktieren. Die Behörden werden sagen: „Großartig!“, Aber sie werden die Finanzierung reduzieren und die Fristen verkürzen, in der Hoffnung, dass wir das System viel früher übergeben werden.

Wenn wir mit dem Manager einverstanden sind, wenden wir uns an diejenigen, mit denen wir jeden Tag arbeiten müssen.

Kollegen

Sie mögen keine Veränderung. Ein typischer Kollege in einem typischen Legacy-Projekt ist eine Person, die das Vertrauen in das Leben und die Zukunft verloren hat. Er ist nicht geneigt, sich zu ändern und hat sich dem Schicksal ergeben: "Ich bin für immer hier, es gibt keinen Ausweg aus dem Sumpf." Das Problem ist, dass Sie in diesem Sumpf anfangen, Wasser aufzurühren. Sie fordern ihn auf, einige Tests zu schreiben und durchzuführen, aber er möchte seinen Job machen, die Aufgabe schließen und nach Hause gehen.

Binden Sie Ihre Kollegen in die Vorteile ein - erklären Sie, warum sie sich besser fühlen. Zum Beispiel verbringen sie ständig Zeit und Mühe damit, nach der Arbeit einige Fehler zu heilen. Drücken Sie darauf: "Wenn Sie keinen fehlerhaften Code für die Produktion bereitstellen, müssen Sie keine Zeit damit verbringen, ihn zu reparieren." Wir werden Tests schreiben, wir werden solchen Code abfangen, er wird weniger kaputt gehen. "

Zeigen Sie Geduld und Empathie.Sie kommunizieren mit Menschen - fragen Sie, warum sie sich Sorgen um Ihre Idee machen? Schlagen Sie vor, eine gemeinsame Basis zu finden, um sich gegenseitig zu verstehen. Dies ist die Haupttaktik für die Arbeit mit Menschen: Nicht streiten, nicht auf die Stirn stoßen, freundlicher sein.

Möglicherweise können Sie die Idee nicht vor dem Treffen der Kollegen beim nächsten Team-Stand-up präsentieren. Der Mechanismus des „Gruppendenkens“ funktioniert im Team: Niemand möchte eine Entscheidung treffen, jeder schaut sich an und sieht, dass niemand vor Begeisterung brennt.

Es gibt einen schmutzigen Trick, um dieses Problem zu lösen. Leider habe ich es in meinem Leben mehr als einmal benutzt.

Teile und herrsche. Gehen Sie beim Mittagessen oder in der Ecke zu einem Ihrer Kollegen und sagen Sie: „Das gesamte Team hat sich bereits angemeldet, Sie sind der einzige, der den Prozess verlangsamt. Vielleicht können wir eine gemeinsame Sprache finden? “

Nachdem Sie alle nacheinander durchlaufen haben, unterschreiben Sie alle. Alle werden sich schämen zuzugeben, dass sie dachten, dass sich alle anderen bereits angemeldet haben. Es ist unehrenhaft und schrecklich, aber es funktioniert. Verwenden Sie diese Technik verantwortungsbewusst und als letzten Ausweg. Denken Sie daran - Sie müssen immer noch mit diesen Leuten arbeiten.

Wenn wir uns mit Kollegen abfinden, warten wir auf ein weiteres gieriges Tier.

Kämpfe mit dem Auto

Dies ist der Trick des Codes, der als Produkt bezeichnet wird. Beginnen wir mit den Grundlagen.

Zerlegen Sie den Müll. Es ist notwendig, dies mit minimalen Auswirkungen auf das System zu testen, um ein überprüfbares Ergebnis zu erhalten. Jedes Legacy-System ist jedoch voller Daten: Sie wurden seit dem Start seit Jahren hinzugefügt und beeinflussen das Verhalten des Systems. Daher ist es notwendig, "von Grund auf neu" zu testen.

Bereiten Sie ein "sphärisches System im luftleeren Raum" vor: Leeren Sie die Datenquellen, nehmen Sie die Mindestkonfigurationen vor, die das System startet, und deaktivieren Sie alle möglichen "Hacks" und "Features". Starten Sie das System. Wenn es startet, haben Sie den Mindestdatensatz, der für das Funktionieren erforderlich ist. Dies ist bereits ein guter Ausgangspunkt - ein "sauberer Schiefer".

Wenn Sie einige messbare Effekte verwenden, beispielsweise eine bestimmte Taste drücken, erhalten Sie ein messbares Arbeitsergebnis. Damit können Sie mit dem nächsten Schritt fortfahren.

Enträtseln Sie die Daten. Jedes Legacy-Projekt arbeitet nach dem Prinzip "muss gestern geliefert werden". Alles, was Sie zur Universität gegangen sind oder in Büchern gelesen haben, funktioniert hier nicht. Wenn Sie mit dem Testen beginnen, werden Sie beispielsweise auf eine zyklische Abhängigkeit stoßen, die im Programm nicht neu erstellt werden kann, aber für das Funktionieren erforderlich ist.

Beginnen Sie mit dem „Hauptobjekt“. Überlegen Sie sich, welches Objekt das Hauptobjekt ist, um mit dem Abhängigkeitswald umzugehen. Für das Lagerabrechnungssystem ist das Hauptobjekt beispielsweise die „Box“. Ein "Regal" -Objekt ist ihm zugeordnet, und ein "Zeilen" -Objekt ist einem "Regal" zugeordnet.

Erstellen Sie das erforderliche Minimum neu.Wenn Sie sich die Verknüpfungen zwischen Objekten ansehen und tiefer in den Abhängigkeitsbaum eintauchen, können Sie das erforderliche Minimum an Daten für abhängige Objekte ermitteln. Sie müssen es neu erstellen, damit das System funktioniert und Ihre Funktionalität testen kann.

Haben Sie keine Angst, Links zu ändern. Möglicherweise müssen Sie die Ärmel hochkrempeln und tief in dieses Chaos eintauchen: Löschen und Ändern von Links, Ändern der Struktur der Datenbank. Sie sind gekommen, um das System zu verbessern. Haben Sie also keine Angst, Änderungen vorzunehmen.

Wir gehen zum Testen über. Eine gute Strategie, um alte Produkte zu verwirren, sind Rauchtests.

Rauchtests

Das Konzept der "Rauchprüfung" kam aus der Welt der Elektronik. Ein Ingenieur baute eine riesige Schaltung mit einer Reihe von Glühbirnen und Drähten zusammen. Aber bevor ich mit dem Testen anfing, steckte ich den Stromkreis einfach in eine Steckdose. Wenn Rauch anfing, ging etwas schief.

In Informationssystemen ist das Konzept der Rauchtests recht einfach. Stellen Sie sich einen Webdienst vor, er hat einen Endpunkt. Versuchen wir, ihm eine GET-Anfrage ohne Parameter zu senden. Wenn das Produkt aus irgendeinem Grund plötzlich kaputt ging (Fehler 500), ist ein Fehler aufgetreten.

Rauchtest ist ein guter Anfang . Dies ist ein Test, der einige Funktionen testet und deutlich macht, dass das System funktioniert oder defekt ist. Selbst eine einfache Anfrage an den einfachsten Endpunkt betrifft bereits mehr als 1% des Codes. Mit solch kleinen Tests bereiten wir ein Sprungbrett für weitere Tests vor.

Der Rauchtest zeigt viele Probleme. Es ist möglich, dass während des gesamten Betriebszeitraums des Dienstes niemand vermutet hat, eine Anfrage ohne Parameter zu senden.

Verwenden Sie diese Taktik, um mehrere Haupteinstiegspunkte in Ihr Programm abzudecken: Anmelde- / Passworteingabeformular, grundlegende Webdienste, Schaltflächen. Dies können Sie dem Manager und den Kollegen bereits zeigen.

Funktionstests

Dies sind keine Tests einzelner Klassen oder einer Methode, sondern die höchstmögliche Teststufe für einen bestimmten Teil der Funktion.

Stellen Sie sich die Funktionalität zum Generieren eines Berichts im Service vor. Anstatt einzelne Teile zu überprüfen, testen wir die Situation der Anforderung, einen Bericht mit bestimmten Parametern zu erstellen und eine Datendatei abzurufen. Es ist nicht erforderlich, den Mechanismus zum Generieren des Berichts zu kennen. Wenn der Dienst jedoch bestimmte Ausgabedaten mit bestimmten Eingabedaten bereitstellt, funktioniert diese Black Box mit einiger Wahrscheinlichkeit ordnungsgemäß.

Durch die Erfassung der Hauptfunktionalität mit solchen Tests können Sie schnell beginnen und große Bereiche sofort abdecken. Sie werden sicher sein, dass der Code zumindest ungefähr so funktioniert, wie Sie es sich vorstellen, mehr Vertrauen gewinnen, Ihre Hand füllen und noch mehr Probleme aufdecken.

Funktionstests sind ein Mittel, kein Zweck.

Es ist einfach, sich an die Funktionstestnadel zu binden: "Ich teste echte Funktionalität! Dies ist, was Benutzer sehen. "

Ein Funktionstest umfasst große Codestücke, die mit riesigen Datenmengen interagieren können. Daher sind 3-4 Funktionstests gut, 10 sind schlechter und Tausende von Tests, die 9 Stunden dauern, sind zu viel. Leider passiert das auch.

Nehmen Sie nach Funktionstests Unit-Tests vor. Aber ich werde nicht darüber reden - du weißt schon alles.

Wir gingen die Grundlagen des Maschinentests durch und kehrten zum Hauptthema zurück. Kollegen und Manager sind nicht der schlimmste Feind im Kampf gegen das Erbe. Der schlimmste Feind bist du selbst.

Kämpfe mit dir selbst

Seien Sie darauf vorbereitet, dass der Weg endlos erscheint . Die Arbeit für eine Woche in Ihrem Plan dauert sechs Monate, ohne dass die Aussicht besteht, das Projekt abzuschließen.

Widerstand ist unvermeidlich . Alle Verbündeten werden irgendwann anfangen zu zweifeln, versuchen, aus der Spur zu geraten, sie zu überreden, Tests zu beenden und zu Funktionen überzugehen. Seien Sie darauf vorbereitet. Erinnern Sie alle daran, warum Sie sich an all dem beteiligt haben, wie viel Aufwand und Zeit investiert wurden. Schwaches Argument, könnte aber funktionieren.

Niemand garantiert Erfolg . Selbst wenn Sie heldenhafte Anstrengungen zeigen, sich selbst in die Arbeit stecken, kann Ihr Projekt immer noch ausbrennen, und der Kreuzzug mit den Tests wird in nichts enden.

Das ist normal, das ist nicht das Ende von Leben und Karriere. Dies ist nicht einmal eine Bestätigung dafür, dass Sie ein schlechter Profi sind. Die einzige Schlussfolgerung hier ist, dass dieses spezielle Projekt gescheitert ist.

Aber dann haben Sie Erfahrung und Wissen. Wenn Sie das nächste Mal einen neuen Speer in die Hand nehmen und Ihr Pferd zu einer anderen Windmühle beschleunigt, sind Sie auch bereit, diesen Speer zu brechen, jedoch später mit einer anderen Methode und mit weniger Schaden.

Jetzt beleidigend, bitter und ewig.

Trennwörter

Hab keine Angst vor Rückmeldungen. Ich musste in diese Falle treten und sehen, wie andere in sie fallen. Ich habe etwas getan und Kollegen dazu gebracht, sich zu rühmen: „Ich habe es getan!“ Aber plötzlich stellt sich heraus, dass mein praktischer Mechanismus für Kollegen unpraktisch ist, und ich habe nicht gefragt.

Schreiben Sie Tests, versuchen Sie, was Sie implementieren . Oft ist die Einführung eines neuen Testframeworks faszinierend, aber Sie schreiben die Tests nicht selbst. Dann kann es vorkommen, dass Sie, sobald Sie sie schreiben, verstehen, dass Sie die Tests nicht verwenden können. Vielleicht sehen Kollegen das auch, schweigen aber oder schreiben einfach keine Tests.

Helfen Sie Kollegen bei Problemenauch wenn sie nicht danach fragen. Hilfe bedeutet nicht, die ganze Arbeit auf sich zu nehmen - sie entspannt die Kollegen und entlastet sie von Verantwortung, und die „Bus“ -Nummer sinkt auf Eins. Dann werden Sie ein menschlicher Tester: Etwas ist kaputt, CI rot, Testanleitung. Hilfe im Rahmen des Vernünftigen.

Die "Bus" -Nummer ist kein Scherz. Sie können das Projekt nicht immer auf sich ziehen. Jeder kann ausbrennen, in den Urlaub fahren oder aufhören. Geben Sie daher Ihr Wissen und Ihre Verantwortung an Ihre Kollegen weiter, die erforderlich sind, um ohne Sie fertig zu werden. Dies hilft, unangenehme Anrufe zu vermeiden, wenn Sie am Strand entspannen, und CI ist wieder rot.

Testmechanismen verbessern. Viele Probleme können einfach vermieden werden, weil langsame Tests plötzlich schnell wurden. Früher besetzten sie 20 Codezeilen, jetzt eine. Sie haben dies nicht bemerkt, weil Sie einmal etwas geschrieben und vergessen haben: "Es funktioniert - berühren Sie es nicht!" Diese Regel gilt jedoch nicht immer.

Du bist nicht das Zentrum des Universums. Ich wiederhole noch einmal, dass die "Bus" -Nummer kein Scherz ist. Mehr als einmal stieß ich auf eine Situation, in der eine Person mit dem Testen begann und dann ein frischeres Angebot für das Projekt erhielt: Er verließ alles, lief weg, hinterließ aber keine Kommentare und Unterlagen. Alles funktioniert bis zu einem neuen Commit, aber es ist unmöglich, es zu beheben - niemand versteht, wie alles funktioniert.

Ich möchte nicht, dass du diese Person bist. Nicht zu einem begrenzenden Faktor werden.

Schreiben Sie die Dokumentation.
Führen Sie Schulungen durch.
Teile deine Erfahrung.

Wenn sich alle Kollegen auf dem gleichen Level wie Sie befinden (Plus oder Minus), verwandelt sich der Prozess von einem Rennen einer Person in ein Team-Staffellauf mit Übergabe der Flagge. Nur durch die Unterstützung Ihrer Kollegen werden Sie Erfolg haben. Wenn Sie alleine im Projekt sind, denken Sie, dass jemand anderes nach Ihnen auch alleine leiden wird. Geben Sie Ihrem Anhänger einen Freund in Form einer Dokumentation, lassen Sie ihn nicht alleine sterben.

27 Moscow Python Conf++ Python 2 Python 3 — 2020 .

, (fb, vk, twitter) telegram- . !

Das Biest zähmen: Legacy-Code, Tests und Sie