Raisonner d'attendre jusqu'à la troisième fois dans la règle des trois?

Je viens de tomber sur l'article " Rule of Three " dans wikipedia

La règle de trois est une règle empirique de refactorisation de code pour décider quand un morceau de code répliqué doit être remplacé par une nouvelle procédure. Il indique que le code peut être copié une fois, mais que lorsque le même code est utilisé trois fois, il doit être extrait dans une nouvelle procédure. La règle a été introduite par Martin Fowler dans Refactoring et attribuée à Don Roberts.

Je sais que ce n'est qu'une règle d'or, mais pourquoi est-il recommandé de refactoriser uniquement après la deuxième duplication? Y a-t-il un inconvénient au refactoring lorsque nous écrivons la première duplication?

refactoring dry rule-of-three

— Louis Rhys
source

See Two est un nombre impossible et la règle Zero-One-Infinity pour un autre ensemble de perspectives.

— AakashM

En ce qui concerne le développement de logiciels, le wiki original est souvent une bien meilleure source que Wikipedia. Après tout, Ward Cunningham a inventé le Wiki comme moyen de parler du développement logiciel. Voir C2.Com/cgi/wiki?RuleOfThree

— Jörg W Mittag

S'il y a 2 scénarios de réutilisation, vous pouvez facilement brancher la logique (si, sinon). Une fois qu'il a atteint trois chemins possibles, il devient plus facile de re-factoriser que de répliquer et de maintenir.

— Andrew Lewis

double possible de la règle générale pour les économies vs coûts pour le code de réutilisation

— moucheron

Je pense que c'est une excuse commode pour copier-coller, quand on peut réellement refactoriser et généraliser. Lorsque vous obtenez le troisième cas, vous pouvez généraliser davantage.

— Alexey

Je pense que cette règle de base existe parce qu'il est facile de se laisser prendre à jouer à "What if ..." lors de la conception du code pour la première fois ou après la première duplication. J'ai rencontré une grave paralysie de l'analyse dans certains cas parce que les gens ont commencé à concevoir des fonctionnalités qui pourraient être nécessaires plus tard. Mais pas nécessaire pour le problème immédiat à résoudre.

Il existe un art pour concevoir / écrire uniquement ce dont vous avez besoin, tout en gardant le code prêt pour une future refactorisation.

— EdH
source

C'est un bon point. D'après mon expérience, avoir un troisième exemplaire rend également les points communs et les différences entre eux un peu plus nets qu'avec seulement deux.

— Daniel B