Wie löscht man sicher einen Code, der so aussieht, als wäre er nie eingegeben worden?

Sie haben Code gefunden, der überflüssig aussieht, und der Compiler merkt das nicht. Was tun Sie, um sicherzustellen (oder so gut wie möglich), dass das Löschen dieses Codes keine Regression hervorruft?

Zwei Ideen kommen in den Sinn.

1. Verwenden Sie "einfach" den Abzug basierend darauf, ob der Code so aussieht, als ob er ausgeführt werden soll oder nicht. Manchmal ist dies jedoch ein komplexer, zeitaufwändiger Job, der ein geringes Risiko birgt (Ihre Einschätzung ist fehleranfällig) und zu keinem wesentlichen Geschäftserfolg führt.

2. Platzieren Sie die Protokollierung in diesem Codeabschnitt und sehen Sie, wie oft sie in der Praxis eingegeben wird. Nach einer ausreichenden Anzahl von Ausführungen sollten Sie sich darauf verlassen können, dass das Entfernen des Codes sicher ist.

Gibt es bessere Ideen oder so etwas wie einen kanonischen Ansatz?

In meiner perfekten Fantasiewelt, in der ich eine 100% ige Einheitentestabdeckung habe, lösche ich sie einfach, führe meine Einheitentests durch, und wenn kein Test rot wird, gebe ich sie ein.

Aber leider muss ich jeden Morgen aufwachen und mich der harten Realität stellen, in der viele Codes entweder keine Komponententests haben oder in denen man sich nicht darauf verlassen kann, dass sie wirklich jeden möglichen Randfall abdecken. Ich würde also das Risiko / den Gewinn in Betracht ziehen und zu dem Schluss kommen, dass es sich einfach nicht lohnt:

• Belohnung: Code ist in Zukunft etwas einfacher zu pflegen.
• Risiko: Brechen Sie den Code in einem undurchsichtigen Fall, an den ich nicht gedacht habe, verursachen Sie einen Vorfall, wenn ich ihn am wenigsten erwarte, und machen Sie Fehler, weil ich meine OCD-Codequalität erfüllen und eine Änderung ohne erkennbaren geschäftlichen Wert vornehmen musste an alle Stakeholder, die selbst kein Kodierer sind.

Dieser Prozess besteht aus zwei Hälften. Der erste bestätigt, dass der Code tatsächlich tot ist. Die zweite besteht darin, die Kosten für das Unrecht zu erfassen und sicherzustellen, dass sie angemessen gemindert werden.

Viele Antworten hier haben großartige Lösungen für die frühere Hälfte. Tools wie statische Analysegeräte eignen sich hervorragend zur Identifizierung von totem Code. grepkann in einigen Fällen dein Freund sein. Ein ungewöhnlicher Schritt, den ich oft unternehme, ist zu versuchen, den ursprünglichen Zweck des Codes zu identifizieren. Es ist viel einfacher zu argumentieren, dass "X nicht länger ein Merkmal unseres Produkts ist und das Codesegment Y das Merkmal X unterstützen soll", als zu sagen, "Ich sehe keinen Sinn für das Codesegment Y".

Die zweite Hälfte ist ein entscheidender Schritt, um zu entscheiden, ob Code entfernt werden soll. Sie müssen verstehen, welche Konsequenzen es hat, wenn die Antwort falsch ist. Wenn Menschen sterben, wenn Sie die falsche Antwort erhalten, achten Sie darauf! Vielleicht ist es ein guter Zeitpunkt, um zu akzeptieren, dass sich mit der Zeit Code Cruft entwickelt, und stattdessen zu versuchen, nicht mehr Cruft selbst zu schreiben. Wenn Menschen nicht sterben werden, fragen Sie sich, wie verzeihend Ihre Benutzer sind. Können Sie ihnen einen Hotfix senden, wenn Sie etwas kaputt gemacht haben und Ihre Kundenbeziehungen pflegen? Haben Sie ein Q & A-Team, das dafür bezahlt wird, solche Probleme zu finden? Diese Art von Fragen sind wichtig, um zu verstehen, wie sicher Sie sein müssen, bevor Sie die Löschtaste drücken.

