Ist es eine schlechte Praxis, redundante Dateien nicht sofort aus VCS zu löschen, sondern sie zuerst mit Kommentaren als "Zu löschen" zu markieren?

Ich wollte wissen, ob die Art und Weise, wie ich mit Quelldateien umgehe, die aus der Versionskontrolle gelöscht werden müssen, als schlechte Praxis angesehen werden kann.

Ich möchte es Ihnen anhand dieses Beispiels erklären:

Vor kurzem wurde ich sehr wütend, weil ich mühsam Java-Klassen in einem Programm aussortieren musste, das im Grunde toter Code war, der jedoch nirgends dokumentiert und in diesen Java-Klassen auch nicht kommentiert wurde. Natürlich mussten sie gelöscht werden, aber bevor ich solche überflüssigen Sachen lösche, habe ich eine - manche mögen sagen seltsame - Angewohnheit:

Ich lösche solche redundanten Dateien nicht sofort über SVN-> Löschen (durch einen Löschbefehl des Versionskontrollsystems Ihrer Wahl ersetzen), sondern füge stattdessen Kommentare in die Dateien ein (ich verweise sowohl am Kopf als auch in der Fußzeile), auf die sie sich beziehen gelöscht werden + mein Name + das Datum und - was noch wichtiger ist - WARUM SIE GELÖSCHT WERDEN (in meinem Fall, weil sie tot waren, verwirrender Code). Dann speichere ich sie und übergebe sie der Versionskontrolle. Wenn ich das nächste Mal etwas im Projekt zur Versionskontrolle einchecken muss, drücke ich SVN-> Löschen und sie werden schließlich in der Versionskontrolle gelöscht - natürlich immer noch durch Überarbeitungen wiederherstellbar, und aus diesem Grund habe ich diese Gewohnheit übernommen.

Warum dies tun, anstatt sie sofort zu löschen?

Mein Grund ist, dass ich zumindest in der letzten Revision, in der diese redundanten Dateien existierten, explizite Markierungen haben möchte, weshalb sie es verdient haben, gelöscht zu werden. Wenn ich sie sofort lösche, werden sie gelöscht, aber es ist nirgendwo dokumentiert, warum sie gelöscht wurden. Ich möchte ein typisches Szenario wie dieses vermeiden:

"Hmm ... warum wurden diese Dateien gelöscht? Ich habe vorher gut gearbeitet." (Drückt "Zurück" -> Kerl, der zurückgesetzt hat, ist dann für immer weg oder in den nächsten Wochen nicht mehr verfügbar und der nächste Rechtsnachfolger muss mühsam herausfinden, worum es bei diesen Dateien geht.)

Merken Sie sich aber nicht, warum diese Dateien in den Commit-Nachrichten gelöscht wurden?

Natürlich tue ich das, aber eine Commit-Nachricht wird manchmal von Kollegen nicht gelesen. Es ist keine typische Situation, dass Sie, wenn Sie versuchen, den (in meinem Fall toten) Code zu verstehen, zuerst das Versionskontrollprotokoll mit allen zugehörigen Commit-Meldungen überprüfen. Anstatt das Protokoll zu durchsuchen, kann ein Kollege sofort erkennen, dass diese Datei unbrauchbar ist. Das spart ihm / ihr Zeit und sie / er weiß, dass diese Datei wahrscheinlich fehlerhaft wiederhergestellt wurde (oder zumindest eine Frage aufwirft).

Das Problem beim Hinzufügen eines Kommentars zu einer Datei, die gelöscht werden soll, anstatt ihn in der Quellcodeverwaltung zu löschen und die Erklärung dort abzulegen, besteht in der Annahme, dass Entwickler, die keine Commit-Nachrichten lesen, mit Sicherheit Kommentare im Quellcode lesen.

Aus der Sicht eines Außenstehenden scheint diese Methodik auf einer sehr konservativen Sicht der Quellcodeverwaltung zu beruhen.

"Was ist, wenn ich diese unbenutzte Datei lösche und sie dann von jemandem benötigt wird?" könnte jemand fragen.

