Sollte ich den Code, der als "Nicht ändern" gekennzeichnet ist, überarbeiten?

Ich habe es mit einer ziemlich großen Codebasis zu tun und bekam ein paar Monate Zeit, um vorhandenen Code zu überarbeiten. Der Refactor-Prozess ist erforderlich, da wir in Kürze viele neue Funktionen zu unserem Produkt hinzufügen müssen und derzeit keine Funktion mehr hinzufügen können, ohne etwas anderes zu beschädigen. Kurz gesagt: chaotischer, riesiger, fehlerhafter Code, den viele von uns in ihrer Karriere gesehen haben.

Während des Refactorings stoße ich von Zeit zu Zeit auf Klassen, Methoden oder Codezeilen mit Kommentaren wie

Eine Auszeit ist vorgesehen, um Modul A etwas Zeit zu geben, um Dinge zu erledigen. Wenn es nicht so zeitgesteuert ist, wird es brechen.

oder

Ändern Sie dies nicht. Vertrauen Sie mir, Sie werden Dinge brechen.

oder

Ich weiß, dass setTimeout keine gute Übung ist, aber in diesem Fall musste ich es verwenden

Meine Frage ist: Soll ich den Code überarbeiten, wenn ich auf solche Warnungen der Autoren stoße (nein, ich kann mich nicht mit den Autoren in Verbindung setzen)?

Es scheint, als würden Sie "nur für den Fall" umgestalten, ohne genau zu wissen, welche Teile der Codebasis im Detail geändert werden, wenn die Entwicklung der neuen Funktionen stattfinden wird. Andernfalls würden Sie wissen, ob die spröden Module wirklich nachbearbeitet werden müssen oder ob Sie sie so lassen können, wie sie sind.

Um es klar zu sagen: Ich denke, dies ist eine zum Scheitern verurteilte Refactoring-Strategie . Sie investieren Zeit und Geld in Ihr Unternehmen für etwas, von dem niemand weiß, ob es wirklich einen Nutzen bringt, und Sie sind kurz davor, die Situation durch die Einführung von Fehlern in den Arbeitscode zu verschlimmern.

Hier ist eine bessere Strategie: Nutze deine Zeit um

• Fügen Sie den gefährdeten Modulen automatische Tests hinzu (wahrscheinlich keine Komponententests, sondern Integrationstests). Insbesondere die von Ihnen erwähnten spröden Module benötigen eine vollständige Testsuite, bevor Sie Änderungen vornehmen können.

• Refactor nur die Bits, die Sie benötigen, um die Tests an Ort und Stelle zu bringen. Versuchen Sie, alle erforderlichen Änderungen zu minimieren. Die einzige Ausnahme ist, wenn Ihre Tests Fehler aufdecken - und diese dann sofort beheben (und in dem Maße umgestalten, in dem Sie dies sicher tun müssen).

• Bringen Sie Ihren Kollegen das "Pfadfinderprinzip" (AKA "opportunistic refactoring" ) bei. Wenn das Team neue Funktionen hinzufügt (oder Fehler behebt), sollten sie genau die Teile der Codebasis verbessern und umgestalten, die sie ändern müssen. nicht weniger, nicht mehr.

• Besorgen Sie sich ein Exemplar von Feders Buch "Effektiv mit altem Code arbeiten" für das Team.

Wenn Sie also genau wissen, dass Sie die spröden Module ändern und umgestalten müssen (entweder aufgrund der Entwicklung neuer Funktionen oder weil die in Schritt 1 hinzugefügten Tests einige Fehler aufdecken), sind Sie und Ihr Team bereit dafür Überarbeiten Sie die Module und ignorieren Sie diese Warnungskommentare mehr oder weniger sicher.

Als Antwort auf einige Kommentare : Um fair zu sein, wenn man den Verdacht hat, dass ein Modul in einem vorhandenen Produkt regelmäßig Probleme verursacht, insbesondere ein Modul, das mit "Nicht anfassen" gekennzeichnet ist, stimme ich allen zu Sie. Es sollte in diesem Prozess überprüft, getestet und höchstwahrscheinlich überarbeitet werden (mit Unterstützung der Tests, die ich erwähnt habe, und nicht unbedingt in dieser Reihenfolge). Bugs sind eine starke Rechtfertigung für Veränderungen, oftmals eine stärkere als neue Funktionen. Dies ist jedoch eine Einzelfallentscheidung. Man muss sehr genau prüfen, ob es sich wirklich lohnt, etwas in einem Modul zu ändern, das mit "nicht anfassen" gekennzeichnet ist.

