Pourquoi le «copier-coller» de code est-il dangereux? [fermé]

Parfois, mon patron se plaint à nous:

Pourquoi avons-nous besoin de si longtemps pour implémenter une fonctionnalité?

En fait, la fonctionnalité a déjà été implémentée dans une autre application, il vous suffit de copier et coller des codes à partir de là. Le coût devrait être faible.

C'est vraiment une question difficile, car copier et coller des codes n'est pas une chose aussi simple à mon avis.

Avez-vous de bonnes raisons d'expliquer cela à votre chef non technique?

Si vous trouvez un bogue dans votre code de copier-coller, vous devrez le corriger à chaque endroit où vous l'avez fait et j'espère que vous vous en souviendrez tous (cela vaut également pour les exigences modifiées).

Si vous conservez la logique à un seul endroit, il est plus facile de la modifier en cas de besoin (donc si vous décidez que l'application doit être mise à jour, vous ne le faites qu'à un seul endroit).

Demandez à votre patron de lire le principe DRY (Don't Repeat Yourself).

Ce que vous décrivez semble être une utilisation parfaite pour les bibliothèques , où vous partagez du code et ne le conservez qu'au même endroit.

Je ne copierais jamais du code que si j'avais l'intention de le refactoriser peu de temps après - en m'assurant que j'extrayais plus tard le code commun afin de pouvoir réutiliser autant de logique que possible. Et peu de temps après, je veux dire des minutes et des heures plus tard, pas des jours et des semaines.

Vous feriez bien mieux de partager le code en créant une bibliothèque plutôt que de copier le code en utilisant le copier-coller.

Vous gagnerez toujours un avantage de vitesse par rapport à la réécriture (recherchez DRY) mais vous n'aurez qu'un seul endroit pour maintenir le code.

La raison évidente est que vous prenez une `` dette '' pour l'avenir: tout changement que vous aurez besoin d'apporter dans le code (pas seulement les corrections de bogues, tout changement) sera désormais deux fois plus coûteux à faire car vous devez mettre à jour deux endroits - et plus risqué parce que vous en oublierez éventuellement un. En d'autres termes, le faire fonctionner plus rapidement maintenant ralentira votre travail à l'avenir, ce qui peut être bon pour les affaires, mais ce n'est généralement pas le cas.

Mais la raison la plus importante est que l'hypothèse «c'est la même chose que cela» est le plus souvent subtilement fausse. Chaque fois que votre code dépend d'hypothèses non dites pour être correct, le copier dans un autre endroit entraîne des erreurs, sauf si ces hypothèses sont également valables au nouvel endroit. Par conséquent, le code collé est souvent erroné dès le début et pas seulement après le prochain changement.

Du point de vue de la conception, le code copié-collé est certainement un désastre, avec le potentiel de causer de nombreux problèmes à l'avenir. Mais vous vous demandez pourquoi cela vous demande beaucoup de travail en ce moment , la réponse est: parce qu'il ne s'agit pas simplement de copier-coller.

Si le code d'origine a été écrit pour être réutilisé, en tant que bibliothèque assez indépendante, avec flexibilité et utilisation par le client à l'esprit - alors c'est parfait, mais ce n'est pas du copier-coller, c'est utiliser une bibliothèque de code. Le copier-coller de code réel ressemble généralement plus à ceci:

• "Bien sûr, j'ai déjà du code qui fait exactement cela!"
• "Attendez, laquelle de ces cinq versions de code est celle que je veux utiliser comme source?"
• "Hmmm, que font toutes ces fonctions 'util_func_023'? Ne les ai-je pas documentées? De laquelle ai-je besoin maintenant?"
• "Oh, oui, ce code utilise Code Base Y. Je suppose que je dois [en choisir un: copier tout Code Base Y dans mon nouveau projet / passer une journée à extraire la fonction que je veux de Code Base Y / passer une semaine à extraire le une fonction que je veux de Code Base Y]. "
• "J'ai tout copié, ouais!"
• "Pourquoi ça ne marche pas?"
• C'est le moment où vous passez des heures / jours / semaines à déboguer du code existant qui est similaire à ce que vous voulez, au lieu d'écrire le code avec lequel vous voulez réellement commencer.

En résumé, le code existant qui ne peut pas être utilisé directement peut, au mieux, servir de bonne référence pour écrire du code similaire. Il ne peut certainement pas être levé en entier et devrait fonctionner dans un système complètement différent. En général, c'est une hypothèse sûre que tout code qui a été écrit et complété devrait être le moins dérangé possible - même s'il s'agit d'une copie et non de l'original lui-même.

Si vous souhaitez baser votre projet sur le copier-coller, vous devez commencer par coder de manière à permettre une réutilisation facile, sans copier ce code d'origine et le manipuler. Cela vaut la peine d'être fait, et si c'est ce que votre patron attend, alors vous devez tous les deux vous assurer que c'est ainsi que vous concevez et travaillez en premier lieu.

copier-coller est un désastre qui attend. Votre patron devrait évaluer très tôt le prix de l'expédition par rapport au prix de l'envoi de code cassé à l'utilisateur final.

Si vous avez déjà implémenté les fonctionnalités et que vous devez copier et coller pour les réutiliser, il semble que vous ayez fait quelque chose de mal. Ne pouvez-vous pas mettre ces fonctionnalités dans une bibliothèque pour pouvoir les réutiliser sans copier / coller?

Le principe DRY (Don't Repeat Yourself): DRY sur wikipedia .

«Chaque élément de connaissance doit avoir une représentation unique, sans ambiguïté et faisant autorité au sein d'un système.

autre lien .

Il me semble que la pire idée fausse de votre chef non technique est que votre travail consiste principalement à taper. Ils pensent que vous pouvez gagner beaucoup de temps en éliminant la saisie.

Je pense que la meilleure éducation que vous pourriez donner à cette personne est de souligner tout le travail que vous faites sans taper. Même si la plupart de ce travail se fait généralement de manière invisible, dans votre tête, en même temps que la saisie.

Bien sûr, éliminer la saisie vous fera gagner du temps. Mais ensuite, la partie beaucoup plus volumineuse de votre travail, sans saisie, s'agrandit et vous fait gagner du temps et plus encore.

Etes-vous sûr que votre patron veut entendre parler du principe DRY, des bugs et autres trucs technologiques?

Ce genre de commentaires que vous entendez généralement lorsque votre patron ou votre entreprise sous-estime le temps nécessaire pour mener à bien un projet. Et sur la base d'une mauvaise estimation, un contrat a été signé, etc. Dans la plupart des cas, les programmeurs n'étaient pas impliqués dans les estimations.

Pourquoi cela arrive? Parfois, le sponsor du projet a un budget trop petit. Peut-être qu'un processus métier que vous automatisez à l'aide d'un logiciel ne vaut pas l'effort de votre équipe. Les gestionnaires ont généralement tendance à être très fermés pour les mauvaises nouvelles dans de tels cas. Au début du projet, il y a des vœux pieux. Ensuite, les gestionnaires essaient de blâmer les programmeurs. Dans votre cas indirectement via copier-coller. Dans les cas extrêmes, cela s'appelle une marche de la mort .

Copier et coller du code conduit généralement à la programmation par coïncidence

Je pense qu'une " autre application " est la clé ici, si l'autre application est déjà testée et utilisée, elle ne devrait pas être modifiée pour utiliser une bibliothèque commune, donc vous ne pouvez pas partager de code avec elle.

Au sein d'une même application , «copier et coller» est mauvais, mais entre des bases de code développées par différentes équipes ou avec des cycles de publication différents, «copier et coller» peut être la meilleure option.

J'ai travaillé pour une entreprise similaire. En tant que stagiaire, je ne savais pas mieux à l'époque, alors quand j'ai commencé un nouveau projet, mon patron a également suggéré de coller le code d'un autre endroit. Eh bien, comme vous le pensez peut-être, tout le logiciel était assez compliqué, au point que lorsque vous avez essayé de corriger un bogue, deux nouveaux bogues sont apparus.

Même si l'autre application dispose déjà de la fonctionnalité dont vous avez besoin, le code de cette fonctionnalité peut tout simplement ne pas s'intégrer dans votre application actuelle sans une réécriture majeure. C'est comme prendre le moteur d'une Ford et essayer de l'installer dans une Toyota. En règle générale, il existe une règle empirique selon laquelle si vous devez modifier plus de 25% du code que vous copiez, il est préférable (moins cher) de le réécrire à partir de zéro.

Extraire le code en question dans une bibliothèque semble convaincant, mais cela peut être plus difficile qu'il n'y paraît, selon la façon dont cet autre système est construit. Par exemple, le code de cette fonctionnalité peut être difficile à extraire car il interface de nombreux autres codes de manière impure (par exemple en accédant à de nombreuses variables globales, etc.)

Dites à votre patron que la partie du nom de chaque variable comprend le nom de l'ancien projet et que vous devez maintenant tous les changer manuellement. Si votre patron ne sait pas (ou veut savoir) pourquoi copier / coller est mauvais, il pourrait aussi bien le croire :)

Oui, le plus gros problème est qu'il ne s'agit pas simplement de copier et coller - son copier puis coller puis modifier légèrement.

Ensuite, plus tard, lorsque l'une des variantes collées a un problème, elle est modifiée. Puis plus tard, une autre variante est modifiée.

Ensuite, vous découvrez que toutes les variantes doivent changer car la copie d'origine avait des bogues. Maintenant, vous êtes bel et bien vissé car toutes les zones collées ne sont plus les mêmes.

Et ne le sauriez-vous pas, ce type de codage merdique est généralement presque entièrement dépourvu de commentaires.

Pour moi, la différence est que lorsque vous avez plusieurs copies de code faisant la même chose, vous avez un tas de code. Lorsque vous n'avez qu'un seul morceau de code pour chaque chose particulière, alors vous avez un système.

Les comportements d'un système peuvent être modifiés assez facilement avec des modifications en un seul point - changer le comportement d'un groupe de code nécessite un tas de code.

J'aime les systèmes, pas un tas de code.

Il existe des compromis entre la vitesse de développement de la fonctionnalité immédiate devant vous (en particulier lorsque l'application est petite) et les coûts de maintenance à plus long terme à mesure que l'application se développe.

Le copier-coller est plus rapide pour la fonctionnalité immédiate, mais vous coûtera cher à mesure que l'application grandit en taille, en termes de correction de bogues et de modifications à l'échelle du système et de maintien des flux de travail entre les différents composants de l'application.

C'est l'argument que les propriétaires d'entreprise doivent entendre. Il est similaire aux coûts acceptés de maintenance d'une flotte de véhicules, cependant, avec les logiciels, les aspects défectueux de l'architecture logicielle sont généralement cachés du côté commercial et ne peuvent être vus que par les développeurs.

Il a raison de dire que si l'équipe a déjà implémenté des fonctionnalités similaires auparavant, la répéter sera beaucoup plus facile la deuxième fois.

Cependant, vous devriez probablement expliquer que chaque application est différente. Ce n'est pas parce que vous avez installé une porte dans une maison que vous pouvez installer une autre porte dans une autre maison en un rien de temps - vous serez plus rapide grâce à l'expérience (nombre de portes installées), mais il faudra encore du temps pour obtenir votre équipement , montez la porte, assurez-vous qu'elle est d'aplomb et vissez-la dans le cadre.

dans mon entreprise, nous travaillons toujours avec des classes et des méthodes, et faisons de la documentation technique pour eux. Je pense que c'est la meilleure pratique si vous pouvez utiliser vos propres applications de recherche svn avec de bonnes clés pour trouver la classe de méthode utilisée auparavant :)