Sie verwenden die Quellcodeverwaltung. Machen Sie die Änderung rückgängig oder sprechen Sie besser mit der Person, die die Datei gelöscht hat (kommunizieren Sie).

"Was ist, wenn ich die tote Datei lösche, jemand sie wieder verwendet und Änderungen vornimmt?" jemand anderes könnte fragen.

Wieder verwenden Sie Quellcodeverwaltung. Sie erhalten einen Zusammenführungskonflikt, den eine Person lösen muss. Wie bei der letzten Frage geht es auch hier darum, mit Ihren Teamkollegen zu kommunizieren.

Wenn Sie wirklich bezweifeln, dass eine Datei entfernt werden sollte, teilen Sie dies mit, bevor Sie sie aus der Quellcodeverwaltung löschen. Vielleicht wird es erst seit kurzem nicht mehr verwendet, aber für eine zukünftige Funktion ist es möglicherweise erforderlich. Sie wissen das nicht, aber einer der anderen Entwickler könnte.

Sollte es entfernt werden, entfernen Sie es. Schneiden Sie das Fett aus der Code-Basis.

Wenn Sie einen "Oopsie" gemacht haben und die Datei tatsächlich benötigen, denken Sie daran, dass Sie die Quellcodeverwaltung verwenden, damit Sie die Datei wiederherstellen können.

Vincent Savard sagte in einem Kommentar zu der Frage:

... Wenn Ihre Kollegen die Commit-Nachrichten nicht lesen und eine Datei, die zu Recht gelöscht wurde und die Codeüberprüfung besteht, wieder aufleben lassen, stimmt in Ihrem Team definitiv etwas nicht, und es ist eine großartige Gelegenheit, sie besser zu unterrichten.

Das ist ein guter Rat. Code-Überprüfungen sollten diese Art von Dingen auffangen. Entwickler müssen sich über Commit-Nachrichten informieren, wenn eine Datei unerwartet geändert oder eine Datei entfernt oder umbenannt wird.

Wenn die Festschreibungsnachrichten nicht die Geschichte erzählen, müssen Entwickler auch bessere Festschreibungsnachrichten schreiben.

Die Angst, Code oder Dateien zu löschen, weist auf ein tieferes, systembedingtes Problem mit dem Prozess hin:

• Fehlende genaue Codeüberprüfungen
• Unverständnis darüber, wie die Quellcodeverwaltung funktioniert
• Fehlende Teamkommunikation
• Schlechte Commit-Nachrichten von Entwicklern

Dies sind die Probleme, mit denen Sie sich befassen müssen, damit Sie nicht das Gefühl haben, Steine ​​in ein Glashaus zu werfen, wenn Sie Code oder Dateien löschen.

Ja, es ist eine schlechte Übung.

Sie sollten die Erklärung für das Löschen in die Festschreibungsnachricht einfügen, wenn Sie das Löschen der Dateien festschreiben.

Kommentare in Quelldateien sollten den Code so erklären, wie er derzeit aussieht . Commit-Meldungen sollten erklären, warum die Änderungen am Commit vorgenommen wurden, sodass der Commit-Verlauf in der Datei dessen Verlauf erläutert.

Das Schreiben von Kommentaren, in denen Änderungen direkt in der Quelle erklärt werden, erschwert lediglich die Verfolgung des Codes. Denken Sie darüber nach: Wenn Sie jedes Mal, wenn Sie Code ändern oder löschen, einen Kommentar in der Datei einfügen, werden die Dateien bald mit Kommentaren zum Änderungsverlauf überschwemmt.

Meiner Meinung nach handelt es sich bei beiden Optionen nicht um bewährte , sondern um schlechte Methoden:

1. Das Hinzufügen von Kommentaren fügt nur dann einen Wert hinzu, wenn jemand diese Kommentare liest.
2. Das einfache Löschen aus dem VCS (mit einem Grund in der Änderungsbeschreibung) kann sich auf ein kritisches Ergebnis auswirken, und viele Leute lesen die Änderungsbeschreibung nicht, insbesondere wenn sie unter Druck stehen.

