Lorsque votre instinct vous dit que vous devriez probablement faire un peu de refactoring, c'est probablement votre instinct qui vous dit un peu tard que vous retardez quelque chose d'important depuis trop longtemps.
Je comprends les "odeurs de code", le refactor rouge-vert et d'autres pensées, mais souvent je pense que le meilleur moment pour refactoriser n'est pas la première fois que vous écrivez le code, mais la deuxième ou la troisième fois que vous utilisez le code et réalisez qu'il s'agit en fait d'un problème et qu'il est réellement utilisé.
Il existe effectivement deux niveaux de refactoring. Le premier est les problèmes évidents qui apparaissent lorsque vous codez pour la première fois. Ce sont les petites optimisations qui vous coûtent très peu à faire dès le départ. Des choses comme garder vos méthodes et vos classes petites et adhérer à DRY et SRP. Ensuite, vous avez l'étape supplémentaire de traiter les défauts majeurs de votre conception, qui peuvent ne pas être immédiatement apparents jusqu'à ce que votre code ait quelques kilomètres en dessous. C'est de ce deuxième niveau que vous parlez, et pourtant pour vous assurer que la refactorisation ultérieure ne soit pas trop coûteuse, vous devez avoir déjà écrit votre code de telle manière que l'effort que vous envisagez plus tard soit rendu plus facile et moins coûteux, ce qui signifie faire une refactorisation précoce.
Comme Jeff l'a mentionné dans sa réponse, «le temps c'est de l'argent» , en particulier dans les entreprises où la charge de travail est élevée et les risques encore plus élevés. Le temps passé à l'avant pour s'assurer que le code est dans son meilleur état possible est un gain de temps plus tard, lorsque démêler ce qui aurait dû être une refactorisation facile se révèle être une opération majeure.
Lors de l'écriture d'un logiciel, chaque instant passé à améliorer votre code est un gain de temps plus tard, lorsque vous en aurez vraiment besoin. Plus vous refactorisez tôt, plus vos modifications ultérieures seront claires. C'est comme faire un acompte en dollars d'aujourd'hui contre une future dette technique qui sera en dollars gonflés de demain.
Dans tous les cas, le refactoring ne devrait pas être une tâche que vous remettez à un avenir mystérieux lorsque le logiciel est déjà complet et stable, car il augmente vos risques plus tard lorsque les enjeux sont beaucoup plus élevés et le produit beaucoup plus difficile à changer. La refactorisation devrait faire partie de vos activités quotidiennes, et c'est l'essence de la philosophie Red-Green-Refactor que vous avez mentionnée.