In den Kommentaren wies rmun auf eine hervorragende Formulierung des Konzepts hin, den ursprünglichen Zweck des Codes zu verstehen, bevor er entfernt wird. Das Zitat ist jetzt als Chestertons Zaun bekannt . Obwohl es zu groß ist, um direkt in einem Kommentar zitiert zu werden, sollte es meiner Meinung nach hier richtig zitiert werden:

Bei der Reform der Dinge gibt es im Gegensatz zu ihrer Verformung ein einfaches Prinzip. Ein Prinzip, das wahrscheinlich als Paradox bezeichnet wird. In einem solchen Fall gibt es eine bestimmte Institution oder ein bestimmtes Gesetz. Lassen Sie uns der Einfachheit halber einen Zaun oder ein Tor über einer Straße errichten. Der modernere Reformertyp macht sich lustig und sagt: „Ich sehe keinen Sinn darin. Lassen Sie es uns wegräumen. “Worauf der intelligentere Reformertyp gut antworten kann:„ Wenn Sie die Verwendung nicht sehen, lasse ich Sie mit Sicherheit nicht wegräumen. Geh weg und denke nach. Dann, wenn Sie zurückkommen und mir sagen können, dass Sie den Gebrauch davon sehen, kann ich Ihnen erlauben, es zu zerstören.

Ich tendiere auch dazu, grepden Funktions- / Klassennamen im Code anzugeben, was einige zusätzliche Vorteile mit sich bringen kann, die eine Code-Analyse möglicherweise nicht bietet, beispielsweise wenn der Name in einem Kommentar, einer Dokumentationsdatei oder einem Skript erwähnt wird. Ich lasse grep auf den Akten im Quellbaum laufen und speichere das Resultat in einer Akte; In der Regel enthält das Ergebnis eine komprimierte Information: Dateiname / Pfad, Zeilennummer und die Zeile, in der der Name vorkommt. Dies kann Hinweise darauf geben, wo die Funktion / Klasse ohne semantische Bedeutung aufgerufen oder erwähnt wird (im Gegensatz zu einem Codeanalysator) ) und unabhängig von den Dateierweiterungen. Auf jeden Fall nicht die ultimative Lösung, aber eine schöne Ergänzung zu einer Analyse.

• Identifizieren Sie den Code, der tot aussieht (statische Analyse usw.).
• Fügen Sie für jeden Aufruf des angeblich toten Codes eine Protokollnachricht hinzu . Es ist einfach mit Funktionen / Methoden; Mit statischen Elementen wie Konstanten ist es schwieriger. Manchmal können Sie Code einfach als veraltet markieren, und die Laufzeit protokolliert automatisch eine Nachricht für Sie. Lassen Sie den Code ansonsten intakt.
  • Protokollieren Sie eine Nachricht, wenn das tote Modul geladen ist: Die meisten Sprachen haben die Möglichkeit, zum Ladezeitpunkt eine statische Initialisierung durchzuführen, die huckepack erfolgen kann.
  • Stellen Sie sicher , dass Ihre Log - Nachricht einen angemessenen Stack - Trace enthält, so dass Sie verstehen , was der angeblich tote Code genannt.
