Le problème avec une refactorisation majeure est que vous pouvez et allez parfois suivre un chemin qui vous amène à réaliser que vous avez piqué plus que vous ne pouvez en mâcher. Les refactorisations géantes sont une erreur. Si la conception du système est défectueuse au départ, la refactorisation peut vous mener loin avant que vous deviez prendre une décision difficile. Vous pouvez soit laisser le système en l'état et contourner le problème, soit planifier de revoir la conception et d'apporter des modifications majeures.
Il y a cependant une autre façon. Le véritable avantage du code de refactoring est de rendre les choses plus simples, plus lisibles et encore plus faciles à maintenir. Lorsque vous abordez un problème pour lequel vous avez des doutes, vous indiquez un changement, allez jusqu’à voir où il pourrait conduire afin d’en savoir plus sur le problème, puis jetez la pointe et appliquez une nouvelle refactorisation en fonction de la pointe. vous a appris. Le fait est que vous ne pouvez vraiment améliorer votre code avec certitude que si les étapes sont petites et si vos efforts de refactoring ne surchargent pas votre capacité à écrire vos tests en premier. La tentation est d'écrire un test, puis du code, puis du code supplémentaire, car une solution peut sembler évidente, mais vous vous rendez vite compte que votre modification modifiera de nombreux autres tests. Vous devez donc faire attention à ne changer qu'une seule chose à la fois.
La solution est donc de ne jamais faire de votre refactoring un projet majeur. Pas de bébé. Commencez par extraire les méthodes, puis cherchez à supprimer les doublons. Passez ensuite à l'extraction des classes. Chacune par petites étapes, un changement mineur à la fois. SI vous extrayez du code, écrivez d'abord un test. Si vous supprimez du code, supprimez-le, lancez vos tests et déterminez si l'un des tests interrompus sera nécessaire. Un petit pas de bébé à la fois. Il semble que cela prendra plus de temps, mais réduira considérablement votre temps de refactoring.
La réalité est cependant que chaque pointe représente apparemment un gaspillage d’efforts. Les modifications de code ne vont parfois nulle part, et vous vous retrouvez en train de restaurer votre code depuis votre vcs. Ceci est juste une réalité de ce que nous faisons au jour le jour. Chaque pointe qui échoue n'est pas perdue cependant, si elle vous apprend quelque chose. Chaque effort de refactoring qui échoue vous apprendra que vous essayez de faire trop, trop vite ou que votre approche est peut-être fausse. Cela aussi n’est pas une perte de temps si vous en tirez des leçons. Plus vous en ferez, plus vous en apprendrez et plus vous deviendrez efficace. Mon conseil est de simplement le porter pour le moment, d'apprendre à faire plus en faisant moins et d'accepter que c'est exactement ce qu'il faut faire jusqu'à ce que vous sachiez mieux jusqu'où prendre une pointe avant qu'elle ne vous mène nulle part.