Sanitär-Syndrom: Legacy-Code-Regeln für Tests

Viele stießen auf einen Neuling, der zu dem Projekt kam und erklärte, dass "alles dringend erneuert werden muss". Und einige selbst sagten oder dachten. Dies ist das „Sanitärsyndrom“: Verhalten, das durch den Wunsch gekennzeichnet ist, alles auf die eigene Art und Weise zu tun, „richtig“, wenn an einem neuen Projekt gearbeitet wird oder wenn ein neuer Job angetreten wird. Daher müssen der vorhandene Code, die vorhandenen Technologien oder Tools neu geschrieben werden, vorzugsweise "für sich selbst". Das Thema wäre alltäglich, wenn es nicht bei jeder Neueinstellung so oft von Projekt zu Projekt wiederholt würde.

Je länger das Projekt „lebt“, desto mehr sammelt es einen „historischen“, geerbten Code und desto höher ist die Wahrscheinlichkeit, den brennenden Augen eines vom „Syndrom“ betroffenen Klempners zu begegnen. In diesem Beitrag möchte ich Ihnen sagen, an welchen Prinzipien Parallels festhält (sofort ist der Spoiler das Prinzip „keinen Schaden anrichten“) und was wir tun, wenn wir uns schließlich dazu entschließen, „alles zu wiederholen“. Obwohl wir im Allgemeinen der Meinung sind, dass dieses Syndrom behandelt werden sollte und dass die Verwendung von Legacy manchmal sogar nützlich ist, da Sie das Produkt rechtzeitig veröffentlichen und keine Zeit mit der Entwicklung Ihrer Technologien verschwenden können.

Wenn Sie mit „langlebigen Programmen“ arbeiten, ist der Legacy-Code ein ausreichend großer Prozentsatz. Zum Beispiel wird Parallels Desktop seit über 15 Jahren entwickelt. Jedes Jahr erweitert sich das Team, neue Leute kommen, schauen sich an, was geschrieben steht, und erklären: "Alles ist schief, lasst uns dem Programmierer die Hände abreißen und alles neu schreiben." Eine vertraute Situation?

Bevor ich anfange zu sagen, ob der Legacy-Code gut oder schlecht ist, möchte ich entscheiden, wer dies und was versteht. Normalerweise werden zwei Definitionen verwendet: Die erste ist Code, der nicht durch Tests abgedeckt wird. Unter dem Gesichtspunkt des automatischen Testens wird nicht der gesamte Code durch Tests abgedeckt. Der zweite Legacy-Code ist der Code, den Sie geerbt haben. Wenn Sie verstehen müssen, wie es funktioniert, aber niemand zu fragen. Und du musst dich selbst darum kümmern.

Ermächtigte Weisheit

I. Das Beste ist der Feind des Guten. Wenn der Legacy-Code oder das Legacy-System alle erforderlichen Funktionen mit akzeptabler Qualität ausführt, müssen Sie ihn nicht verbessern. Es ist besser, Ihre kochende Energie auf etwas Nützlicheres zu lenken.

II. Wählen Sie aus dem Wichtigen und dem Neuen das Wichtige, aus dem Gleichen das Neue. Wenn der Legacy-Code wichtige Funktionen enthält und nicht durch Tests abgedeckt wird, müssen Sie ihm maximale Aufmerksamkeit widmen, sowohl bei der Verarbeitung des Codes als auch bei der Abdeckung mit Tests. Wenn der Legacy-Code und die neuen Funktionen gleich wichtig sind, sollten Sie sich auf neue Funktionen (Entwicklung und Tests) konzentrieren.

III. Wenn das alte nicht verbessert werden kann, bauen Sie ein neues in der Nähe und werfen Sie das alte weg. Wenn der Legacy-Code benötigt wird, aber nicht geändert werden kann, verwenden Sie den alten Code, bis Sie den neuen schreiben und debuggen. Wenn der neue Code funktioniert, kann der alte weggeworfen werden.

Was zu tun ist?

