Meilleures pratiques pour renommer, refactoriser et interrompre les modifications avec les équipes

Quelles sont les meilleures pratiques de refactorisation et de changement de nom dans les environnements d'équipe? Je soulève ceci avec quelques scénarios à l'esprit:

1. Si une bibliothèque qui est généralement référencée est refactorisée pour introduire un changement de rupture dans une bibliothèque ou un projet qui la référence. Par exemple, changer arbitrairement le nom d'une méthode.

2. Si les projets sont renommés et que les solutions doivent être reconstruites avec des références mises à jour.

3. Si la structure du projet est modifiée pour être «plus organisée» en introduisant des dossiers et en déplaçant les projets ou solutions existants vers de nouveaux emplacements.

Quelques réflexions / questions supplémentaires:

1. Des changements comme celui-ci ou la douleur qui en résulte devraient-ils indiquer que la structure a mal tourné?

2. Qui devrait prendre la responsabilité de corriger les erreurs liées à un changement de rupture? Si un développeur apporte un changement de rupture, devrait-il être responsable de l’exploitation des projets concernés et de leur mise à jour ou devrait-il alerter d’autres développeurs et les inciter à changer les choses?

3. Est-ce quelque chose qui peut être fait sur une base programmée ou est-ce quelque chose qui devrait être fait aussi souvent que possible? Si un refactoring est reporté trop longtemps, il est de plus en plus difficile de le réconcilier, mais en même temps, au cours d'une journée, passer des incréments d'une heure à réparer un build en raison de changements qui se produisent ailleurs.

4. S'agit-il d'un processus de communication formel ou peut-il être organique?

Chacun des scénarios que vous avez répertoriés relève de la catégorie des "API / code publiés". Il est difficile de refactoriser, il ne faut donc rien changer à la légère. Il devrait plutôt négocier au préalable les changements prévus avec toutes les parties concernées. C'est au moins autant une question politique que technique.

Le conseil numéro un de Martin Fowler à ce sujet est donc de ne pas publier prématurément vos interfaces (noms de projets et structures) .

Cependant, si cela est déjà fait et qu'il doit être corrigé, il est probablement préférable d'essayer de faire les changements nécessaires en aussi peu d'étapes que possible, afin de minimiser la perturbation des autres parties. Ce qui s'écarte assez loin du concept original de refactoring, mais pour une bonne raison.

Aussi, si possible, envisagez d' ajouter la nouvelle méthode (tout en dépréciant celle existante) au lieu de renommer la méthode existante. Cela garantit que le code client ne casse pas et fournit une période de transition pour qu'ils mettent à jour leur code pour se conformer à la dernière API. L'inconvénient est que cela complique votre API. Bien que l'état ne soit que temporaire, il peut toutefois s'écouler un temps considérable avant de pouvoir supprimer en toute sécurité les méthodes d'API obsolètes (dans le cas de la bibliothèque de classes Java, années).

Vous pouvez presque toujours éviter ces problèmes en refactorisant en deux étapes. Dans la première étape, introduisez le nouveau code et déconseillez l'ancien code. Lorsque toutes les équipes ont migré vers le nouveau code, supprimez l'ancien code. J'utilise également cette technique pour refactoriser progressivement un seul module. De cette façon, je peux limiter la quantité de code qui doit être modifiée entre les tests.

Notez que c'est l'une des principales raisons d'avoir un serveur de build, qui exécute des tests.

Si quelque chose se produit qui va interrompre un programme donné, on vous le dit le plus rapidement possible et pouvez traquer le coupable et résoudre les problèmes pendant que les détails sont encore frais.