• Führen Sie den geänderten Code in all Ihren Testsuiten aus. Ihre Testsuiten sollten auch auf bestimmte Zeiten prüfen, z. B. Mitternacht, Viertel- oder Jahreswechsel. Sehen Sie sich die Protokolle an, und aktualisieren Sie Ihr Verständnis für den Tod. Beachten Sie, dass Unit-Tests möglicherweise speziell den toten Code testen, während keine anderen Unit-Tests und keine Integrationstests ihn berühren.
• Führen Sie den geänderten Code einige Wochen lang in der Produktion aus. Stellen Sie sicher, dass während dieses Zeitraums alle regelmäßigen Prozesse ausgeführt werden, z. B. die einmal im Monat durchgeführten ETL-Cron-Jobs.
• Schauen Sie sich die Protokolle an. Alles, was protokolliert wurde, ist nicht wirklich tot. Die transitive Schließung des Aufrufgraphen über den Rest des toten Code ist auch möglicherweise nicht tot, auch wenn es nicht aufgerufen wurde. Analysiere es. Möglicherweise sind einige Zweige sicher tot (z. B. die Arbeit mit einer API eines inzwischen ausgestorbenen Dienstes), andere noch nicht. Möglicherweise wird ein ganzes Modul / eine ganze Klasse nur für eine darin definierte Konstante geladen, und Sie können sie leicht wieder verwenden.
• Was übrig bleibt, ist sicher tot und kann entfernt werden.

Zusätzlich zu den bereits erwähnten Antworten können Sie den Code auch iterativ über mehrere Versionen hinweg entfernen.

In der anfänglichen Version konnten Sie eine Verfallswarnung ausführen, während der Codeblock noch funktionierte. In der darauf folgenden Version können Sie den Codeblock entfernen, aber eine Fehlermeldung hinterlassen, in der Benutzer die Funktion nicht mehr verwenden und nicht mehr verfügbar sind. In der endgültigen Version würden Sie den Codeblock und alle Nachrichten entfernen.

Dies kann helfen, unvorhergesehene Funktionen zu identifizieren, ohne die Endbenutzer zu warnen. Im besten Fall tut der Code wirklich nichts und alles, was passiert, ist, dass der nicht benötigte Code über mehrere Versionen hinweg aufbewahrt wird, bevor er entfernt wird.

Viele Leute schlagen vor, dass es "sicher" ist, den Code zu belassen, wenn man nicht nachweisen kann, dass er nicht verwendet wird.

Aber Code ist kein Aktivposten, sondern eine Verbindlichkeit.

Wenn Sie nicht erklären können, warum es wichtig ist, und auf seine Tests verweisen, besteht die "sicherere" Alternative möglicherweise darin, sie zu löschen.

Wenn Sie sich immer noch nicht sicher sind, fügen Sie mindestens Tests hinzu, um den Zombie-Code zu testen.

Mithilfe von Feature-Umschaltern können Sie den Ausführungspfad Ihrer Software ändern, um den betreffenden Code vollständig zu ignorieren.

Auf diese Weise können Sie Ihre Änderung mit dem nicht verwendeten Code und dem Deaktivieren sicher bereitstellen. Wenn Sie einige schwerwiegende Fehler im Zusammenhang mit dem Code feststellen, schalten Sie den Schalter wieder ein und untersuchen Sie den möglichen Pfad dazu.

Dieser Ansatz sollte Ihnen Sicherheit geben, wenn Sie über einen längeren Zeitraum hinweg keine Probleme feststellen und die Möglichkeit haben, ihn ohne Bereitstellung wieder in Betrieb zu nehmen. Ein noch besserer Weg wäre jedoch, eine zusätzliche Protokollierung und Testabdeckung für das betreffende Gebiet anzuwenden, was mehr Beweise liefert, ob es verwendet wird oder nicht.

Weitere Informationen zum Umschalten finden Sie hier: https://martinfowler.com/articles/feature-toggles.html

Statische Analyse natürlich ... und das Schöne ist, dass Sie keine neuen Werkzeuge benötigen; Ihr Compiler verfügt über alle statischen Analyse-Tools, die Sie benötigen.

Ändern Sie einfach den Namen der Methode (z. B. Ändern DoSomethingin DoSomethingX) und führen Sie dann einen Build aus.

Wenn Ihr Build erfolgreich ist, wird die Methode offensichtlich von nichts verwendet. Sicher zu löschen.

Wenn Ihr Build fehlschlägt, isolieren Sie die Codezeile, die ihn aufruft, und überprüfen Sie, welche ifAnweisungen den Aufruf umgeben, um zu bestimmen, wie er ausgelöst werden soll. Wenn Sie keinen möglichen Datenverwendungsfall finden, der ihn auslöst, können Sie ihn sicher löschen.