Schritt 1. Wir schauen, wer gesagt hat
1. Freiberufler . In den meisten Fällen wiederholen Personen, die keine Erfahrung mit der Teilnahme an einem großen Projekt von der Seite haben, den Code vollständig. Zum Beispiel habe ich selbst zuerst freiberuflich gearbeitet, Projekte von Grund auf neu geschrieben und wie viele ähnliche Entwickler eine ziemlich stabile Angewohnheit entwickelt - genau so zu tun, wie ich mich wohl fühle.

2. Unerfahren . Manchmal deuten solche Aussagen auf eine mangelnde Qualifikation der Person selbst im Fachgebiet hin: Sie kennt die Geschichte des Projekts nicht und zum Beispiel, dass diese (seiner Meinung nach) beängstigende Konstruktion darauf zurückzuführen ist, dass Menschen während des Entwicklungsprozesses auf externe Fehler gestoßen sind Systeme und begann, um sie herumzukommen. Infolgedessen gab es eine Art Spaghetti von miteinander verbundenen Flecken und Krücken für diese Käfer. Eine solche Kenntnis aller bestehenden Fallstricke beim Menschen von außen kann grundsätzlich nicht sein.

3. D'Artagnan . Meistens geschieht dies bei Ingenieuren, die keine Produkterfahrung und Erfahrung in großen Projekten haben und nicht verstehen, welchen Preis sie erhalten. Ein Mann schlägt sich mit der Ferse in die Brust und sagt, dass er es brillant, frisch und in nur einer Woche tun wird, aber er kann sich tief in seinen Fähigkeiten irren und weil er Punkte wie das Testen und die Integration in das bestehende größere System völlig verfehlt.

4. Hochqualifizierter Spezialist. Die einzige Art von "Bewerbern", die Sie hören sollten, obwohl sie sich beeilen, seinen Rat zu wiederholen, lohnt sich immer noch nicht, bis Schritt 2 abgeschlossen ist. Es ist möglich, dass wir einen hochklassigen Fachmann haben und er kann wirklich beweisen, dass wir dies nicht tun also und kann es besser machen. Tatsache ist jedoch, dass ich mit solchen Aussagen keine einzige Person auf Senior-Ebene getroffen habe. Wenn ein Mensch auf ein solches Niveau wächst, kann er sich das Projekt bereits als Ganzes vorstellen und versteht alle Mängel der "revolutionären" Methode.

Schritt 2. Argumentation
Das erste, was eine Person stoppen und ihre Argumente analysieren muss. Diese Studie sollte vom Teamleiter initiiert werden. Mit der Einschränkung, dass das "Sanitär-Syndrom" nicht anfing, eine Person zu leiden, die selbst Teamleiter wurde. Dann ist die Analyse des Fluges Aufgabe des Projektmanagers, obwohl ein reifer Teamleiter offen gesagt niemals eine vollständige Änderung ohne ernsthafte Argumentation einleitet.

Welche Argumente werden fehlschlagen:
"Wir werden unsere eigenen schreiben, mit Schach und Dichtern"
Wenn ein Produkt schon lange auf dem Markt ist, funktioniert es meistens schon irgendwie. Er hat bereits gezeigt, dass es trotz der schrecklichen Natur dessen, was sich unter der Haube befindet, funktioniert. Zum Beispiel haben wir Parallels Desktop (eine Lösung, um Windows und andere Betriebssysteme auf einem Mac ohne Neustart auszuführen), und manchmal können Sie von Anfängern hören: "Irgendwie sind Sie hier allzu kompliziert, schreiben wir meine virtuelle Maschine." Und da solche Dinge im Prinzip nicht sofort erledigt werden können, ist eine Person, die dies sagt, entweder nicht zum Thema oder nicht allein. Es ist notwendig, ihm erste Erfahrungen mit dem Projekt zu geben und zu verstehen, warum es von Anfang an so umgesetzt wurde.