Ja, Sie sollten den Code überarbeiten, bevor Sie die anderen Funktionen hinzufügen.

Das Problem bei Kommentaren wie diesen ist, dass sie von bestimmten Umständen der Umgebung abhängen, in der die Codebasis ausgeführt wird. Die Zeitüberschreitung, die an einem bestimmten Punkt programmiert wurde, war bei der Programmierung möglicherweise wirklich notwendig.

Es gibt jedoch eine Reihe von Faktoren, die diese Gleichung ändern können: Hardwareänderungen, Änderungen des Betriebssystems, nicht damit zusammenhängende Änderungen in einer anderen Systemkomponente, Änderungen in typischen Datenmengen, wie Sie es nennen. Es gibt keine Garantie dafür, dass dies auch heute noch notwendig oder ausreichend ist (die Integrität des zu schützenden Gegenstands könnte lange Zeit verletzt worden sein - ohne geeignete Regressionstests, die Sie möglicherweise nie bemerken). Aus diesem Grund ist die Programmierung einer festen Verzögerung zum Beenden einer anderen Komponente fast immer falsch und funktioniert nur aus Versehen.

In Ihrem Fall kennen Sie die ursprünglichen Umstände nicht und können auch nicht die ursprünglichen Autoren fragen. (Vermutlich haben Sie auch keine richtigen Regressionstests / Integrationstests, oder Sie könnten einfach weitermachen und sich von Ihren Tests sagen lassen, ob Sie etwas kaputt gemacht haben.)

Dies könnte ein Argument dafür sein, nichts aus Vorsicht zu ändern. Sie sagen jedoch, dass es ohnehin große Änderungen geben muss, sodass die Gefahr besteht, dass das zuvor an dieser Stelle erreichte heikle Gleichgewicht gestört wird. Es ist viel besser, den Apfelkarren jetzt zu verärgern , wenn das einzige, was Sie tun, das Refactoring ist, und sicher zu sein, dass es das Refactoring war, das ihn verursacht hat, als zu warten, bis Sie gleichzeitig und niemals weitere Änderungen vornehmen sicher sein.

Meine Frage ist: Soll ich den Code überarbeiten, wenn ich auf solche Warnungen der Autoren stoße?

Nein oder zumindest noch nicht. Sie implizieren, dass der Umfang der automatisierten Tests sehr gering ist. Sie benötigen Tests, bevor Sie sicher umgestalten können.

Im Moment können wir keine Funktion mehr hinzufügen, ohne etwas anderes zu beschädigen

Im Moment müssen Sie sich auf die Erhöhung der Stabilität konzentrieren, nicht auf das Refactoring. Sie können Refactoring als Teil der Stabilitätssteigerung durchführen, aber es ist ein Werkzeug, um Ihr eigentliches Ziel zu erreichen - eine stabile Codebasis.

Es hört sich so an, als ob dies eine alte Codebasis geworden ist. Sie müssen sie also etwas anders behandeln.

Beginnen Sie mit dem Hinzufügen von Charakterisierungstests. Machen Sie sich keine Gedanken über Spezifikationen, fügen Sie einfach einen Test hinzu, der das aktuelle Verhalten bestätigt. Auf diese Weise wird verhindert, dass neue Arbeiten vorhandene Features beschädigen.

Fügen Sie jedes Mal, wenn Sie einen Fehler beheben, einen Testfall hinzu, der beweist, dass der Fehler behoben ist. Dies verhindert direkte Regressionen.

Wenn Sie ein neues Feature hinzufügen, fügen Sie mindestens einige grundlegende Tests hinzu, die sicherstellen, dass das neue Feature wie beabsichtigt funktioniert.

Vielleicht erhalten Sie eine Kopie von "Effektiv mit Legacy-Code arbeiten"?

