it-swarm.com.de

Sollte ich nicht referenzierten Code entfernen?

Ich arbeite an einer mittelgroßen Codebasis (100.000 Zeilen), alles ist relativ neuer Code (weniger als ein Jahr alt) und hat eine gute Abdeckung durch Unit-Tests.

Ich stoße immer wieder auf Methoden, die entweder nirgendwo mehr verwendet werden oder nur in Komponententests referenziert werden, die nur diese bestimmte Methode testen.

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

Gründe, es zu entfernen :

  • Weniger Code, weniger Fehler
  • 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 irgendwann nützlich sein
  • Es wurde möglicherweise geschrieben, um die Funktionalität für eine Klasse abzurunden
121
Simon Hutton

Die meisten Ihrer Gründe, es zu behalten, sind 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 dem angegeben ist, in welcher Revision Sie ihn finden möchten.

Ganz einfach: Je früher Sie den Code schneiden, desto schneller müssen Sie keine Zeit damit verschwenden, ihn zu warten, zu kompilieren und zu testen. Diese Vorteile überwiegen massiv die von Ihnen beschriebenen trivialen Vorteile, die ohnehin aus der Quellcodeverwaltung abgeleitet werden können.

220
DeadMG

Alle Gründe, es zu entfernen, stehen.

Gründe, es zu behalten:

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

Alle diese Gründe für die Beibehaltung werden von der Quellcodeverwaltung verwaltet. Wenn Sie es aus dem Live-Code entfernen, können Sie es bei Bedarf abrufen.

43
StuperUser

Nicht referenzierter Code ist dasselbe wie das Halten der 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, dass Sie sie aus dem Live-Code entfernen und den Versionsverlauf verwenden, falls sich herausstellt, dass er nützlich ist.

23
Nicholas Smith

Der einzige gute Grund, warum ich Code behalten kann, der derzeit nicht verwendet wird, ist, wenn er Teil eines in sich geschlossenen Moduls ist: Während einige Teile des Codes derzeit möglicherweise nicht verwendet werden, kann es durchaus sein, dass dies der Fall ist in der Zukunft verwendet.

Dies gilt insbesondere für eine Bibliothek, die Sie projektübergreifend verwenden: Sie möchten nicht immer wieder Codeteile ein- und auswerfen, je nachdem, was Sie für ein bestimmtes Projekt benötigen: Ich finde dies zeitaufwändig 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 bei der zweiten Verwendung an. (3) Wenn Sie es mehr als zweimal verwenden, erstellen Sie daraus ein genau definiertes, stabiles Modul und verwenden Sie dieses Modul nach Bedarf.

Zusammenfassend: Ich würde den gesamten nicht verwendeten Code wegwerfen, es sei denn, er ist Teil eines Allzweckmoduls, das Sie als solches entworfen haben und von dem Sie wissen, dass Sie es 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 Projekten hinzuzufügen.

15
Giorgio

Im Allgemeinen würde ich mich diesbezüglich vor YAGNI verneigen. Wenn "Sie es nicht brauchen", nimmt es einfach Platz in Ihrer Codebasis, in Unit-Tests und in Assemblys ein. Möglicherweise benötigen Sie es, aber Sie müssen es möglicherweise auch komplett neu schreiben, da sich zwischen jetzt und dem Zeitpunkt, an dem Sie so etwas benötigen, viel ändern kann.

Dies ändert sich jedoch etwas, wenn Sie ein Dienstprogramm oder eine API für den allgemeinen Gebrauch schreiben. So wie Sie niemals erwarten können, dass Software-Endbenutzer so mit der Software interagieren, wie Sie es beabsichtigt haben, können Sie niemals erwarten, dass Verbraucher Ihres Codes Ihren Code genau so verwenden möchten, wie Sie es sich vorstellen. In solchen Fällen sollte es wahrscheinlich funktionieren, solange Sie die Existenz einer Methode mit "Es ist eine gültige Möglichkeit, mit meinem Objekt interagieren zu wollen" rechtfertigen können, denn selbst wenn Sie sie nicht benötigen, stehen die Chancen gut, dass JEMAND dies tut .

11
KeithS

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

Für Teile, die an erster Stelle 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 daran erinnern, dass sie existieren - wenn sie sagen "Sie können es einfach in der Quellcodeverwaltung finden", setzen Sie voraus, dass Sie wissen/sich daran erinnern, dass es da ist! In solchen Fällen sollten Sie eine Ablehnung (mit einem Showstopper "assert (false)") oder ein Auskommentieren in Betracht ziehen.

8
Ed Staub

"Kann als Referenz verwendet werden" Ich würde nicht zustimmen, ein guter Grund zu sein, unbenutzten Code zu belassen. 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 im Verlauf der Versionskontrolle nach xy oder z suchen, um herauszufinden, wer die vorherige Version sein 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 auskommentiert werden, wann er entfernt wurde und warum er nicht einfach aus dem Code gelöscht wurde. Dies wird jedoch im Allgemeinen als schlechter Stil angesehen, und Code, der nicht ordnungsgemäß verwendet und nicht ordnungsgemäß gewartet wird, kann alle Arten von Fehlern verursachen, wenn er später nicht kommentiert wird. Dies ist daher im Allgemeinen besser als vorübergehender Debugging-/Testschritt während des Refactorings als eine Möglichkeit, Produktionscode zu verlassen.