"Es ist hässlich."
Das Problem ist, dass eine Person oft keine anderen Argumente hat. "Nicht technologisch fortgeschritten", "auf etwas Müll gemacht", "warum es in C geschrieben ist, ist es jetzt in Mode, in Go zu schreiben." Dies sind keine Argumente für die Neugestaltung des Systems. Denn wenn Sie über Ihren einen Code hinausgehen, werden Sie feststellen, dass Ihre Nacharbeit möglicherweise schlimmer ist als zuvor. Im Inneren sieht es möglicherweise hübscher aus und arbeitet langsamer, was für das Produkt nicht akzeptabel ist. Ich habe dies in Parallels nicht gesehen, aber in der vorherigen Firma mussten wir alle Konsequenzen dieses Schritts vollständig erfahren. Wir entschieden, dass die Treiberfamilie für bestimmte Geräte hässlich implementiert war, und wir brauchten ein eleganteres und erweitertes Design, das einfacher zu warten und neue Funktionen hinzuzufügen wäre. Sie haben anderthalb Jahre lang neu und schön geschrieben, aber am Ende stellte sich heraus, dass es genauso schrecklich war und keine Vorteile brachte. Und die Kosten für Ressourcen erwiesen sich als sehr hoch: Zwei Entwickler haben eineinhalb Jahre Arbeit verschlungen.

Warum es besser ist, den langfristigen Code eines großen Projekts nicht zu berühren

Sie können sogar Ihr Projekt beenden
Wo ist die Garantie, dass Sie etwas wieder schreiben und es richtig funktioniert? Immerhin ist dies noch nicht. Aus geschäftlicher Sicht müssen Sie in der Gegenwart leben und die Kontinuität der Umsatzgenerierung sicherstellen.

Sie können Krücken brechen
In jedem Projekt gibt es so etwas wie Kludge (besser bekannt als „Krücke“) und viele undokumentierte Dinge. Ja, es gibt eine solche Entwicklungsmethode, wenn die Dokumentation zuerst geschrieben wird und dann die Entwicklung strikt befolgt wird, aber sie hat sich in den 90er Jahren immer noch als zu träge für Geschäftsaufgaben erwiesen. Vielleicht können Sie auf diese Weise eine Rakete bauen, dh in Prozessen, in denen die Entwicklung seit mehreren Jahrzehnten stattfindet, ist dies gerechtfertigt, da das Risiko von Abweichungen groß ist. Und selbst dort müssen Sie unterwegs einige Änderungen vornehmen.

Und aus Sicht der kommerziellen Entwicklung von Software bleibt nicht so viel Zeit, um zuerst alles in der Dokumentation zu berücksichtigen und dann zu tun. Und es stellt sich heraus, dass alle Produkte eine große Menge unausgesprochener Daten enthalten. Bei einem Umweltproblem, zum Beispiel, arbeitete etwas Eisen, um die Spezifikation zu umgehen, daran. In vielen Fällen wird eine relativ geringfügige Änderung häufig vergessen und nicht in der Dokumentation berücksichtigt. Es ist nur in den Code eingeklemmt und meistens - leider mit einem kleinen vernünftigen Kommentar.

Und es beginnt: Lassen Sie uns all diese Krücken rauswerfen, da nicht klar ist, dass es den Code verdirbt. Und sie denken nicht, wohin es führen wird. Als wir zum Beispiel einen unserer Patches für den Linux-Kernel erstellt haben, hat an einer Stelle eine solche Krücke geknallt: Sie war sehr hässlich und gleichzeitig ziemlich schlecht beschrieben. Und dann erfuhren sie in der Diskussion: Bestimmte Geräte ohne dieses Lager funktionieren nicht. Ja, es wird nicht mehr produziert, aber die Benutzer haben es immer noch und es funktioniert. Und der Verlust der Unterstützung für diese Hardware widerspricht der Linux-Community-Philosophie. Ich musste unseren Code neu schreiben, damit diese Problemumgehung eins zu eins erhalten blieb und danach alle zufrieden waren.

Sie können Ressourcen verschwenden
Ein Beispiel für eine solche Verschwendung von Ressourcen ist oben angegeben. Es versteht sich, dass jede Revolution zu einem Bürgerkrieg führt, zu einer bestimmten Zeit mit einer Verschlechterung des Zustands, in der nichts funktionieren wird.