Ich hatte ein paar Monate Zeit, um vorhandenen Code zu überarbeiten.

Beginnen Sie, indem Sie die Testabdeckung verbessern. Beginnen Sie mit den Bereichen, die am meisten stören. Beginnen Sie mit Bereichen, die sich am meisten ändern. Sobald Sie fehlerhafte Designs identifiziert haben, ersetzen Sie diese nacheinander.

Sie machen fast nie einen großen Refaktor, sondern jede Woche einen konstanten Strom kleiner Refaktoren. Ein großer Refaktor birgt ein enormes Risiko, Dinge zu zerbrechen, und es ist schwierig, gut zu testen.

Denken Sie an den Zaun des GK Chesterton : Nehmen Sie keinen Zaun herunter, der eine Straße blockiert, bis Sie verstehen, warum er gebaut wurde.

Sie können den Autor (die Autoren) des Codes und die fraglichen Kommentare finden und sie konsultieren, um das Verständnis zu erlangen. Sie können sich die Commit-Nachrichten, E-Mail-Threads oder Dokumente ansehen, falls vorhanden. Dann können Sie entweder das markierte Fragment umgestalten oder Ihr Wissen in die Kommentare eintragen, damit die nächste Person, die diesen Code verwaltet, eine fundiertere Entscheidung treffen kann.

Ihr Ziel ist es, zu verstehen, was der Code bewirkt und warum er damals mit einer Warnung gekennzeichnet war und was passieren würde, wenn die Warnung ignoriert würde.

Vorher würde ich den Code mit der Aufschrift "Nicht berühren" nicht berühren.

Code mit Kommentaren wie denen, die Sie gezeigt haben, würde auf meiner Liste der Dinge, die umgestaltet werden müssen, ganz oben stehen , und zwar nur dann, wenn ich einen Grund dazu habe . Der Punkt ist, dass der Code so schlecht stinkt, dass man ihn sogar durch die Kommentare riecht. Es ist sinnlos zu versuchen, neue Funktionen in diesen Code einfließen zu lassen. Dieser Code muss sterben, sobald er sich ändern muss.

Beachten Sie auch, dass die Kommentare nicht im geringsten hilfreich sind: Sie geben nur eine Warnung und keinen Grund. Ja, das sind die Warnschilder um einen Haifischpanzer. Aber wenn Sie in der Nähe etwas unternehmen möchten, gibt es wenig Punkte, um zu versuchen, mit den Haien zu schwimmen. Imho, sollten Sie zuerst diese Haie loswerden.

Das heißt, Sie brauchen unbedingt gute Testfälle, bevor Sie sich trauen können, an einem solchen Code zu arbeiten. Wenn Sie diese Testfälle haben, müssen Sie jedes noch so kleine bisschen verstehen, das Sie ändern, um sicherzustellen, dass Sie Ihr Verhalten nicht wirklich ändern. Machen Sie es sich zur obersten Priorität, alle Verhaltensmerkmale des Codes beizubehalten, bis Sie nachweisen können, dass sie keine Auswirkungen haben. Denken Sie daran, Sie haben es mit Haien zu tun - Sie müssen sehr vorsichtig sein.

Im Fall einer Zeitüberschreitung: Lassen Sie die Option aktiviert, bis Sie genau wissen, worauf der Code wartet, und legen Sie den Grund für die Zeitüberschreitung fest, bevor Sie mit dem Entfernen fortfahren.

Stellen Sie außerdem sicher, dass Ihr Chef versteht, was für ein Unterfangen Sie unternehmen und warum es erforderlich ist. Und wenn sie nein sagen, tu es nicht. Sie brauchen unbedingt ihre Unterstützung dabei.

Wahrscheinlich ist es keine gute Idee, den Code mit solchen Warnungen zu überarbeiten, wenn die Dinge so funktionieren, wie sie sind.

Aber wenn Sie umgestalten müssen ...

