Vous avez raison: le copier-coller fonctionne très bien et DRY ne sert à rien si votre tâche est de produire un programme pour lequel le modèle copié ou la copie ne devra plus être conservé ni évolué. Lorsque ces deux composants logiciels ont un cycle de vie complètement différent, les coupler en reformulant le code commun dans une bibliothèque commune, elle-même en cours de développement, peut en effet avoir des effets imprévisibles sur l'effort. En revanche, lors de la copie de sections de code dans un programme ou un système de programme, toutes ces parties auront généralement le même cycle de vie. Je vais illustrer ci-dessous ce que cela signifie pour DRY et la gestion de projet.
Sérieusement, il existe de nombreux programmes de ce type: par exemple, l’industrie du jeu vidéo produit beaucoup de programmes qui doivent être conservés sur une courte période de quelques mois ou un an au maximum, et lorsque ce temps est écoulé, le copier-coller l'ancien code d'un jeu précédent où la période de maintenance est dépassée, la base de code d'un nouveau jeu convient parfaitement et pourrait accélérer les choses.
Malheureusement, le cycle de vie de la plupart des programmes auxquels j'ai eu à faire au cours des dernières années est très différent de cela. 98% des exigences ou demandes de correctifs de bugs qui me sont arrivées étaient des demandes de changementpour les programmes existants. Et chaque fois que vous avez besoin de changer quelque chose dans un logiciel existant, la "gestion de projet" ou la planification donnent de meilleurs résultats lorsque vos efforts de test et de débogage sont assez faibles - ce qui ne sera pas le cas si vous changez quelque chose au même endroit, mais à cause de la copie. une logique métier complexe que vous oubliez facilement que vous devez également modifier une douzaine d'autres emplacements dans la base de code. Et même si vous parvenez à trouver tous ces endroits, le temps de les changer tous (et de tester les changements) est probablement beaucoup plus long, comme si vous n'aviez qu'un endroit à changer. Ainsi, même si vous pouviez faire une estimation précise du changement, le fait d’avoir des coûts douze fois supérieurs au besoin peut facilement entrer en conflit avec le budget du projet.
TLDR - n'hésitez pas à copier si vous développez un programme qui ne nécessite ni responsabilité ni correction de bogues et maintenance de l'original ou de la copie. Mais si vous, votre équipe ou votre entreprise êtes ou pourriez devenir responsables, appliquez DRY chaque fois que vous le pouvez.
Exemple
En tant qu’additif, permettez-moi d’expliquer ce que «correction de bogues et maintenance» signifie, et en quoi cela conduit à une imprévisibilité de la planification, en particulier à l’intérieur d’un produit, par un exemple concret. J'ai effectivement vu ce genre de choses se produire en réalité, probablement pas avec 100 instances, mais les problèmes peuvent même commencer lorsque vous ne disposez que d'une instance en double.
La tâche: créer 100 rapports différents pour une application, chaque rapport ayant un aspect très similaire, certaines différences d’exigences entre les rapports, une logique différente, mais dans l’ensemble, peu de différences.
Le développeur qui obtient cette tâche crée la première (disons que cela prend 3 jours), après quelques modifications ou corrections de bugs mineurs dues au contrôle qualité et à l'inspection du client terminée, il semble fonctionner correctement. Ensuite, il a commencé à créer le prochain rapport en copiant-collant et en modifiant l’ensemble, puis le suivant, et pour chaque nouveau rapport, il a besoin d’environ 1 jour en moyenne. Très prévisible, au premier regard ...
Maintenant, une fois que les 100 rapports sont «prêts», le programme passe en production réelle et certains problèmes surviennent qui ont été négligés au cours de l'assurance qualité. Peut-être y a-t-il des problèmes de performances, peut-être que les rapports se bloquent régulièrement, peut-être que d'autres choses ne fonctionnent pas comme prévu. Maintenant, lorsque le principe DRY aura été appliqué, 90% de ces problèmes pourraient être résolus en modifiant la base de code à un endroit. Mais en raison de l'approche copier-coller, le problème doit être résolu 100 fois au lieu d'une fois. Et en raison des modifications déjà appliquées d'un rapport à un autre, le développeur ne peut pas rapidement copier-coller le correctif du premier rapport sur les 99 autres. Il doit examiner les 100 rapports, les lire, les traduire en modifications. signaler, tester et peut-être déboguer chacun individuellement. Pour le PM, cela commence à devenir très difficile - il peut bien sûr prendre le temps de corriger un bogue "habituel" (3 heures, par exemple) et le multiplier par 100, mais en réalité, il s'agit probablement d'une mauvaise estimation, certaines des corrections pouvant être apportées. plus facile à fabriquer que d’autres, d’autres pourraient être plus difficiles. Et même si cette estimation est correcte, les coûts de débogage 100 fois supérieurs à ceux qu’ils auraient dû coûteront très cher à votre entreprise.
La même chose se produira la prochaine fois que le client demandera de changer la couleur de l'emblème de sa société dans tous ces rapports, de rendre la taille de la page configurable ou d'une autre nouvelle exigence qui affecte tous les rapports de la même manière. Donc, si cela se produit, vous pouvez faire une estimation des coûts et facturer au client 100 fois le prix qu’il devrait payer lorsque le code était DRY. Cependant, essayez ceci plusieurs fois et le client annulera le projet car il ne sera probablement pas disposé à payer vos coûts d'évolution exorbitants. Et peut-être qu'à ce moment-là quelqu'un posera la question pourquoi cela est arrivé et montrera du doigt la personne qui a pris la décision pour cette programmation en copier-coller.
Mon point est le suivant: lorsque vous produisez un logiciel pour d’autres personnes, vous avez toujours au moins pour une courte période la responsabilité de faire fonctionner la chose, de corriger les bugs, d’adapter le programme à des exigences changeantes, etc. Même dans un projet en vert, les pièces peuvent rapidement s’ajouter à l’effort de développement initialement prévu. Et surtout lorsque tout votre code copié-collé est contenu dans un même produit, la période de responsabilité est la même pour toutes les parties, ce qui est très différent de la situation où vous copiez-collez du code plus ancien provenant d'un projet mort qui n'est plus. en maintenance active.