Meine bevorzugte Vorgehensweise - hauptsächlich, weil ich im Laufe der Jahre mehrmals gebissen wurde, wobei ich bedenke, dass Sie nicht immer wissen, wo oder von wem Ihr Code verwendet wird - ist:

1. Fügen Sie einen Kommentar hinzu, der besagt, dass es sich um einen Löschkandidaten und eine Ablehnung #warning oder ähnliches handelt (die meisten Sprachen haben einen solchen Mechanismus, z. B. in Java , im schlimmsten Fall printgenügt eine Aussage oder ähnliches), idealerweise mit einer Art Zeitskala und mit Kontaktdaten. Dies wird niemanden alarmieren , dass nach wie vor ist eigentlich mit dem Code. Diese Warnungen befinden sich normalerweise in jeder Funktion oder Klasse, wenn solche Dinge existieren .
2. Aktualisieren Sie die Warnung nach einiger Zeit auf einen Standarddateibereich #warning(einige Benutzer ignorieren Verfallswarnungen und einige Toolketten zeigen solche Warnungen standardmäßig nicht an).
3. Ersetzen Sie den Dateibereich später durch #warningeinen #erroroder einen gleichwertigen Code. Dadurch wird der Code beim Erstellen beschädigt, kann jedoch bei Bedarf entfernt werden, aber die Person, die ihn entfernt, kann ihn nicht ignorieren. (Einige Entwickler lesen oder adressieren keine Warnungen oder haben so viele, dass sie die wichtigen nicht herausfiltern können.)
4. Markieren Sie schließlich die Datei (en) (am oder nach dem Fälligkeitsdatum) als im VCS gelöscht.
5. Wenn ich ein ganzes Paket / Bibliothek / etc in der Warnphase lösche, würde ich eine README.txt oder README.html oder ähnliches mit der Information hinzufügen, wann und warum geplant ist, das Paket loszuwerden und nur diese Datei mit einem zu belassen Ändern Sie diese Option, um anzugeben, wann sie gelöscht wurde, da sie einige Zeit nach dem Entfernen des restlichen Inhalts der einzige Inhalt des Pakets war.

Ein Vorteil dieses Ansatzes besteht darin, dass einige Versionsverwaltungssysteme (CVS, PVCS usw.) eine vorhandene Datei beim Auschecken nicht entfernen, wenn sie im VCS gelöscht wurde. Es gibt auch gewissenhaften Entwicklern, die alle ihre Warnungen korrigieren, viel Zeit, um das Problem anzugehen oder die Löschung anzufechten. Es zwingt auch die verbleibenden Entwickler, zumindest die Löschungsmitteilung zu lesen und sich viel zu beschweren .

Beachten Sie, dass #warning/ #errorein C / C ++ - Mechanismus ist, der eine Warnung / einen Fehler, gefolgt von dem bereitgestellten Text, verursacht, wenn der Compiler auf diesen Code stößt. Java / Java-Doc verfügt über eine @DeprecatedAnnotation, um bei Verwendung eine Warnung @deprecatedauszugeben und einige Informationen usw. bereitzustellen Rezepte , die in Python ähnlich sind & ich habe gesehen assert, dass sie ähnliche Informationen liefern wie #errorin der realen Welt.

Ja, ich würde sagen, es ist eine schlechte Praxis, aber nicht, weil es in den Dateien oder in der Commit-Nachricht steht. Das Problem ist, dass Sie versuchen, eine Änderung vorzunehmen, ohne mit Ihrem Team zu kommunizieren.

Wann immer Sie Änderungen am Trunk vornehmen - Dateien hinzufügen, löschen oder auf irgendeine Weise ändern - sollten Sie, bevor Sie einen Commit für den Trunk durchführen, direkt mit einem Mitglied (oder Mitgliedern) des Teams über diese Änderungen sprechen , das direkt dazugehört über sie Bescheid wissen (besprechen Sie im Wesentlichen mit Ihren Teamkollegen, was Sie in diese Überschriften schreiben würden). Dies stellt sicher, dass (1) der Code, den Sie löschen, wirklich gelöscht werden muss und (2) Ihr Team mit größerer Wahrscheinlichkeit weiß, dass der Code gelöscht wurde, und versucht daher nicht, Ihre Löschungen zurückzusetzen. Ganz zu schweigen davon, dass Sie auch eine Fehlererkennung und ähnliches für den hinzugefügten Code erhalten.

