J'ai en fait subi une refonte assez importante trois fois dans ma carrière. Le code a tendance à se décomposer, donc si votre base de code est assez longue, un grand refactor est à peu près inévitable. Tous mes exemples étaient sur des bases de code privées, ce qui pourrait expliquer pourquoi les exemples publics sont difficiles à trouver.
La première fois était une application qui, croyez-le ou non, avait une architecture fondamentale qui ne fonctionnait qu'avec des imprimantes matricielles. Quand mon entreprise n'a plus pu trouver de fournisseur pour fournir les rubans, ils m'ont assigné pour le faire fonctionner avec une imprimante laser.
La deuxième fois a été une migration de plusieurs centaines de scripts de test automatisés de C vers Java, en partie parce que nous avions besoin d'une meilleure capacité multiplateforme et en partie parce qu'il devenait difficile d'embaucher de nouveaux développeurs C.
La troisième fois, je suis toujours en train de moduler une énorme application monolithique pour permettre les tests unitaires en réduisant le couplage et à des fins multiplates-formes.
Je compare l'effort à l'escalade d'une montagne. Vous avez cet énorme objectif devant vous, mais vous ne vous y attaquez pas au niveau macro. Vous le prenez une poignée à la fois, ayant toujours une position de repli proche, ne déconnectant jamais la sécurité précédente jusqu'à ce que la suivante soit en place. Vous commencez simplement à faire de petites améliorations incrémentielles, et après un certain temps, vous vous retournez et il y a soudain cette belle vue.
Disons que vous avez 60 000 fichiers de code fortement couplé, par exemple. Vous voulez commencer à le mettre sous test unitaire, mais les dépendances le rendent impossible. Comment le corrigez-vous? Vous découplez un fichier. Vous ajoutez des tests automatisés. Vous revenez sur un terrain stable avant de continuer. Répétez 59 999 fois.
Si simple que des sons, c'est parce qu'il est simple. Ce n'est pas facile, mais c'est simple. Il est difficile de remarquer des progrès au début. Nous sommes dans deux ans dans ce qui semblait un refactor impossible, et nous avons probablement des années devant nous jusqu'à ce que nous ayons terminé, mais en regardant en arrière, nous réalisons soudainement à quel point le code s'est déjà amélioré, et nous avons pu continuer à fournir de nouvelles fonctionnalités à nos clients en attendant.
Les deux autres fois ont fonctionné de la même manière. Vous trouvez la plus petite étape sûre que vous pouvez prendre, et vous la prenez, en gardant toujours l'application en état de fonctionnement. Vous ne vous souciez que de la vue d'ensemble pour vous assurer que vous vous dirigez dans la bonne direction. Toutes vos actions sont petites, régulières et incrémentales.