Sie können den Initiator und das Projekt verlieren
Das Sanitär-Syndrom betrifft hauptsächlich neue Mitarbeiter. Es sei daran erinnert, dass solche Personen gefährdet sind, weil sie das Unternehmen während der Probezeit verlassen können (nicht umsonst sagen sie, dass die Probezeit nicht nur für die Person, sondern auch für das Unternehmen gilt). Der Mann erhielt einen Freibrief, er begann ihn zu wiederholen und erklärte dann, dass er keinen Kaffee in der Firma mochte und ging. Dies ist eine sehr gefährliche Situation. Es stellt sich heraus, dass es nichts Neues gibt, aber das Alte ist bereits kaputt. Dann muss jemand (und keineswegs ein Enthusiast) es in Arbeitsform bringen.

Was tun, wenn die Entscheidung, die Entscheidung nicht zu wiederholen, offensichtlich ist und die Person „mit einer Idee brennt“?

Lassen Sie Zeit zum Abkühlen und Nachdenken
Sie müssen nur der Person Zeit geben, die zu einem großen bestehenden Projekt gekommen ist, um sich besser kennenzulernen. Denn wenn eine Idee von einer Person stammt, die lange Zeit in einem Unternehmen und speziell mit diesem Produkt gearbeitet hat, werden seine Initiativen viel ernster genommen und anhand ihrer Argumente analysiert. Sie müssen ihm erklären, dass Sie nicht in einen Bereich werfen sollten, mit dem Sie noch nicht ausreichend vertraut sind und die aktuelle Situation nicht kennen. Es ist zweifelhaft, dass eine Person, die gerade angekommen ist und sich den Code angesehen hat, vernünftigerweise erklären kann, warum alles falsch ist und warum es geändert werden muss.

Wenn eine Person eine solche Ablehnung ablehnt oder sehr viel anbietet, ist dies eine Gelegenheit, um festzustellen, dass dieser Entwickler möglicherweise nicht bereit ist, in einem Team zu arbeiten, und Kommunikationsschwierigkeiten mit ihm auftreten können (und dies ist ein sehr wichtiger Faktor für uns). Seitdem muss der Teamleiter separat im „manuellen Modus“ arbeiten. Vielleicht sollte eine solche Person ihre Ansichten über ihre Karriere überdenken und freiberuflich tätig werden, wo Sie alles „nach Bedarf“ tun können.

Richten Sie seine Energie in eine andere Richtung
Die meisten großen Produkte haben immer einige Engpässe und Probleme, die regelmäßig auftreten, da sich außen alles ändert. Obwohl es meiner Meinung nach immer noch sehr gefährlich ist, eine neue Person zum Code gehen zu lassen, bis sie ein paar Monate mit dem Debuggen kleiner Fehler arbeitet, sich mit dem vorhandenen Code vertraut macht und ihr Können unter Beweis stellt.
Es ist möglich, ihm eine Aufgabe aus einigen Nebenprojekten zu geben, damit er seine neuen Sachen dort ablegt und sieht, was passiert. Dies setzt voraus, dass es solche Zeitnischen gibt, da es eine begrenzte Anzahl von Aufgaben gibt. Hier habe ich wie bei einem Venture-Unternehmen in 100 Unternehmen investiert und Renditen für eines erhalten.

Wenn Sie noch wiederholen müssen

Das Produkt stirbt unter bestehenden Bedingungen
Das Argument für das Wiederherstellen - wenn sich die externe Umgebung so stark geändert hat, dass das vorhandene Produkt nicht mehr funktioniert. Als sie beispielsweise ein neues Betriebssystem herausbrachten, auf das Benutzer in großen Mengen umstellten, wurde in diesem Betriebssystem jedoch etwas geändert, sodass Ihr Produkt, das unter früheren Versionen normal funktionierte, nicht mehr funktionierte oder es für den Benutzer völlig unpraktisch wurde, es zu verwenden. Oder wenn die Plattform stirbt - zum Beispiel aus einer alten, können Sie BeOS zitieren, unter dem sie ziemlich viel mit Multimedia-Produkten gearbeitet haben, zum Beispiel komponierte Musik. Das System starb, und da es sehr unterschiedlich war, wurden die Codes praktisch nicht auf andere Systeme übertragen. Mit BeOS OS selbst passierte dasselbe: Es gab Atom-Computer, auf die sie abzielten, und dann stellte der Hersteller die Freigabe dieser Prozessoren ein, und die Leute, die für diesen Computer schrieben, hatten praktisch nichts mehr. Und sie mussten sich dringend an Intel anpassen, was sich für sie als schlecht herausstellte - die Nische war besetzt und ein anderes Betriebssystem regierte dort. Und um ihr Leben zumindest irgendwie zu verlängern, mussten sie es ernsthaft wiederholen, um die Portabilität zu verbessern und so weiter.

