Welche speziellen Techniken verwenden Sie, wenn Sie bestehenden Code ändern?Wartungskommentar
Beispiel: Angenommen, Sie ändern eine Geschäftsregel in einer Methode. Markierst du den modifizierten Abschnitt mit speziellen Kommentaren?
Irgendwelche Codierungs-/Kommentarstandards, die Sie verwenden, wenn Sie Code ändern?
Sie meinen, so etwas wie:
foo(); // changed by SecretWiz, 20090131
ich nicht empfehlen würde. Es verstopft die Code-Dateien, und das Versionskontrollsystem sollte das für Sie handhaben. Es verfolgt, wer was geändert hat. Verwenden Sie
svn blame
Nein, das ist eine sehr schlechte Idee. Ihre Quellcodeverwaltung behält den Verlauf aller Änderungen bei. Wenn Sie etwas anderes möchten, machen Sie einen Eintrag in Ihrem Fehlerverfolgungsprogramm. Es gibt keine Notwendigkeit, alte Codeabschnitte zu kommentieren oder Wurf mit Sachen wie:
// modified by A.B. on 11/23/99 to fix issue #123456
Ich habe so gesehen Kommentare in unserer Code-Basis und sie machen keinen Sinn Jahre auf der ganzen Linie. Wer zum Teufel ist A. B., und was war das Problem # 123456? Wenn der Code immer noch hier ist, bedeutet dies, dass jemand plant, diese Änderungen in der Zukunft zurückzustellen?
Diese Kommentare haben keinen Wert und dienen nur dazu, Ihren Code zu überladen.
Ich denke, bezogen auf das Problem # ist nicht so schlimm. Wir haben oft eine Situation, in der die Gründe für eine Ein-Zeilen-Änderung komplex sein können, und die Diskussion im Issue-Tracker zu lang ist, um sie in Code zu kopieren (jetzt * würde das * sie durcheinander bringen). Da der Issue Tracker - wie Versionskontrolle - nirgendwohin geht, finde ich es ok, die Referenz hinzuzufügen. Auch nach Jahren sehen Sie die vollständige Diskussion, die zu dieser spezifischen Codezeile führte. – Reunanen
Ich würde vorschlagen, eine Methode zu erstellen & rufen Sie das aus dem Code, der geändert wird.
Benennen Sie auch die Methode, um den Zweck/die Absicht der Methode vorzuschlagen.
z.B. GiveRebateIfValidCoupon();
"Irgendwelche Kodierungs-/Kommentarstandards, die Sie beim Modifizieren von Code verwenden?"
Ja. Erstelle neue Unterklassen. Lassen Sie alten Code allein, außer in dem seltenen Fall, dass Sie es nicht richtig getestet haben und tatsächlich falsch lagen.
Änderungen an den Anforderungen bedeuten das Hinzufügen von Unterklassen und neuen Tests für die neuen Geschäftsregeln.
Interessante Idee, aber ich weiß nicht, ob es in allen Fällen funktioniert. Manchmal ändern sich die Geschäftsregeln IMMER und es ist nicht nötig, diesen alten Code herumzuhalten. –
Das klingt nach einem Rezept für Starrheit –
Rieche ich hier irgendeine C++ - ähnliche Technologie im Hintergrund? Wenn Sie darauf bestehen würden, bei meinem C#/Java-Projekt so zu arbeiten, hätte ich Sie aus dem Projekt geworfen. -1 von mir. – krosenvold
Die einzige Zeit, die ich spezielle Kommentare hinzufügen, ist, wenn die Änderung vorübergehend sein soll. In dieser Situation markiere ich es mit einem Standardschlüsselwort (zB TEMPFIX), damit ich es später finden kann. Natürlich müssen Sie dann daran denken, zurück zu kommen und den Code zu entfernen oder eine dauerhafte Änderung vorzunehmen, aber bei einigen Projekten haben wir dies mithilfe eines Makros erzwungen, mit dem wir ein Ablaufdatum angeben konnten, nach dem der Code nicht mehr kompiliert wird.
Ansonsten verlassen wir uns auf die Quellcodeverwaltung.
Der Code sollte den Kodierungsstandards entsprechen, die Sie haben, oder Ihrer Organisation.
Also, nein, es sollte keine besonderen Kommentare geben, dass der Code geändert wurde - alle oder zumindest die meisten, Code wird früher oder später geändert.
Wenn es Code gibt, den Sie vererbt haben, der nicht zu kommentierenden Standards entspricht, dann fügen Sie Kommentare wie Sie refactor den Code hinzu. Wenn der Code wirklich alt und nicht dokumentiert ist, bedeutet das natürlich, Dokumentation hinzuzufügen.
Es ist gut, Code zu verstehen, bevor Sie ihn ändern (by-the-way).
Normalerweise werde ich nur den Code ändern und meine Kommentare in meiner Quellcodeverwaltung einchecken. In der Taskverfolgung der Wahl können Sie auf die Revision verweisen, in der die Aufgabe implementiert wurde.
Manchmal weiß ich, dass bestimmte Funktionen hin und her wechseln, sich bewegen, Namen ändern usw. je nachdem, wie die Benutzeranforderungen diskutiert werden. In diesem speziellen Fall werde ich die alte Version dort behalten und sie einfach kommentieren. Dann wird es trivial, es später einfach auskommentieren zu lassen, anstatt durch die Quellcodeverwaltung nach der alten Version zu suchen. Dies kann auch den Ärger von jemandem ersparen, wenn er seinen Code später pflegen muss, denn wenn die Benutzer ihre Meinung WIEDER ändern, ist die Anforderung bereits im Code und wartet darauf, unkommentiert zu werden.
Ich muss mich mit vielen anderen Leuten hier auf SO einigen. "Wenn Sie etwas in Ihrem Code nicht benötigen, entfernen Sie es". Vor allem im Produktionscode ist das Letzte, was Sie wollen, eine Menge Unordnung. Es könnte viel einfacher für jemanden sein herauszufinden, wie Ihre Änderung funktioniert, als Ihren Kommentar zur Wartung zu lesen und möglicherweise verwirrt zu werden.
Ich habe alten veralteten Code in meinen Projekten behalten, aber im Laufe der Zeit war ein Projekt, das nur ein paar tausend Zeilen hätte sein sollen, über 10.000 und schwer zu verwalten.
Wenn ich etwas wie das Korrigieren eines relativ obskuren Fehlers mache, im Grunde alles, wo es nicht ziemlich offensichtlich ist, warum ich den Code so geschrieben habe, wie ich es gemacht habe, füge ich normalerweise einen Kommentar hinzu, damit ich (oder jemand anders, wenn jemand anders meinen Code geändert hat ;-) wird ihn später nicht versehentlich entfernen.
Eine Sache, die ich immer versuche, ist, die Bug-ID (oder Feature-Request-ID) in Bug-Tracking-System in den Code-Checkin-Kommentare, die ich für diese Änderung tun. Ich füge etwas wie "Siehe die Kommentare für diesen Bug/Feature in Bugzilla für weitere Details". Dort kann ich die Gründe für diesen Codewechsel erklären. Dies bedeutet, dass alle Änderungen oder zumindest alle wichtigen Änderungen über eine Feature Request/Bug ID verfolgt werden müssen. Ich habe oft einen Fehler erstellt, nur um die geschäftlichen Gründe im Detail zu erklären.
+1 Beat mich durch eine Sekunde ... –
Tatsächlich macht mich das auch verrückt. – DavGarcia
Entfernen Sie solche Sachen, wenn Sie an einer Datei arbeiten, die andere auf diese Weise dekoriert haben? – innaM