Schreiben Sie zunächst einige Komponententests und Integrationstests , um die Bedingungen zu testen, vor denen Sie in den Warnungen gewarnt werden. Versuchen Sie, produktionsähnliche Bedingungen so gut wie möglich nachzuahmen . Dies bedeutet, dass Sie die Produktionsdatenbank auf einen Testserver spiegeln, dieselben anderen Dienste auf dem Computer ausführen usw., was auch immer Sie tun können. Versuchen Sie dann Ihr Refactoring (natürlich auf einem isolierten Zweig). Führen Sie dann Ihre Tests mit Ihrem neuen Code durch, um festzustellen, ob Sie dieselben Ergebnisse wie mit dem Original erzielen können. Wenn Sie können, ist es wahrscheinlich in Ordnung, Ihr Refactoring in der Produktion zu implementieren. Aber seien Sie bereit, die Änderungen rückgängig zu machen, wenn etwas schief geht.

Ich sage, mach weiter und ändere es. Ob Sie es glauben oder nicht, nicht jeder Codierer ist ein Genie und eine Warnung wie diese bedeutet, dass es ein Ort für Verbesserungen sein könnte. Wenn Sie feststellen, dass der Autor Recht hat, können Sie DOKUMENTIEREN oder den Grund für die Warnung erklären (nach Luft schnappen).

Ich erweitere meine Kommentare zu einer Antwort, weil ich denke, dass einige Aspekte des spezifischen Problems entweder übersehen werden oder verwendet werden, um die falschen Schlussfolgerungen zu ziehen.

Zu diesem Zeitpunkt ist die Frage, ob eine Refaktorisierung durchgeführt werden soll, verfrüht (auch wenn dies wahrscheinlich durch ein bestimmtes Ja beantwortet wird).

Das zentrale Problem hierbei ist, dass (wie in einigen Antworten erwähnt) die von Ihnen zitierten Kommentare nachdrücklich darauf hinweisen, dass der Code Race-Bedingungen oder andere Parallelitäts- / Synchronisationsprobleme aufweist, wie hier beschrieben . Dies sind aus mehreren Gründen besonders schwierige Probleme. Erstens können, wie Sie festgestellt haben, scheinbar nicht zusammenhängende Änderungen das Problem auslösen (andere Fehler können ebenfalls diesen Effekt haben, aber Parallelitätsfehler sind fast immer der Fall.) Zweitens sind sie sehr schwer zu diagnostizieren: Der Fehler manifestiert sich häufig an einem Ort, an dem er sich befindet Zeit oder Code von der Ursache entfernt, und alles, was Sie tun, um sie zu diagnostizieren, kann dazu führen, dass sie verschwindet ( Heisenbugs). Drittens sind Parallelitätsfehler beim Testen sehr schwer zu finden. Dies liegt zum Teil an der kombinatorischen Explosion: Sie ist für sequentiellen Code schon schlimm genug, aber das Hinzufügen der möglichen Verschachtelungen der gleichzeitigen Ausführung führt dazu, dass das sequentielle Problem im Vergleich dazu nicht mehr von Bedeutung ist. Darüber hinaus kann selbst ein guter Testfall das Problem nur gelegentlich auslösen - Nancy Leveson errechnete, dass einer der tödlichen Fehler im Therac 25 isttrat in 1 von ungefähr 350 Läufen auf, aber wenn Sie nicht wissen, was der Fehler ist, oder sogar, dass es einen gibt, wissen Sie nicht, wie viele Wiederholungen einen wirksamen Test durchführen. Darüber hinaus ist in diesem Maßstab nur ein automatisiertes Testen möglich, und es ist möglich, dass der Testtreiber subtile zeitliche Einschränkungen auferlegt, so dass er den Fehler nie mehr auslöst (Heisenbugs again).

In einigen Umgebungen gibt es einige Tools zum Testen der Parallelität, z. B. Helgrind für Code unter Verwendung von POSIX-Pthreads. Wir kennen die Details hier jedoch nicht. Das Testen sollte durch eine statische Analyse ergänzt werden (oder ist das umgekehrt?), Wenn es geeignete Tools für Ihre Umgebung gibt.

Um die Schwierigkeit zu erhöhen, können Compiler (und sogar die Prozessoren zur Laufzeit) den Code oft auf eine Weise reorganisieren, die es manchmal unmöglich macht, über die Threadsicherheit nachzudenken (vielleicht ist der bekannteste Fall die doppelte Überprüfung) sperren Sie Idiom, obwohl einige Umgebungen (Java, C ++ ...) geändert worden sind, um es zu verbessern.)