Meine bevorzugte Art, den gelöschten Code zu speichern, wenn er in Zukunft nützlich erscheint, besteht darin, ein sekundäres Referenzdokument zu erstellen, das alle verschiedenen Teile des lohnenden gelöschten Codes enthält. Jeder Codeblock ist mit einer kurzen Erwähnung versehen, woher er stammt oder was sonst noch wichtig ist, z. B. wann er entfernt wurde oder unter welcher Versionsnummer 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, um es fortlaufend zu warten und zu testen (dieses Testen wird auf den Punkt verschoben, an dem der Code erneut eingeführt wird).

3
Jessica Brown

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

Für interessante Codekadaver verwende ich in meinen Versionskontrollsystemen einen archive -Zweig.

3
phresnel

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

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

2
davorp

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 schon lange in Produktion ist, nur um herauszufinden, dass sie nicht tatsächlich verwendet wurde mehrere Jahre. Code, der nicht verwendet wird, wird nicht verwaltet, und obwohl er möglicherweise vor Jahren funktioniert hat, hat sich die API um ihn herum so geändert, dass Sie ihm nicht vertrauen können.

Bestenfalls 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 von einem bösen Fehler gebissen werden und es länger dauert, ihn aufzuspüren, da Sie davon ausgegangen sind, dass der "produktionsgeprüfte" 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, ist es genau dort in der Quellcodeverwaltung. Wenn Sie es erst brauchen, wenn so viel Zeit vergangen ist, dass Sie sich nicht daran erinnern, dass es sich um eine Quellcodeverwaltung handelt, ist es wahrscheinlich besser, es von Grund auf neu zu schreiben.

1
Karl Bielefeldt

Nichts verbraucht weniger Zeit als kein Code.

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

Ok - dies könnte durch einen Kommentar geheilt werden, aber andererseits wird jeder darüber nachdenken, warum sich dieser nicht verwendete Code noch in der Codebasis befindet, ob er entfernt werden sollte oder nicht.

Wenn es nichts gibt, wird niemand Zeit damit verlieren.

Wenn es schwierig war, es richtig zu machen, benötigen Sie eine gute Dokumentation, dass dieser Code vorhanden ist. Wenn sich die Codebasis jedoch über einige Iterationen hinweg entwickelt, funktioniert sie möglicherweise nicht mehr, wenn sie reaktiviert wird.

1
user unknown

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

Lange Kommentare des alten Codes lenken ab und erschweren die Navigation.

Grüße

1
Luca Botti

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 für die Entfernung sind gültig.

Alle Ihre Punkte für die Beibehaltung der Unordnung sind ungültig, sobald Sie ein SCM haben, um es nachzuschlagen oder wiederherzustellen. Eigentlich 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.

1
haylem

Wenn Sie ein Versionskontrollsystem verwenden, machen Sie sich keine Sorgen über zukünftige Referenzen, 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 werden würde, lassen Sie es einfach dort bleiben, aber kommentieren Sie es mit einer Beschreibung, die erklärt, warum es kommentiert wird.

Wenn Sie jedoch sicher sind, dass Sie es in Zukunft nicht mehr verwenden werden, einfach entfernen Sie es. Ich denke, die Gründe, die Sie erwähnt haben, sind ziemlich einfach für das Entfernen des Codes.

Stellen Sie jedoch vor dem Entfernen sicher, dass es nirgendwo verwendet wird. Visual Studio verfügt über eine Funktion namens Alle Referenzen suchen, die die gesamte Lösung durchsucht und Verweise auf die aktuelle Variable, Methode, Eigenschaft, Klasse, Schnittstelle usw. findet. Ich stelle immer sicher, dass keine Verweise vorhanden sind bevor Sie einen Teil meines Codes entfernen.

1
Saeed Neamati

Nach meiner Erfahrung kann das Entfernen von nicht verwendetem Code ebenfalls nach hinten losgehen. Möglicherweise vergessen Sie, dass Sie diesen Code hatten, und Sie werden ihn in der Geschichte nicht suchen. Oder Sie wissen möglicherweise nicht einmal, dass jemand diesen Code implementiert und später entfernt hat. Auch hier werden Sie in der Geschichte nicht danach suchen ...

Kein Zweifel, unbenutzter Code ist ein schlechter Geruch.

PDATE : Ich habe gerade bemerkt, dass Ed Staub eine sehr ähnliche Antwort gegeben hat.

0
Ali

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 jedoch, den Code irgendwann öffentlich zu machen, und andere möchten möglicherweise diese grundlegende Funktionalität. Entwerfen Sie dann einfach Tests, um sicherzustellen, dass diese Teile des Codes funktionieren, die nachahmen, wie Sie vorschlagen, dass andere diese Teile des Codes verwenden. Wenn Sie jedoch überhaupt in Betracht ziehen, den Code zu löschen, und keinen soliden Grund finden, ihn beizubehalten, sollte er funktionieren. Nicht verwendeter Code macht mehr Arbeit für alle (schwieriger, den Code zu lesen; der Code ist möglicherweise defekt; mehr Arbeit zu warten usw.)

0
dr jimbob