Wenn Sie wirklich Bedenken haben, den Code zu löschen, sollten Sie ihn behalten und ihn mit einem ObsoleteAttribute (oder einem in Ihrer Sprache gleichwertigen Attribut) kennzeichnen . Geben Sie es für eine Version so frei, und entfernen Sie den Code, nachdem keine Probleme in freier Wildbahn gefunden wurden.

• Ich würde anfangen, einen Code-Analysator zu verwenden, um zu überprüfen, ob dies toter Code ist
• Ich würde anfangen, meine Tests zu überprüfen und zu versuchen, den Code zu erreichen. Wenn ich den Code in einem Testfall nicht erreichen kann, ist er möglicherweise tot
• Ich würde den Code entfernen und stattdessen eine Ausnahme auslösen. Bei einem Release ist die Ausnahme aktiviert und bei dem zweiten Release kann die Ausnahme entfernt werden. Setzen Sie aus Sicherheitsgründen ein Notfall-Flag (in Java eine Systemeigenschaft), um den ursprünglichen Code zu aktivieren, wenn ein Kunde die Ausnahme bemerkt. So kann die Ausnahme deaktiviert und der ursprüngliche Code in einer Produktionsumgebung aktiviert werden.

Nicht erreichbaren Code entfernen

In einer prinzipiell statisch typisierten Sprache sollten Sie immer wissen, ob der Code tatsächlich erreichbar ist oder nicht: entfernen Sie ihn, kompilieren Sie ihn, wenn kein Fehler vorliegt, war er nicht erreichbar.

Leider sind nicht alle Sprachen statisch typisiert und nicht alle statisch typisierten Sprachen sind prinzipiell. Mögliche Fehler sind (1) Reflexion und (2) grundlose Überladung.

Wenn Sie eine dynamische Sprache oder eine Sprache mit ausreichend leistungsstarker Reflektion verwenden, sodass möglicherweise zur Laufzeit über Reflektion auf den untersuchten Code zugegriffen werden kann, können Sie sich nicht auf den Compiler verlassen. Zu diesen Sprachen gehören Python, Ruby oder Java.

Wenn Sie eine Sprache mit einer prinzipienlosen Überladung verwenden, kann durch das Entfernen einer Überladung die Überlastungsauflösung einfach stillschweigend auf eine andere Überlastung umgeschaltet werden. In einigen dieser Sprachen können Sie eine Warnung / einen Fehler zur Kompilierungszeit programmieren, die / der mit der Verwendung des Codes zusammenhängt. Andernfalls können Sie sich nicht auf den Compiler verlassen. Zu diesen Sprachen gehören Java (Verwendung @Deprecated) oder C ++ (Verwendung [[deprecated]]oder = delete).

Wenn Sie also nicht das große Glück haben, mit strengen Sprachen zu arbeiten (was Rust in den Sinn kommt), können Sie sich wirklich in den Fuß schießen, indem Sie dem Compiler vertrauen. Und leider sind Testsuiten in der Regel unvollständig, sodass auch nicht viel mehr geholfen werden kann.

Cue den nächsten Abschnitt ...

Entfernen von möglicherweise nicht verwendetem Code

Wahrscheinlicher ist, dass tatsächlich auf den Code verwiesen wird, Sie vermuten jedoch , dass in der Praxis die darauf verweisenden Codezweige niemals verwendet werden.

In diesem Fall ist der Code unabhängig von der Sprache nachweislich erreichbar und es kann nur die Laufzeitinstrumentierung verwendet werden.

In der Vergangenheit habe ich erfolgreich einen 3-Phasen-Ansatz zum Entfernen solchen Codes verwendet:

1. Protokollieren Sie auf jedem Zweig, von dem vermutet wird, dass er NICHT belegt ist, eine Warnung.
2. Nach einem Zyklus eine Ausnahme auslösen / einen Fehler bei der Eingabe des spezifischen Codes zurückgeben.
3. Löschen Sie nach einem weiteren Zyklus den Code.

