Wartung - Balancing die Frage, wann und wenn Sie Änderungen vornehmen

Question

Ich pflege ein paar Bibliotheken für andere Leute. Nachdem ich für jeden von ihnen ein paar Releases durchgemacht hatte, gab es einige Dinge, die ich anders machen würde, wenn ich sie nochmal machen müsste.

Die Frage ist: Soll ich sie tun? Ich denke, wir alle stehen vor diesem Dilemma - wie man die Hilfsbereitschaft der Wartungsaktivitäten gegen die störenden Auswirkungen der Veränderung ausbalanciert.

Offensichtlich für Bugs ist die Änderung zwingend erforderlich. Kein Dilemma da. Für neue Funktionen ist es eine Frage von Nutzen gegenüber zusätzlicher Komplexität. Ich fühle mich mit dieser Frage wohl.

Es ist der unscharfe Abstand zwischen Bugfix und neuer Funktion, nach dem ich frage. Ein Beispiel ist die Wartung, um die Rahmenrichtlinien für das Design oder die CLS-Konformität zu erfüllen. Für eine Bibliothek habe ich sie geschrieben, ohne an CLS-Compliance zu denken, und dann haben die Leute danach gefragt. Als Ergebnis musste ich die Schnittstelle ändern, um int für int zu tauschen. Das ist eine bahnbrechende Veränderung, für wenig Gewinn (für die meisten Leute).

Ein weiteres Problem: FxCop-Compliance. Ich musste für einige Methoden Änderungen in Parameternamen vornehmen, um FxCop glücklich zu machen. Aber diese Veränderungen betreffen nur Menschen, die sich der Reflexion bedienen - die Typen haben sich nicht geändert, nur die Namen der Params.

Das Problem, mit dem ich es gerade zu tun habe, ist: Framework Design Guidelines. Die Richtlinien zu Ereignissen sagen, dass Ereignisse eine Signatur mit zwei Argumenten haben sollten: (Objektquelle, EventArgs e). Aber ich war an diesem Tag in meinem Framework Design Kurs abwesend;). Die Ereignisse in meiner Bibliothek verwenden derzeit nur ein einziges EventArgs-Argument.

Ich füge jetzt neue Ereignisse zur Bibliothek hinzu. Sollten die neuen Veranstaltungen den Richtlinien für das Framework-Design entsprechen? oder das Muster bereits in der Bibliothek etabliert? Wenn ich die Designrichtlinien für die neuen Ereignisse verwende, sollte ich die vorhandenen Ereignisse so ändern, dass sie auch den Designrichtlinien entsprechen? Und wenn ja, wie wird die Migration durchgeführt? Soll ich das Attribut [Obsolet] verwenden? Wie viele Veröffentlichungen?

Allgemeiner bin ich interessiert an Gedanken zur Wartung in diesem unscharfen Bereich zwischen Bugfix und neuer Funktion.

Answer 1

Anstatt den alten Code zu ändern, ist er abzulehnen. Starten Sie Ihren neuen Code mit dem richtigen Design und schreiben Sie Ersatzcode für die Teile mit dem alten Design. Schließlich werden Sie mit einem System enden, das alle das richtige Design verwendet, aber es wird keine sehr störende Veränderung sein.

Answer 2

Sie müssen auf jeden Fall viel kommunizieren, wenn Sie vorhaben, Änderungen vorzunehmen. Selbst wenn Sie Ihre Bibliotheken als Version 2 neu starten, müssen Sie Ihren Benutzern mitteilen, dass Version 1 nur in der Zukunft fehlerbehaftet sein wird und Sie werden in die Entwicklung von Version 2 gehen, wo sie alle neuen Funktionen finden können.

Aber ich denke, dass ich diesen Weg gehen würde. Unterstütze Version 1 für Bugfixes und portiere eine neue Version 2 für die brechenden Änderungen.

Answer 3

Wenn ich versuche, einige Richtlinien zu befolgen, denen ich vorher nicht gefolgt bin, werde ich in dem neuen Code tun. Für vorhandenen Code behebe ich sie, es sei denn, sie sind kaputt. Wenn Sie jedoch einige Fehler im vorhandenen Code finden, sollten Sie die Richtlinien anwenden und gleichzeitig die Fehler beheben.