Dieser Code kann ein einfaches Problem haben, das alle Symptome verursacht, aber es ist wahrscheinlicher, dass Sie ein systembedingtes Problem haben, das Ihre Pläne, neue Funktionen hinzuzufügen, zum Erliegen bringen könnte. Ich hoffe, ich habe Sie überzeugt, dass Sie möglicherweise ein ernstes Problem in Ihren Händen haben, möglicherweise sogar eine existenzielle Bedrohung für Ihr Produkt, und das erste, was Sie tun müssen, ist herauszufinden, was passiert. Wenn dies Parallelitätsprobleme aufzeigt, rate ich Ihnen dringend, diese zuerst zu beheben, bevor Sie sich überhaupt die Frage stellen, ob Sie allgemeinere Umgestaltungen vornehmen sollten, und bevor Sie versuchen, weitere Funktionen hinzuzufügen.

Ich habe es mit einer ziemlich großen Codebasis zu tun und bekam ein paar Monate Zeit, um vorhandenen Code zu überarbeiten. Der Refactor-Prozess wird benötigt, da wir in Kürze viele neue Funktionen zu unserem Produkt hinzufügen müssen [...]

Während des Refactorings stoße ich von Zeit zu Zeit auf Klassen, Methoden oder Codezeilen mit Kommentaren wie ["Fass das nicht an!"].

Ja, Sie sollten diese Teile speziell umgestalten . Diese Warnungen wurden von den Vorgängern dort platziert, um zu bedeuten, dass "nicht untätig mit diesem Zeug umgegangen wird, es ist sehr kompliziert und es gibt viele unerwartete Interaktionen". Da Ihr Unternehmen plant, die Software weiterzuentwickeln und viele Funktionen hinzuzufügen, wurden Sie speziell mit der Bereinigung dieses Materials beauftragt. Damit Sie nicht untätig daran herumspielen, sind Sie absichtlich mit dem Aufräumen beauftragt.

Finden Sie heraus, was diese kniffligen Module tun, und teilen Sie sie in kleinere Probleme auf (was die ursprünglichen Autoren hätten tun sollen). Um einen wartbaren Code zu erhalten, müssen die guten Teile überarbeitet und die schlechten Teile neu geschrieben werden .

Diese Frage ist eine weitere Variation der Debatte darüber, wann / wie Code refaktorisiert und / oder bereinigt werden soll, mit einer Prise "wie Code geerbt werden soll". Wir haben alle unterschiedliche Erfahrungen und arbeiten in unterschiedlichen Organisationen mit unterschiedlichen Teams und Kulturen. Es gibt also keine richtige oder falsche Antwort außer "Tu, was du denkst, dass du tun musst, und tu es auf eine Weise, die dich nicht entlassen". .

Ich glaube nicht, dass es viele Organisationen gibt, die es gut finden, wenn ein Geschäftsprozess auf die Seite fällt, weil die unterstützende Anwendung eine Code-Bereinigung oder -Refactoring benötigt.

In diesem speziellen Fall erhöhen die Codekommentare das Flag, dass das Ändern dieser Codeabschnitte nicht durchgeführt werden sollte. Wenn Sie also fortfahren und das Geschäft auf die Seite fällt, haben Sie nicht nur nichts zu zeigen, um Ihre Handlungen zu unterstützen, sondern es gibt tatsächlich ein Artefakt, das Ihrer Entscheidung widerspricht.

Daher sollten Sie, wie immer, vorsichtig vorgehen und Änderungen erst vornehmen, nachdem Sie alle Aspekte Ihrer bevorstehenden Änderungen verstanden und Möglichkeiten gefunden haben, diese zu testen. Achten Sie dabei sehr genau auf Kapazität und Leistung sowie auf das Timing die Kommentare im Code.

Dennoch muss Ihr Management das mit Ihrer Tätigkeit verbundene Risiko verstehen und sich darauf einigen, dass Ihre Tätigkeit einen Geschäftswert hat, der das Risiko überwiegt, und dass Sie das getan haben, was zur Minderung dieses Risikos getan werden kann.