Was ist ein Zyklus? Es ist der Zyklus der Verwendung des Codes. Zum Beispiel würde ich für eine finanzielle Bewerbung einen kurzen monatlichen Zyklus (mit Gehältern, die am Monatsende ausgezahlt werden) und einen langen jährlichen Zyklus erwarten. In diesem Fall müssen Sie mindestens ein Jahr warten, um sicherzustellen, dass keine Warnung ausgegeben wird, dass für das Inventar zum Jahresende Codepfade verwendet werden können, die ansonsten nie verwendet werden.

Hoffentlich haben die meisten Anwendungen kürzere Zyklen.

Ich empfehle, einen TODO-Kommentar mit einem Datum einzutragen und anzugeben, wann mit dem nächsten Schritt fortgefahren werden soll. Und eine Erinnerung in Ihrem Kalender.

Das Entfernen von Code aus der Produktion ist wie das Reinigen eines Hauses. In dem Moment, in dem Sie einen Gegenstand vom Dachboden wegwerfen, bringt Ihre Frau Sie am nächsten Tag um, weil Sie das Heimkehrgeschenk des dritten Neffen ihrer Urgroßmutter von ihrem 1923 verstorbenen Nachbarn weggeworfen haben.

Denken Sie ernsthaft daran, dass Sie nach einer kurzen Analyse mit verschiedenen Tools, die bereits von allen erwähnt wurden, und nach der Verwendung des bereits erwähnten Ansatzes der schrittweisen Abschreibung möglicherweise vom Unternehmen verschwunden sind, wenn die eigentliche Entfernung stattfindet. Es ist unerlässlich, den Code zu belassen und seine Ausführung protokollieren zu lassen und sicherzustellen, dass alle Warnungen bezüglich seiner Ausführung definitiv an Sie (oder Ihre Nachfolger und Beauftragten) übermittelt werden.

Wenn Sie diesen Ansatz nicht befolgen, werden Sie wahrscheinlich von Ihrer Frau getötet. Wenn Sie den Code behalten (wie jedes Andenken), können Sie sich darauf verlassen, dass Moores Gesetz zu Ihrer Rettung beiträgt und die Kosten für Speicherplatz, den der Code verbraucht, der sich wie ein "Stein in meinem Schuh" anfühlt, jeden verringern Jahr und Sie riskieren nicht, das Zentrum mehrerer Klatsch und seltsame Blicke in den Gängen des Wasserkühlers zu werden.

PS: Um als Antwort auf einen Kommentar zu klären ... Die ursprüngliche Frage lautet "Wie löscht man sicher ...". Natürlich wird in meiner Antwort die Versionskontrolle vorausgesetzt. Genau wie das Graben im Müll, um das Wertvolle zu finden, wird angenommen. Kein vernünftiger Körper wirft Code weg und die Versionskontrolle sollte Teil der Strenge eines jeden Entwicklers sein.

Das Problem betrifft Code, der möglicherweise überflüssig ist. Wir können niemals wissen, dass ein Teil des Codes überflüssig ist, es sei denn, wir können garantieren, dass 100% der Ausführungspfade ihn nicht erreichen. Und es wird angenommen, dass dies eine Software ist, die groß genug ist, dass diese Garantie so gut wie unmöglich ist. Und wenn ich die Frage nicht falsch lese, ist der gesamte Konversationsthread nur für Fälle relevant, in denen der entfernte Code aufgerufen wird und daher ein Laufzeit- / Produktionsproblem vorliegt. Die Versionskontrolle rettet niemanden, der aufgrund von Produktionsfehlern in Verzug ist. Daher ist der Kommentar zu "Versionskontrolle" nicht relevant für die Frage oder meinen ursprünglichen Punkt, dh über einen extrem langen Zeitraum hinweg wird die Versionskontrolle ordnungsgemäß abgelehnt, wenn Sie dies wirklich tun müssen.

IMHO ist der Kommentar überflüssig und ist ein Kandidat für die Entfernung.

