Par défaut, refactoriser. Une réécriture n'est justifiée que lorsque le système existant ne peut plus évoluer pour répondre aux besoins à un coût acceptable, et que vous pouvez continuer à délivrer de la valeur pendant que vous le faites. La plupart des réflexes « il nous faut une réécriture » sont en réalité un problème de tech debt non géré que le refactoring incrémental résout avec beaucoup moins de risque.
| Signal | Pencher refactor | Pencher réécriture |
|---|---|---|
| L'architecture convient aux besoins | Oui | Non |
| Couverture tests/spec | Faible ou élevée | Assez élevée pour vérifier la parité |
| Livraison possible de façon incrémentale | Oui | Difficile, big-bang |
| L'équipe comprend le code | Oui | Non, et les auteurs d'origine sont partis |
Le choix refactor-vs-réécriture est l'une des décisions à plus fort levier qu'un Tech Lead prend. Trompez-vous vers la réécriture et vous pouvez geler la livraison pendant un an et échouer quand même ; trompez-vous vers le refactor et vous saignez lentement de la vélocité. La présenter comme une décision de coût et de risque, pas de goût, est ce qui sépare le jugement senior de la préférence.