Kommen wir jetzt alle zu unseren eigenen TODOs zurück und die Dinge, die wir kennen, können in unseren eigenen Code-Kreationen verbessert werden, wenn nur mehr Zeit vorhanden wäre.

Ja absolut. Dies sind eindeutige Anzeichen dafür, dass die Person, die diesen Code geschrieben hat, mit dem Code nicht zufrieden war und ihn wahrscheinlich angestochert hat, bis er funktioniert hat. Es ist möglich, dass sie die tatsächlichen Probleme nicht verstanden haben oder, schlimmer noch, verstanden haben und zu faul waren, sie zu beheben.

Es ist jedoch eine Warnung, dass große Anstrengungen erforderlich sind, um sie zu beheben, und dass mit solchen Korrekturen Risiken verbunden sind.

Im Idealfall können Sie das Problem ermitteln und richtig beheben. Zum Beispiel:

Eine Auszeit ist vorgesehen, um Modul A etwas Zeit zu geben, um Dinge zu erledigen. Wenn es nicht so zeitgesteuert ist, wird es brechen.

Dies deutet stark darauf hin, dass Modul A nicht korrekt angibt, wann es einsatzbereit ist oder wann die Verarbeitung abgeschlossen ist. Vielleicht wollte die Person, die das geschrieben hat, Modul A nicht reparieren oder konnte es aus irgendeinem Grund nicht. Dies scheint eine Katastrophe zu sein, die darauf wartet, geschehen zu können, da dies darauf hindeutet, dass eine Zeitabhängigkeit eher durch Glück als durch eine ordnungsgemäße Abfolge behoben wird. Wenn ich das sehen würde, würde ich es sehr gerne reparieren.

Ändern Sie dies nicht. Vertrauen Sie mir, Sie werden Dinge brechen.

Das sagt dir nicht viel. Es würde davon abhängen, was der Code tat. Es könnte bedeuten, dass es offensichtliche Optimierungen aufweist, die aus dem einen oder anderen Grund den Code tatsächlich beschädigen. Beispielsweise kann eine Schleife eine Variable mit einem bestimmten Wert belassen, von dem ein anderer Code abhängt. Oder eine Variable wird in einem anderen Thread getestet, und das Ändern der Reihenfolge der Variablenaktualisierungen kann den anderen Code beschädigen.

Ich weiß, dass setTimeout keine gute Übung ist, aber in diesem Fall musste ich es verwenden.

Das sieht einfach aus. Sie sollten in der Lage sein zu sehen, was gerade setTimeoutgeschieht, und vielleicht einen besseren Weg finden, dies zu tun.

Das heißt, wenn diese Art von Korrekturen außerhalb des Bereichs Ihres Refactors liegen, sind dies Hinweise darauf, dass der Versuch, innerhalb dieses Codes eine Refactor-Korrektur durchzuführen, den Bereich Ihres Aufwands erheblich erweitern kann.

Sehen Sie sich den betroffenen Code mindestens genau an und prüfen Sie, ob Sie den Kommentar mindestens so weit verbessern können, dass er das Problem deutlicher erklärt. Das könnte die nächste Person davor bewahren, sich demselben Rätsel zu stellen, mit dem Sie konfrontiert sind.

Der Autor der Kommentare hat den Code selbst höchstwahrscheinlich nicht vollständig verstanden . Wenn sie tatsächlich wüssten, was sie taten, hätten sie tatsächlich hilfreiche Kommentare geschrieben (oder die Rennbedingungen gar nicht erst vorgestellt). Ein Kommentar wie " Vertrau mir, du wirst Dinge zerbrechen. " Bedeutet für mich, dass der Autor versucht, etwas zu ändern, was unerwartete Fehler verursacht hat, die er nicht vollständig verstanden hat.

Der Code wird wahrscheinlich durch Raten und Ausprobieren entwickelt, ohne dass man genau weiß, was tatsächlich passiert.

Das heisst:

