Sollte ich nicht referenzierten Code entfernen?

Ich arbeite an einer mittelgroßen Codebasis (100.000 Zeilen), die allesamt relativ neuen Code enthält (weniger als ein Jahr alt) und eine gute Abdeckung durch Komponententests aufweist.

Ich stoße immer wieder auf Methoden, die entweder nirgendwo mehr verwendet werden oder auf die nur in Komponententests verwiesen wird, in denen nur diese bestimmte Methode getestet wird.

Sollte ich diesen Code entfernen, wenn ich sicher bin, dass er nicht mehr benötigt wird?

Gründe, es zu entfernen:

• Weniger Code, weniger Bugs
• Weniger Code ist für andere leichter zu verdauen
• Es ist immer noch unter Quellcodeverwaltung

Gründe, es zu behalten:

• Kann als Referenz verwendet werden
• Es kann manchmal nützlich sein
• Es wurde möglicherweise geschrieben, um die Funktionalität für eine Klasse abzurunden

Die meisten Ihrer Gründe, es zu behalten, sind schlicht und einfach irrelevant. Wenn der Code nicht verwendet wird, werfen Sie ihn weg - jeder Vorteil, der mit seiner Aufbewahrung verbunden ist, kann trivial aus der Quellcodeverwaltung abgeleitet werden. Hinterlassen Sie höchstens einen Kommentar, in der angegeben ist, in welcher Revision sie gefunden werden soll.

Ganz einfach: Je früher Sie den Code schneiden, desto schneller müssen Sie ihn nicht warten, kompilieren und testen. Diese Vorteile überwiegen massiv die von Ihnen beschriebenen geringfügigen Vorteile, die sich ohnehin aus der Quellcodeverwaltung ableiten lassen.

Alle Gründe, es zu entfernen, stehen.

Gründe, es zu behalten:

• Kann als Referenz verwendet werden
• Es kann manchmal nützlich sein
• Es wurde möglicherweise geschrieben, um die Funktionalität für eine Klasse abzurunden

Alle diese Gründe werden von der Quellcodeverwaltung verwaltet. Entfernen Sie es aus dem Live-Code und Sie können es bei Bedarf abrufen.

Nicht referenzierter Code ist das Gleiche wie das Aufbewahren von Batterien, die irgendwie leer sind, nur für den Fall, dass Sie sie eines Tages für eine Taschenlampe benötigen.

Solange Sie eine Art Versionskontrolle verwenden, würde ich sagen, entfernen Sie sie aus dem Live-Code und verwenden Sie das Versionsprotokoll, falls es sich als nützlich herausstellt.

Der einzige gute Grund, warum ich sehe, dass Code, der derzeit nicht verwendet wird, beibehalten wird, ist, dass er Teil eines eigenständigen Moduls ist: Einige Teile des Codes werden möglicherweise momentan nicht verwendet, es kann aber durchaus sein, dass sie verwendet werden in der Zukunft verwendet.

Dies trifft insbesondere auf eine Bibliothek zu, die Sie projektübergreifend verwenden: Sie möchten nicht ständig Code-Teile ein- und auslagern, je nachdem, was Sie für ein bestimmtes Projekt benötigen. Ich finde dies zeitaufwendig und fehleranfällig.

Mein Ansatz ist: (1) Wenn Sie es einmal verwenden, behalten Sie nur das, was Sie wirklich brauchen; (2) Wenn Sie es zweimal verwenden, kopieren Sie es und passen Sie es an, wenn Sie es das zweite Mal verwenden. (3) Wenn Sie es mehr als zweimal verwenden, erstellen Sie ein genau definiertes, stabiles Modul und verwenden Sie dieses Modul nach Bedarf.

Zusammenfassend: Ich würde nicht verwendeten Code wegwerfen, es sei denn, er ist Teil eines Universalmoduls, das Sie als solches entworfen haben und von dem Sie wissen, dass Sie ihn mehrmals wiederverwenden werden.

Hinweis : Eine noch sauberere Lösung wäre natürlich, ein separates Projekt für eine Bibliothek zu erstellen und eine Abhängigkeit zwischen den Projekten hinzuzufügen.

Generell würde ich mich bei YAGNI verneigen. Wenn "Sie es nicht brauchen", beansprucht es einfach Platz in Ihrer Codebasis, in Unit-Tests und in Assemblys. Vielleicht brauchen Sie es, aber Sie müssen es auch komplett umschreiben, denn bis dahin kann sich vieles ändern, wenn Sie etwas Ähnliches brauchen.

Dies ändert sich jedoch etwas, wenn Sie ein Dienstprogramm oder eine API für den allgemeinen Gebrauch schreiben. Genauso wie Sie niemals erwarten können, dass Software-Endbenutzer in der von Ihnen beabsichtigten Weise mit der Software interagieren, können Sie auch niemals erwarten, dass die Benutzer Ihres Codes Ihren Code genau so verwenden möchten, wie Sie es sich vorstellen. Solange Sie die Existenz einer Methode mit "Es ist eine gültige Möglichkeit, mit meinem Objekt zu interagieren" begründen können, sollte dies in solchen Fällen wahrscheinlich geschehen, denn selbst wenn Sie es nicht benötigen, ist die Wahrscheinlichkeit groß, dass JEMAND dies tut .

