Pourquoi le "copier-coller" du code est-il dangereux?
Parfois, mon patron se plaindra à nous:
Pourquoi avons-nous besoin d'un temps aussi long 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 patron non technique?
Si vous trouvez un bogue dans votre code copier-coller, vous devrez le corriger à chaque endroit que vous avez fait et espérons que vous pourrez vous en souvenir tous (cela vaut également pour les exigences modifiées).
Si vous conservez la logique en un seul endroit, il est plus facile de changer en cas de besoin (donc si vous décidez que l'application doit être mise à jour, vous ne le faites qu'en un seul endroit).
Demandez à votre patron de lire le principe SEC (Ne vous répétez pas).
Ce que vous décrivez ressemble à une utilisation parfaite pour les bibliothèques , où vous partagez du code et ne le conservez qu'au même endroit.
Je ne copierais/collerais du code que si j'avais l'intention de refactoriser peu de temps après - en m'assurant d'avoir extrait 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.
La raison évidente est que vous contractez une `` dette '' pour l'avenir: toute modification que vous devrez apporter au code (et pas seulement les corrections de bugs, toute modification) coûtera désormais deux fois plus cher car vous devez mettre à jour deux emplacements - et plus risqué parce que vous en oublierez éventuellement un. En d'autres termes, le rendre plus rapide maintenant rendra votre travail encore plus lent à l'avenir, ce qui peut être un bon sens des 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 erronée. Chaque fois que votre code dépend de suppositions tacites pour être correct, le copier dans un autre endroit entraîne des erreurs, à moins que ces hypothèses ne tiennent également dans le nouvel endroit. Par conséquent, le code collé est souvent erroné dès le début et pas seulement après la prochaine modification.
Du point de vue de la conception, le code copié-collé est certainement un désastre, avec le potentiel de causer beaucoup de problèmes à l'avenir. Mais vous demandez pourquoi cela vous prend beaucoup de travail maintenant, la réponse est: parce que ce n'est pas seulement copier et coller.
Si le code d'origine a été écrit afin d'être réutilisé, en tant que bibliothèque assez indépendante, avec une flexibilité et une utilisation client à l'esprit - alors 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 à ceci:
- "Bien sûr, j'ai déjà un code qui fait exactement ça!"
- "Attendez, laquelle de ces cinq versions de code est celle que je veux utiliser comme source?"
- "Hmmm, à quoi servent toutes ces fonctions 'util_func_023'? Je ne les ai pas documentées? De lesquelles ai-je besoin maintenant?"
- "Oh, oui, ce code utilise le code de base Y. Je suppose que je dois [choisissez-en 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 la fonction que je veux de Code Base Y]. "
- "J'ai tout copié, yay!"
- "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 que 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 un 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 sali avec le moins possible - même s'il s'agit d'une copie et non de l'original lui-même.
Si vous voulez baser votre projet sur le copier-coller, vous devez coder pour commencer d'une manière qui permettra une réutilisation facile, sans pour autant copier ce code original et déconner avec. Cela en vaut la peine, et si c'est ce à quoi votre patron s'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 de se produire. Votre patron devrait évaluer très tôt le prix de l'expédition par rapport au prix de l'envoi du code cassé à l'utilisateur final.
Si vous avez déjà implémenté les fonctionnalités et que vous avez besoin de copier-coller pour les réutiliser, il semble que vous ayez fait quelque chose de mal. Vous ne pouvez pas mettre ces fonctionnalités dans une bibliothèque afin de pouvoir les réutiliser sans copier/coller?
Le principe DRY (Ne vous répétez pas): DRY sur wikipedia .
"Chaque élément de connaissance doit avoir une représentation unique, non ambiguë et faisant autorité au sein d'un système."
Cela me semble être la pire idée fausse que votre patron non technique ait, c'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 qui ne tape pas. Même si la plupart de ce travail se produit généralement de manière invisible, dans votre tête, en même temps que la frappe.
Bien sûr, l'élimination de la frappe fera gagner du temps. Mais alors, la partie beaucoup plus grande, sans dactylographie, de votre travail devient plus grande et consomme du temps et plus encore.
Êtes-vous sûr que votre patron veut entendre parler du principe DRY, des bugs et autres trucs techniques?
Ce genre de commentaires que vous entendez habituellement lorsque votre patron ou votre entreprise a sous-estimé le temps nécessaire pour terminer un projet. Et sur la base d'une estimation erronée, un contrat a été signé, etc. Dans la plupart des cas, les programmeurs n'étaient pas impliqués dans les estimations.
Pourquoi ça arrive? Parfois, le sponsor du projet a un budget trop petit. Un processus métier que vous automatisez à l'aide d'un logiciel ne vaut peut-être pas la peine de votre travail d'é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 ne marche de la mort .
Copier et coller du code conduit généralement à Programmation par coïncidence
Je pense que "ne autre application" est la clé ici, si l'autre application est déjà testée et utilisée, elle devrait ne pas être modifiée pour utiliser une bibliothèque commune, donc vous pouvez ' t partager le code avec elle.
Au sein de la même application, le "copier-coller" est mauvais, mais entre des bases de code développées par différentes équipes ou avec différents cycles de publication, le "copier-coller" peut être la meilleure option.
J'ai travaillé pour une entreprise similaire. En tant que stagiaire, je ne savais pas mieux alors, alors quand j'ai commencé un nouveau projet, mon patron a également suggéré de coller le code ailleurs. Eh bien, comme vous pouvez le penser, l'ensemble du logiciel était un vrai gâchis, au point que lorsque vous avez essayé de corriger un bogue, deux nouveaux bogues sont apparus.
Même si l'autre application possède déjà la fonctionnalité dont vous avez besoin, le code de cette fonctionnalité peut tout simplement ne pas correspondre à votre application actuelle sans une réécriture majeure. C'est comme prendre le moteur d'une Ford et essayer de l'intégrer dans une Toyota. En règle générale, il existe une règle générale 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 convaincante, mais cela pourrait ê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 les modifier tous manuellement. Si votre patron ne sait pas (ou veut savoir) pourquoi le copier/coller est mauvais, il pourrait aussi bien le croire :)
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 termes de correction de bogues et de modifications à l'échelle du système et de maintenance 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'un parc de véhicules, mais avec les logiciels, les aspects brisés de l'architecture logicielle sont généralement cachés du côté des entreprises et ne peuvent être vus que par les développeurs.
Oui, le plus gros problème est que ce n'est pas seulement copier-coller - sa copie puis coller puis modifier légèrement.
Plus tard, lorsque l'une des variantes collées a un problème, elle est modifiée. 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 bugs. Maintenant, vous êtes bel et bien foutu parce que 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 vide 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 faisant chaque chose particulière, alors vous avez un système.
Les comportements d'un système peuvent être modifiés avec des modifications ponctuelles assez facilement - changer le comportement d'un tas de code nécessite un tas de code.
J'aime les systèmes, pas un tas de code.
Il a raison de dire que si l'équipe a déjà implémenté des fonctionnalités similaires, la répéter sera beaucoup plus facile la 2ème fois.
Cependant, vous devez 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 pas de temps plat - vous serez plus rapide à cause de l'expérience (# portes installées), mais cela prenez toujours le temps de vous procurer l'é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 :)