Maintenance - équilibrer la question de savoir quand et si apporter des modifications

Question

Je gère quelques bibliothèques pour d'autres personnes. Après avoir passé en revue quelques versions pour chacune d’elles, il y a des choses que je ferais différemment si je devais les refaire.

La question est: devrais-je les refaire? Je suppose que nous sommes tous confrontés à ce dilemme: comment équilibrer l'utilité de l'activité de maintenance par rapport aux effets perturbateurs du changement.

Évidemment pour les bugs, le changement est impératif. Pas de dilemme là-bas. Pour les nouvelles fonctionnalités, il s’agit d’une question d’utilité par opposition à une complexité accrue. Je suis à l'aise avec cette question.

C’est l’espace flou entre la correction de bogue et la nouvelle fonctionnalité au sujet de laquelle je me pose des questions. Un exemple est la maintenance pour se conformer aux directives de conception du framework ou à la conformité CLS. Pour une bibliothèque, je l'ai écrit sans penser à la conformité CLS, puis les gens l'ont demandé. En conséquence, j'ai dû modifier l'interface pour permuter uint pour int. C’est un changement perturbateur qui n’apporte que peu d’avantages (pour la plupart des gens).

Autre problème: la conformité à FxCop. J'ai dû modifier les noms de paramètres pour certaines méthodes, pour rendre FxCop heureux. Mais ces changements n'affectent réellement que les personnes utilisant la réflexion - les types ne changent pas, seuls les noms des paramètres.

La question que je traite actuellement est: les directives de conception de cadre. Les instructions concernant les événements indiquent que les événements doivent avoir une signature avec deux arguments: (Source de l'objet, EventArgs e). Mais j'étais absent ce jour-là dans mon cours de Framework Design;). Les événements de ma bibliothèque ne prennent actuellement qu'un seul argument EventArgs.

J'ajoute maintenant de nouveaux événements à la bibliothèque. Les nouveaux événements doivent-ils suivre les directives de conception du cadre? ou le motif déjà établi dans la bibliothèque? Si j'utilise les directives de conception pour les nouveaux événements, dois-je modifier les événements existants pour qu'ils soient également conformes aux directives de conception? Et si oui, comment faire la migration? Devrais-je utiliser l'attribut [Obsolete]? Combien de sorties?

Plus généralement, je suis intéressé par des réflexions sur la maintenance dans cette zone floue entre la correction de bug et la nouvelle fonctionnalité.

Answer 1

Plutôt que de modifier l’ancien code, déconseillez-le. Commencez votre nouveau code avec la conception appropriée et écrivez le code de remplacement pour les morceaux en utilisant l'ancienne conception. vous finirez par vous retrouver avec un système utilisant tous la conception appropriée, mais ce ne sera pas un changement très perturbateur.

Answer 2

Vous devez certainement beaucoup communiquer si vous prévoyez de faire des changements radicaux. Même si vous redémarrez vos bibliothèques en tant que version 2, vous devrez dire à vos utilisateurs que la version 1 ne sera corrigée que par la suite et que vous vous dirigerez vers le développement de la version 2 où ils trouveront toutes les nouvelles fonctionnalités.

Mais je pense que j'irais de cette façon. Supportez la version 1 pour les corrections de bugs et portez une nouvelle version 2 pour les modifications les plus récentes.

Answer 3

Si j'essaie de suivre certaines directives que je n'avais pas suivies auparavant, je le ferai dans le nouveau code. Pour le code existant, je vais les réparer à moins qu’ils ne soient cassés. Toutefois, si vous rencontrez des problèmes dans le code existant, il est judicieux d’appliquer les directives tout en corrigeant les erreurs en même temps.