Angesichts der Tatsache, dass die Codebasis weniger als ein Jahr alt ist, ist sie wahrscheinlich immer noch in Bewegung (ja?) - daher ist die Vorstellung, dass einige Bits in naher Zukunft wiederbelebt werden müssen, nicht unangemessen.

Für Teile, die anfangs schwer zu finden waren und mit größerer Wahrscheinlichkeit wiederbelebt werden, würde ich sie ein bisschen "lebendiger" halten als nur in der Quellcodeverwaltung. Leute werden nicht wissen / sich erinnern, dass sie existieren - "Sie können es nur in der Quellcodeverwaltung finden" setzt voraus, dass Sie wissen / sich erinnern, dass es da ist! Betrachten Sie in solchen Fällen die Nichtbeachtung (mit einem "assert (false)" - Showstopper) oder das Auskommentieren.

Wenn der Code trivial und uninteressant ist, schmeiße ich ihn einfach weg, um unnötige Trägheit des Softwaresystems zu beseitigen.

Für interessante Code-Leichen verwende ich eine archiveVerzweigung in meinen Versionskontrollsystemen.

"Kann als Referenz verwendet werden" Ich bin nicht der Meinung, dass dies ein guter Grund ist, nicht verwendeten Code zu verwenden. Oft zeigt nur ein kleiner Teil des nicht verwendeten Codes tatsächlich etwas Interessantes. Es gibt mehrere Möglichkeiten, nützlichen, aber nicht verwendeten Code zu dokumentieren und zu speichern.

Obwohl die Versionskontrolle einen Verlauf enthält, mit dem Sie bestimmte Funktionen problemlos wiederherstellen können, wenn Sie später entscheiden, dass der Code benötigt wird, müssen Sie den Versionskontrollverlauf durchsehen, um xy oder z zu ermitteln, von wem die vorherige Revision stammen kann ein bisschen langweilig und wird oft übersehen, es sei denn, Sie haben eine ziemlich genaue Vorstellung davon, wonach Sie suchen.

Der Code konnte mit einem Hinweis darauf, wann er entfernt wurde und warum er nicht einfach aus dem Code gelöscht wurde, auskommentiert werden. Dies wird jedoch im Allgemeinen als schlechter Stil angesehen, und Code, der nicht verwendet und nicht ordnungsgemäß gewartet wird, kann alle Arten von Fehlern hervorrufen, wenn er später nicht kommentiert wird. Daher ist dies im Allgemeinen besser als vorübergehender Debug- / Testschritt während des Refactorings als eine Möglichkeit, den Produktionscode zu verlassen.

Meine Lieblingsmethode zum Speichern des gelöschten Codes besteht darin, ein sekundäres Referenzdokument zu erstellen, das alle verschiedenen Teile des lohnenswerten gelöschten Codes enthält, sofern dies in Zukunft sinnvoll erscheint. Jeder Codeblock ist mit einem kurzen Vermerk versehen, woher er stammt oder was sonst noch zu merken ist, z. B. wann er entfernt wurde oder die Revisionsnummer, unter der er zuletzt im Code war. Alles, was entfernt wurde, aber "potenziell nützlich" ist, befindet sich an einem Ort, ist leicht zu durchsuchen, erfordert jedoch keinen ständigen Aufwand für die Wartung und den fortlaufenden Test (dieser Test wird auf jeden Punkt verschoben, an dem der Code erneut eingeführt wird).

Ein guter Grund, die nicht verwendeten Methoden beizubehalten, ist , dass sie für andere Zweige / Tags verwendet werden können!

Durchsuchen Sie alle aktiven Zweige und Tags, bevor Sie sie entfernen.

Wenn Sie ein Versionskontrollsystem verwenden, machen Sie sich keine Gedanken über zukünftige Verweise, da Sie einfach den Verlauf dieses Codes durchsehen und den gelöschten Teil finden können. Wenn Sie dies nicht tun und glauben, dass es eines Tages verwendet wird, lassen Sie es einfach dort stehen, aber kommentieren Sie es mit einer Beschreibung, in der erläutert wird, warum es kommentiert wird.

Wenn Sie jedoch sicher sind, dass Sie es in Zukunft nicht mehr verwenden werden, entfernen Sie es einfach . Ich denke, die Gründe, die Sie erwähnt haben, sind ziemlich einfach, damit der Code entfernt wird.

Aber bitte stellen Sie vor dem Entfernen sicher, dass es nirgendwo verwendet wird. Visual Studio verfügt über die Funktion Alle Verweise suchen, die die gesamte Lösung durchsucht und Verweise auf die aktuelle Variable, Methode, Eigenschaft, Klasse, Schnittstelle usw. findet. Ich stelle immer sicher, dass kein Verweis vorhanden ist, bevor ich einen Teil meines Codes entferne.