1. Es ist riskant, den Code zu ändern. Das Verstehen wird natürlich einige Zeit in Anspruch nehmen, und es folgt wahrscheinlich keinen guten Entwurfsprinzipien und kann unklare Auswirkungen und Abhängigkeiten haben. Es ist höchstwahrscheinlich nicht ausreichend getestet und wenn niemand vollständig versteht, was der Code tut, wird es schwierig sein, Tests zu schreiben, um sicherzustellen, dass keine Fehler oder Verhaltensänderungen eingeführt werden. Die Rennbedingungen (wie in den Kommentaren erwähnt) sind besonders belastend - dies ist ein Ort, an dem Unit-Tests Sie nicht retten werden.

2. Es ist riskant , den Code nicht zu ändern. Es ist sehr wahrscheinlich, dass der Code undurchsichtige Fehler und Rennbedingungen enthält. Wenn ein kritischer Fehler im Code entdeckt wird, oder eine hohe Priorität Geschäftsanforderungen ändern zwingt SieFormal diesen Code kurzfristig zu ändern, sind Sie in tiefen Schwierigkeiten. Jetzt haben Sie alle in 1 umrissenen Probleme, aber unter Zeitdruck! Darüber hinaus neigen solche "dunklen Bereiche" im Code dazu, andere Teile des Codes, die sie berühren, zu verbreiten und zu infizieren.

Eine weitere Komplikation: Unit-Tests werden Sie nicht retten . Normalerweise besteht der empfohlene Ansatz für einen solchen veralteten Code darin, zuerst Unit- oder Integrationstests hinzuzufügen und dann zu isolieren und neu zu faktorisieren. Die Rennbedingungen können jedoch nicht durch automatisierte Tests erfasst werden. Die einzige Lösung besteht darin, sich hinzusetzen und den Code zu durchdenken, bis Sie ihn verstanden haben, und ihn dann neu zu schreiben, um die Rennbedingungen zu umgehen.

Dies bedeutet, dass die Aufgabe viel anspruchsvoller ist als nur routinemäßiges Refactoring. Sie müssen es als echte Entwicklungsaufgabe einplanen.

Möglicherweise können Sie den betroffenen Code im Rahmen des regulären Refactorings kapseln, sodass zumindest der gefährliche Code isoliert ist.

Die Frage, die ich stellen würde, ist, warum jemand schrieb, überhaupt NICHT BEARBEITEN.

Ich habe an einer Menge Code gearbeitet, und einige davon sind hässlich, und ich habe viel Zeit und Mühe gebraucht, um unter den gegebenen Bedingungen zu arbeiten.

Ich wette, in diesem Fall ist dies passiert und die Person, die den Kommentar geschrieben hat, hat festgestellt, dass jemand ihn geändert hat und dann die gesamte Übung wiederholen und zurückstellen musste, um die Sache zum Laufen zu bringen. Danach schrieben sie aus Scherfrustration ... NICHT BEARBEITEN.

Mit anderen Worten, ich möchte das nicht noch einmal beheben müssen, da ich bessere Dinge mit meinem Leben zu tun habe.

Mit der Aussage "NICHT BEARBEITEN" können wir sagen, dass wir alles wissen, was wir jemals wissen werden, und daher werden wir in Zukunft niemals etwas Neues lernen.

Es sollte mindestens ein Kommentar zu den Gründen für die Nichtbearbeitung vorhanden sein. Zum Beispiel "Nicht berühren" oder "Nicht eintreten". Warum nicht den Zaun berühren? Warum nicht eintreten? Wäre es nicht besser zu sagen: "Elektrozaun, nicht anfassen!" oder "Landminen! Nicht betreten!". Dann ist es offensichtlich, warum und dennoch können Sie eingeben, aber zumindest die Konsequenzen kennen, bevor Sie dies tun.

Ich wette auch, das System hat keine Tests um diesen magischen Code und daher kann niemand bestätigen, dass der Code nach einer Änderung korrekt funktioniert. Das Platzieren von Charakterisierungstests um den Problemcode ist immer ein erster Schritt. Unter "Arbeiten mit Legacy-Code" von Michael Feathers finden Sie Tipps zum Aufheben von Abhängigkeiten und zum Testen des Codes, bevor Sie Änderungen am Code vornehmen.

Ich denke, am Ende ist es kurzsichtig, Einschränkungen für die Umgestaltung und die natürliche und organische Weiterentwicklung des Produkts zu treffen.