Vielleicht ist der Compiler nicht feststellen , dass es einfach nicht viel Aufhebens machen.

Führen Sie einen Build mit vollständigen, auf die Größe ausgerichteten Compiler-Optimierungen aus. Löschen Sie dann den verdächtigen Code und führen Sie den Build erneut aus.

Vergleichen Sie die Binärdateien. Wenn sie identisch sind, hat der Compiler den Code bemerkt und unbemerkt gelöscht. Sie können es sicher aus der Quelle löschen.

Wenn die Binärdateien unterschiedlich sind ... dann ist es nicht schlüssig. Es könnte eine andere Veränderung sein. Einige Compiler enthalten sogar Datum und Uhrzeit der Kompilierung in der Binärdatei (und möglicherweise kann sie auch entfernt konfiguriert werden!).

Ich bin kürzlich auf genau diese Situation gestoßen, mit einer Methode namens "deleteFoo". Nirgendwo in der gesamten Codebasis wurde dieser String anders als in der Methodendeklaration gefunden, aber ich habe klugerweise eine Protokollzeile oben in der Methode geschrieben.

PHP:

public function deleteFoo()
{
    error_log("In deleteFoo()", 3, "/path/to/log");
}

Es stellt sich heraus, dass der Code verwendet wurde! Einige AJAX-Methoden rufen "method: delete, elem = Foo" auf, das dann verkettet und mit call_user_func_array () aufgerufen wird .

Wenn Sie Zweifel haben, melden Sie sich! Wenn Sie nicht genügend Zeit haben, ohne das Protokoll gefüllt zu sehen, sollten Sie den Code entfernen. Aber selbst wenn Sie den Code entfernen, belassen Sie das Login und einen Kommentar mit dem Datum, damit der Typ, der ihn warten muss, den Commit in Git leichter finden kann!

Verwenden Sie grepoder welche Tools Sie zuerst zur Verfügung haben, finden Sie möglicherweise Verweise auf den Code. (Ursprünglich nicht meine Anweisung / mein Rat.)

Entscheide dann, ob du riskieren willst, den Code zu entfernen, oder ob mein Vorschlag Verwendung finden könnte:

Sie können die Funktion / den Codeblock so ändern, dass er in eine Protokolldatei geschrieben wird. Wenn keine solche Meldung jemals in der Protokolldatei aufgezeichnet wurde, können Sie den Protokollierungscode wahrscheinlich entfernen.

Zwei Probleme:

1. Abrufen des Protokolls von anderen Benutzern. Vielleicht können Sie ein globales Flag setzen, das das Programm beim Beenden zum Absturz bringt, und den Benutzer bitten, Ihnen das Fehlerprotokoll zu senden.