Ich habe relativ häufig die Erfahrung gemacht, eine Funktion zu finden, die genau das tut, was ich brauche, und darauf zu vertrauen, dass sie funktioniert, da sie seit langer Zeit in Produktion ist, nur um herauszufinden, dass sie in Wirklichkeit nicht verwendet wurde mehrere Jahre. Code, der nicht verwendet wird, wird nicht beibehalten, und obwohl er vor Jahren möglicherweise funktioniert hat, hat sich die API rundum so geändert, dass Sie ihm nicht vertrauen können.

Im besten Fall verbringen Sie viel Zeit damit, sicherzustellen, dass es tatsächlich immer noch das tut, was Sie wollen. Im schlimmsten Fall scheint es zu funktionieren, bis Sie später mit einem bösen Fehler gebissen werden, und es dauert länger, bis Sie ihn finden, da Sie davon ausgegangen sind, dass der "produktionstestete" Code funktioniert, sodass das Problem an einer anderen Stelle in Ihrem neuen Code liegen muss. Nach meiner Erfahrung ist es fast immer schneller, selbst eine neue Funktion zu schreiben.

Wenn Sie es löschen, aber relativ bald herausfinden, dass Sie es tatsächlich benötigen, befindet es sich genau dort in der Quellcodeverwaltung. Wenn Sie es nicht benötigen, bis so viel Zeit verstrichen ist, dass Sie sich nicht daran erinnern, dass es sich in der Quellcodeverwaltung befindet, ist es wahrscheinlich besser, es von Grund auf neu zu schreiben.

Nichts kostet weniger Zeit als kein Code.

Wenn Sie in eine Codebasis eintauchen müssen, brauchen Sie einige Zeit, um herauszufinden, wofür dieser Code verwendet wird, und wenn er für nichts verwendet wird, brauchen Sie noch mehr Zeit.

Ok - das könnte ein Kommentar sein, aber andererseits wird jeder darüber nachdenken, warum sich dieser unbenutzte Code noch in der Codebasis befindet, ob er entfernt werden soll oder nicht.

Wenn es nichts gibt, wird niemand Zeit damit verlieren.

Wenn es schwierig war, es richtig zu machen, brauchen Sie eine gute Dokumentation, dass dieser Code existiert, aber wenn sich die Codebasis über einige Iterationen entwickelt, funktioniert sie möglicherweise nicht mehr, wenn sie reaktiviert wird.

Entfernen Sie nicht verwendeten Code - weniger Unordnung, besseres Verständnis. Ihr Versionskontrollsystem wird sich darum kümmern. Wenn Sie etwas Besseres als Notepad verwenden, können Sie in Ihrer Umgebung älteren Code als Referenz verwenden.

Lange Kommentare zu altem Code lenken ab und erschweren das Navigieren.

Grüße

Folgen Sie diesem einfachen Algorithmus:

1. Wird es in einem SCM gesichert? Wenn ja, springen Sie zu 3.
2. Richten Sie ein SCM ein.
3. Wirf das Zeug weg .

Alle Ihre Punkte zugunsten der Entfernung sind gültig.

Alle Ihre Punkte für die Aufrechterhaltung der Unordnung sind ungültig, sobald Sie über ein SCM verfügen, um es nachzuschlagen oder wiederherzustellen. Tatsächlich sollte Ihr SCM Ihnen helfen können, festzustellen, warum dieser Code hier ist und nicht verwendet wird, wenn er ordnungsgemäß verwendet wurde.

Es heißt aus einem bestimmten Grund "toter Code". Lass es sterben und ruhe in Frieden.

Es bleibt in der Quellcodeverwaltung; Es sollte nicht in der aktiven Codebasis bleiben.

Die einzige Ausnahme ist, wenn der Code das Design vervollständigt und Sie den Code nicht verwenden, planen Sie, den Code irgendwann zu veröffentlichen, und andere möchten möglicherweise diese grundlegende Funktionalität. Entwerfen Sie dann einfach Tests, um sicherzustellen, dass diese Teile des Codes so funktionieren, wie Sie es anderen vorschlagen, und verwenden Sie diese Teile des Codes. Wenn Sie jedoch sogar überlegen, den Code zu löschen, und keinen stichhaltigen Grund haben, ihn beizubehalten, sollte er funktionieren. Nicht verwendeter Code macht mehr Arbeit für alle (schwerer zu lesen; der Code ist möglicherweise fehlerhaft; mehr zu wartender Code usw.)

Nach meiner Erfahrung kann das Entfernen von nicht verwendetem Code ebenfalls fehlschlagen. Sie können vergessen, dass Sie diesen Code hatten, und Sie werden ihn in der Historie nicht suchen. Oder Sie wissen nicht einmal, dass jemand diesen Code implementiert und später wieder entfernt hat. Auch in der Geschichte werden Sie nicht danach suchen ...

Ohne Zweifel ist es ein übler Geruch, unbenutzten Code zu haben.

UPDATE: Mir ist gerade aufgefallen, dass Ed Staub eine sehr ähnliche Antwort gegeben hat.