Das Sanitär-Syndrom hat funktioniert: Umbauphasen

Es ist notwendig, evolutionär und parallel zu handeln, ohne das System zu brechen. Der Prozess und die Phasen der Änderung hängen davon ab, ob wir das gesamte Produkt als Ganzes oder einen wesentlichen Teil davon ändern. Wenn das ganze Produkt, dann ist dies eigentlich der Beginn eines neuen Projekts von Grund auf neu. In den meisten Fällen wechseln sie jedoch immer noch den Teil, da es im ersten Fall mehr als ein Jahr dauern wird, bis die neue Codebasis Stabilität und Übereinstimmung mit den Verbraucherqualitäten erreicht, um zumindest das Niveau zu erreichen, das sie war.

Wenn Sie die Komponente austauschen, ist dies ratsam: Wenn für die externe Schnittstelle keine Änderungen erforderlich sind, führen wir die zweite Implementierung in aller Ruhe durch. Es ist ratsam, die Trennlinien sofort zu finden: hier bleibt das Alte übrig, aber hier ist es bereits möglich, Einstiegspunkte zu wiederholen. Wenn Sie also die Benutzeroberfläche beibehalten, ändern Sie die Füllung.

Es ist wie bei einem Auto, bei dem beschlossen wurde, den Gasmotor durch einen Elektromotor zu ersetzen. Für den Benutzer hat sich wenig geändert: Die gleiche Karosserie, vier Räder und das Lenkrad bleiben erhalten. Und unter der Haube kann alles andere sein.

Wenn es Ihnen gelingt, einen solchen Teilungspunkt zu finden, können Sie ihn evolutionär wiederholen, und jeder, der an diesem Teilungspunkt steht, bemerkt möglicherweise nicht einmal die Änderungen (außer hoffentlich einer Verbesserung der Arbeitsqualität). Und dann im Prozess des internen Tests wechseln und speichern Sie das Produkt. Leider ist dies bei weitem nicht immer möglich, und Änderungen können dann zu einer Katastrophe führen.

Oder diese Option: Die Schnittstelle ist fest, die Implementierung ist abgeschlossen, und dann beginnt sich die Schnittstelle iterativ zu ändern.

Es ist sinnvoll, eine ernsthafte Änderung an den Seitenzweigen vorzunehmen, und bis sie fertig ist, wird sie nicht in das Hauptprodukt integriert. Selbst in Bezug auf Subsysteme ist es schlimmer, wenn wir unter diesem Namen etwas völlig Neues anfangen und das Team sich getrennt hat, dann gibt es überhaupt kein Produkt.

Anstelle einer Schlussfolgerung

Ein Junge wurde mit einer Nuss anstelle eines Bauchnabels geboren. Und er fragte seine Eltern regelmäßig, warum er dort eine Nuss habe. Die Eltern versprachen, ihm an seinem 14. Geburtstag davon zu erzählen. Der Mann wurde 14 Jahre alt. Dann ging er wieder zu seinem Vater und seiner Mutter und fragte, warum er eine Nuss anstelle eines Bauchnabels habe. Die Eltern versprachen, ihm davon zu erzählen, wenn er 18 Jahre alt sein wird. Mit 18 fragte er erneut, und dann sagten sie ihm, dass es eine tropische Insel gibt, auf der eine Palme wächst, und unter dieser Palme ist ein Stamm begraben. Es gibt Antworten auf alle seine Fragen. Der Typ hat lange Zeit Geld gespart und sich trotzdem auf dieser Insel vergiftet. Ich fand eine Palme und grub eine Truhe aus, in der ein Schraubenschlüssel lag. Ohne zu zögern schraubte er die Mutter mit dem gefundenen Schraubenschlüssel ab und sein Arsch fiel ab. Moral: Manchmal muss man beim fünften Punkt einfach nicht nach Abenteuern suchen.