2. Verfolgung des Anrufers. In einigen höheren Sprachen (z. B. Python) können Sie problemlos einen Traceback erhalten. In kompilierten Sprachen müssen Sie jedoch die Absenderadresse im Protokoll speichern und beim Beenden einen Core-Dump erzwingen (Punkt 1).
   In C sollte dies recht einfach sein: Verwenden Sie einen bedingten Block (z. B. #ifdef ... #endif), um dies nur zu verwenden, wenn Sie wissen, dass es funktioniert (und getestet haben, dass es funktioniert), und lesen Sie einfach die Rücksprungadresse aus dem Stapel (möglicherweise oder möglicherweise nicht Inline-Assemblersprache erforderlich).

Das Speichern der Argumente in der Protokolldatei kann nützlich sein oder auch nicht.

Wenn Sie wissen, was der umgebende Code bewirkt, testen Sie ihn, um festzustellen , ob er fehlerhaft ist. Dies ist die einfachste und kostengünstigste Möglichkeit, einen Code, an dem Sie arbeiten, umzugestalten, und sollte auf jeden Fall durchgeführt werden, um Änderungen am Code zu entwickeln, an dem Sie gerade arbeiten.

Wenn Sie andererseits einen Code umgestalten, bei dem Sie nicht wissen, was er tut, entfernen Sie ihn nicht . Verstehe es zuerst und überarbeite es dann, wenn du feststellst, dass es sicher ist (und nur, wenn du feststellen kannst, dass das Überarbeiten eine angemessene Nutzung deiner Zeit ist).

Nun, es könnte einige Umstände geben (ich weiß, dass ich selbst darauf gestoßen bin), unter denen der Code, der "tot" ist, tatsächlich mit nichts verbunden ist . Zum Beispiel von einem Auftragnehmer entwickelte Codebibliotheken, die nirgendwo implementiert wurden, weil sie unmittelbar nach der Bereitstellung der App veraltet waren (warum ja, ich habe ein bestimmtes Beispiel im Sinn, woher wussten Sie das?).

Ich persönlich habe den gesamten Code entfernt, aber es ist ein großes Risiko, dass ich nicht empfehle, ihn auf die leichte Schulter zu nehmen - abhängig davon, wie viel Code sich diese Änderung möglicherweise auf Sie auswirken könnte (da immer das Potenzial besteht, dass Sie etwas übersehen haben) sollten außerordentlich vorsichtig sein und aggressive Unit-Tests durchführen, um festzustellen, ob das Entfernen dieses alten Legacy-Codes Ihre Anwendung beschädigt.

Trotzdem lohnt es sich wahrscheinlich nicht , den Code so zu entfernen. Nicht, wenn es ein ernstes Problem mit Ihrer Anwendung wird (z. B. weil die Sicherheitsscans aufgrund aufgeblähter Anwendungen nicht abgeschlossen werden können ... warum ja, ich habe immer noch ein Beispiel im Sinn), daher würde ich es nur empfehlen, wenn Sie dies erreichen Eine solche Situation, in der der Code wirklich auf eine wirkungsvolle Weise zu faulen begonnen hat.

Kurz gesagt: Wenn Sie wissen, was der Code bewirkt, testen Sie ihn zuerst. Wenn Sie dies nicht tun, können Sie es wahrscheinlich in Ruhe lassen. Wenn Sie wissen, dass Sie es nicht alleine lassen können, widmen Sie Ihre Zeit dem aggressiven Testen der Änderung, bevor Sie die Änderung implementieren.

Mein Ansatz, den ich in diesem Fall immer als Industriestandard angenommen habe, wurde bisher komischerweise nicht erwähnt:

Holen Sie sich ein zweites Paar Augen.

Es gibt verschiedene Arten von "unbenutztem Code", und in einigen Fällen ist das Löschen angebracht, in anderen Fällen sollten Sie eine Umgestaltung vornehmen, und in anderen Fällen rennen Sie so weit wie möglich davon und schauen niemals zurück. Sie müssen herausfinden, um welches es sich handelt und am besten mit einem erfahrenen zweiten Partner zusammenarbeiten! - Entwickler, der mit der Codebasis sehr vertraut ist. Dadurch wird das Risiko eines unnötigen Fehlers erheblich verringert, und Sie können die erforderlichen Verbesserungen vornehmen, um die Codebasis in einem wartbaren Zustand zu halten. Und wenn Sie dies nicht tun, werden Ihnen irgendwann die Entwickler ausgehen, die mit der Codebasis sehr vertraut sind.

Ich habe auch den Protokollierungsansatz gesehen - genauer gesagt, ich habe den Protokollierungscode gesehen: noch mehr toten Code, der 10 Jahre dort belassen wurde. Der Protokollierungsansatz ist recht anständig, wenn Sie über das Entfernen ganzer Features sprechen, aber nicht, wenn Sie nur einen kleinen Teil des toten Codes entfernen.

Die einfache Antwort auf Ihre Frage lautet, dass Sie nicht verstandenen Code nicht sicher löschen können. Dazu gehört auch, dass Sie nicht verstehen, wie er aufgerufen wird. Es besteht ein gewisses Risiko.

Sie müssen beurteilen, wie Sie dieses unvermeidbare Risiko am besten mindern können. Andere haben die Protokollierung erwähnt. Das Protokollieren kann natürlich beweisen, dass es verwendet wird, kann aber nicht beweisen, dass es nicht verwendet wird. Da das Hauptproblem bei totem Code darin besteht, dass er gewartet wird, können Sie möglicherweise einen Kommentar hinzufügen, der besagt, dass es sich vermutlich um toten Code handelt, und keine Wartungsarbeiten daran vornehmen.

Wenn sich der Code in der Quellcodeverwaltung befindet, können Sie immer herausfinden, wann er hinzugefügt wurde, und bestimmen, wie er dann aufgerufen wurde.

Letztendlich verstehst du es entweder, lässt es in Ruhe oder nutzt eine Chance.

Falls der Entwickler des fraglichen Codes noch verfügbar ist, überprüfen Sie die Entfernung des Codes mit ihm . Außerdem lesen Kommentare im Code .

Sie erhalten die richtige Erklärung, warum dieser Code hinzugefügt wurde und für welche Funktion er dient. Es kann leicht eine Unterstützung für den spezifischen Anwendungsfall sein, oder Sie verfügen möglicherweise nicht über genügend Fachwissen, um beurteilen zu können, ob dies wirklich nicht erforderlich ist. Im Extremfall kann es vorkommen, dass alle freien Anweisungen aus einem C-Programm entfernt werden und nichts Falsches bemerkt wird (es kann einige Minuten dauern, bis der Speicher voll ist).

Es ist wirklich eine schlechte Kultur, wenn der Autor des Codes neben Ihnen sitzt, aber Sie sehen keinen Grund zum Reden, weil Sie sicher sind, dass er nur schlechten Code schreibt und Ihr Code alles so perfekt ist. Und natürlich schreibt er nur zufällige Wörter in die Kommentare, ohne Zeit mit Lesen zu verschwenden.

Einer der wichtigsten Gründe, einen Kommentar in den Code zu schreiben, besteht darin, zu erklären, warum er auf diese Weise implementiert wurde. Sie können mit der Lösung nicht einverstanden sein, aber Sie müssen das Problem berücksichtigen.

Eine Diskussion mit dem Autor kann auch ergeben, dass der Code der historische Rest von etwas ist, das entfernt oder nie fertiggestellt wurde, und daher sicher gelöscht werden kann.

Ich stimme dem ersten Punkt von Markus Lausberg voll und ganz zu: Der Code sollte unbedingt mit Hilfe von Tools analysiert werden. Affengehirne sind mit dieser Art von Aufgabe nicht zu trauen !!

Die meisten Standard-Programmiersprachen können in IDEs verwendet werden, und jede IDE, die es wert ist, aufgerufen zu werden, verfügt über ein "Find for all Usages" -Feature, das genau das richtige Werkzeug für diese Art von Situation ist. (Strg + Umschalt + G in Eclipse zum Beispiel)

Natürlich: Statische Analysewerkzeuge sind nicht perfekt. Man muss sich komplizierterer Situationen bewusst sein, in denen die Entscheidung, dass die fragliche Methode aufgerufen wird, erst zur Laufzeit und nicht früher erfolgt (Aufrufe über Reflection, Aufrufe zu "eval" -Funktionen in Skriptsprachen usw.).

Zwei Möglichkeiten:

1. Sie haben eine Testabdeckung von über 99% : Löschen Sie den Code und machen Sie es fertig.
2. Sie haben keine vertrauenswürdige Testabdeckung: Dann müssen Sie eine Warnung vor Verfall hinzufügen . Das heißt, Sie fügen diesem Ort Code hinzu, der etwas Vernünftiges bewirkt (protokollieren Sie eine Warnung an einem gut sichtbaren Ort, der beispielsweise nicht mit der täglichen Nutzung Ihrer Anwendung in Konflikt steht). Dann einige Monate / Jahre köcheln lassen. Wenn Sie nie ein Vorkommen davon gefunden haben, ersetzen Sie die Veraltetheit durch etwas, das eine Ausnahme auslöst. Lass das eine Weile stehen. Schließlich entfernen Sie alles vollständig.