Wenn Sie große Datenmengen ändern, sollten Sie diese natürlich auch in die Festschreibungsnachricht einfügen. Da Sie jedoch bereits darüber gesprochen haben, muss dies nicht die Quelle wichtiger Ankündigungen sein. In der Antwort von Steve Barnes werden auch einige gute Strategien angesprochen, die zu verwenden sind, wenn der potenzielle Pool an Benutzern für Ihren Code zu groß ist (z. B. Verwenden der veralteten Markierungen Ihrer Sprache, anstatt die Dateien zuerst zu löschen).

Wenn Sie nicht so lange ohne Commit auskommen möchten (dh Ihre Änderung ist am sinnvollsten, wenn Sie mehrere Revisionen durchführen), ist es eine gute Idee, einen Zweig aus trunk zu erstellen und den Zweig festzuschreiben und den Zweig dann wieder in trunk zusammenzuführen, wenn der Änderung ist bereit. Auf diese Weise sichert das VCS die Datei weiterhin für Sie, aber Ihre Änderungen wirken sich in keiner Weise auf den Trunk aus.

Ein verwandtes Problem aus Projekten, die auf mehreren Plattformen und Konfigurationen basieren. Nur weil ich feststelle, dass es tot ist, heißt das nicht, dass es eine richtige Bestimmung ist. Beachten Sie, dass Totgebrauch immer noch eine Abhängigkeit von Spuren bedeuten kann, die noch beseitigt werden muss, und dass einige möglicherweise übersehen wurden.

Also (in einem C ++ Projekt) habe ich hinzugefügt

#error this is not as dead as I thought it was

Und checkte das ein. Warten Sie, bis alle normalen Plattformen wiederhergestellt sind und sich niemand darüber beschwert. Wenn jemand es finden würde, wäre es einfach, eine Zeile zu entfernen, anstatt mit einer fehlenden Datei verwirrt zu sein.

Ich bin grundsätzlich damit einverstanden, dass die von Ihnen erwähnten Kommentare die Funktion duplizieren, die im Versionsverwaltungssystem ausgeführt werden sollte . Möglicherweise haben Sie jedoch bestimmte Gründe, dies zu ergänzen. Das VCS-Tool nicht zu kennen, gehört nicht dazu.

Auf dem Kontinuum der schlechten Praktiken ist dies ziemlich gering. Ich werde dies gelegentlich tun, wenn ich eine Filiale auschecken und in der Lage sein möchte, den alten Code zu sehen. Dies kann den Vergleich mit dem Ersatzcode erleichtern. Normalerweise erhalte ich einen Kommentar zur Codeüberprüfung "cruft". Mit einer kleinen Erklärung übergebe ich die Codeüberprüfung.

Aber dieser Code sollte nicht lange leben. Ich lösche in der Regel zu Beginn des nächsten Sprints.

Wenn Sie Mitarbeiter haben, die keine Commit-Nachrichten lesen oder Sie nicht fragen, warum Sie den Code im Projekt belassen haben, liegt das Problem nicht an einem schlechten Codierungsstil. Du hast ein anderes Problem.

Sie können die Klasse auch umgestalten und mit dem Präfix UNUSED_Classname umbenennen, bevor Sie Ihren Stunt ausführen. Dann sollten Sie den Löschvorgang auch direkt durchführen

• Schritt 1: Klasse umbenennen, Kommentar hinzufügen, festschreiben
• Schritt 2: Datei löschen und festschreiben

Wenn der Code tot ist, löschen Sie ihn. Jeder braucht es, er kann zurückgehen, aber der Umbenennungsschritt hindert ihn daran, es direkt zu verwenden, ohne nachzudenken.

Bringen Sie den Leuten auch bei, wie man alle Commit-Nachrichten für eine Datei betrachtet. Manche wissen nicht einmal, dass dies möglich ist.