Quelle est une bonne façon concise d'expliquer les dangers de la programmation copier-coller à des non-programmeurs? [fermé]

Je cherche une bonne analogie ou métaphore qui pourrait illustrer les problèmes de programmation copier-coller pour les non-programmeurs. Je fais de temps en temps des revues de code / système pour des clients potentiels, et l'un des problèmes communs que je vois sont de grandes quantités de code copier-coller sur toutes leurs bases de code. C'est quelque chose que j'appelle régulièrement dans les critiques, et chaque fois je dois expliquer pourquoi c'est un problème (c'est particulièrement difficile avec les clients qui en savent juste assez sur la programmation pour comprendre que la réutilisation est une bonne chose, mais pas assez pour comprendre pourquoi copier-coller n'est pas une bonne forme de réutilisation). Évidemment, je peux (et je fais) expliquer le problème en termes de maintenance de code, mais ce serait bien d'avoir une bonne analogie concise pour ce problème qui toucherait les non-programmeurs. Bonus si l'analogie illustre pourquoi la recherche et le remplacement ne sont pas une solution efficace à ce problème. Aucune suggestion?

Juste pour clarifier (basé sur la réponse de Jaroslav ci-dessous) - Je ne parle pas d'utiliser des extraits de code ici; ce que je vois (de manière inquiétante souvent), c'est copier-coller de vastes étendues de code, ou un morceau de code de dix lignes pour obtenir des données utilisateur (avec requête SQL en ligne) collées dans des dizaines de pages PHP ou ASP.NET. Donc, dupliquez le code d'ailleurs dans le même projet.

Mise à jour: Il y a plusieurs très bonnes réponses ici; J'ai expliqué dans les commentaires pourquoi j'ai choisi la réponse de Scott Whitlock, mais je recommanderais également très, fortement la réponse de whatsisname si vous avez affaire à des clients qui sont familiers avec la fabrication.

C'est comme ça ... vous avez une horloge dans votre maison. Génial! Vous savez quelle heure il est, mais vous devez toujours aller dans cette seule pièce pour la regarder.

Mais bien sûr, vous voulez savoir quelle heure il est sans aller tout le temps dans cette pièce, alors vous achetez plus d'horloges et vous les distribuez dans votre maison. Chacune de ces horloges est indépendante. Ils gardent tous leur temps. Ça signifie:

• Lorsque l'heure change en raison de l'heure d'été, vous devez tous les changer
• Même quand ils sont tous prêts, ils sont tous un peu différents et s'accordent rarement parfaitement. Au fil du temps, ils dérivent.

Imaginez maintenant le même problème dans une grande installation avec des dizaines ou des centaines d'horloges. C'est pourquoi vous avez besoin de quelque chose comme cette horloge en réseau qui se synchronise avec une base de temps centrale. De cette façon, le temps est défini une fois et une seule fois .

La programmation par copier-coller revient à acheter des horloges plus indépendantes. Il ne se redimensionne pas.

Imaginez que vous concevez un avion. Vous avez un seul jet de moteur. Ça se vend bien. Vous allez maintenant concevoir un avion à 4 moteurs pour de longs trajets à travers l'océan.

Maintenant, vous ne créez pas un ensemble complet de spécifications techniques et de dessins pour chaque moteur individuel, n'est-ce pas? Non, vous utilisez le même moteur aux quatre endroits. Imaginez maintenant si vous aviez 4 jeux de dessins et que vous deviez changer quelque chose. Vous devez maintenant le modifier dans les quatre dessins du moteur. Que se passe-t-il si vous oubliez accidentellement de changer quelque chose dans le 4e moteur parce que vous espaciez?

Disons que vous modifiez la longueur d'une vis ou d'un filetage de tuyau. Maintenant, vous ne pouvez pas simplement "rechercher et remplacer" dans votre base de données de dessins techniques, vous pouvez accidentellement changer les vis de montage dans les pompes à carburant car elles se trouvaient être de la même taille. Ou la ligne hydraulique alimentant le gouvernail de queue utilisait le même fil, mais maintenant c'est différent et vous ne pouvez plus alimenter la queue.

Imaginez maintenant que le NTSB vous tracasse parce que vos moteurs lancent des aubes de turbine au hasard et explosent en volant au sud de la Floride. Maintenant, quels dessins de moteur regardez-vous? Tous, l'un d'eux? Comment savez-vous que les quatre sont identiques? Peut-être que les corrections sont faites, mais elles ne s'appliquent qu'au moteur un, car le gars qui a conçu les moteurs est parti un an en arrière pour jouer dans un groupe de reggae et était le seul à se rappeler que les quatre moteurs sont dans des fichiers séparés, et le gars qui a réparé la turbine qui explose était son remplaçant.

Copier et coller du code est analogue à avoir des dessins en double des composants, que ce soit une vis ou un moteur. Vous voulez résumer les composants en pièces fondamentales qui sont réutilisées autant que possible.

Ne dupliquez pas les moteurs, écrivez simplement le code qui monte les moteurs sur l'aile.

Vous devez l'expliquer en termes de partage de la même ressource par rapport à la duplication de la même ressource.

Par exemple, serait-il logique que chaque maison dans une grande ville ait une centrale électrique dédiée fournissant de l'électricité à la maison ou serait-il plus logique que chaque maison partage la même centrale électrique? Si quelque chose ne va pas avec un composant particulier utilisé dans la ou les centrales électriques et que des réparations sont nécessaires, il serait plus facile de faire les réparations en un seul endroit et tout le monde profite de ces réparations par rapport aux réparations dans chaque centrale électrique dédiée et uniquement dans chaque avantages de la maison individuellement.

« Hey Regardez tous la chirurgie est un peu similaire à droite ?, si vous ne me dérangerait pas si je hasard copie chirurgicale instruction des procédures différentes de différents chirurgiens pour votre opération? »

Copier et coller, c'est comme essayer de fabriquer des pièces sans moule. C'est lent et vous obtiendrez une utilisation unique de chaque pièce, car une fois qu'il est déterminé qu'il est défectueux ou cassé, vous ne pouvez pas simplement réparer le moule pour créer un remplacement approprié.

Dans la recherche d'une analogie, nous devons d'abord considérer les dangers de la programmation par copier-coller :

• Bogues introduits car la copie n'est pas un ajustement exact (variables inutiles et chemins de code non nettoyés)
• Exigences de test accrues - l'abstraction permet de supprimer le besoin de tests de régression car vous ne testez que ce que vous avez changé, et vous ne changez que les feuilles, pas les branches.
• La duplication duplique tout, bugs inclus. Chaque correction de bogue ou fonctionnalité qui s'applique aux deux sections de code coûte désormais deux fois plus cher à implémenter et il est fort probable de l'oublier complètement.
• La recherche et le remplacement aggravent le problème ci-dessus, car vous ne pouvez pas facilement trouver le code dupliqué.

L'arme principale dans la lutte contre la programmation par copier-coller est l' abstraction . Donc, pour trouver une bonne analogie, cherchez des exemples d'abstraction dans le monde qui nous entoure.

L'abstraction est basée sur l'idée de mettre en place des définitions puis de continuer à utiliser ces définitions en exécution. À quoi ressemblerait le monde sans définitions?

• Les définitions sont un élément clé du langage juridique. Imaginez un contrat qui n'avait pas de définitions de base, mais qui définissait pleinement chaque terme à chaque fois qu'il était utilisé.
• Les définitions et les modèles sont utilisés dans la construction. Un problème courant dans la construction consiste à faire chaque nouvelle coupe sur la base de la dernière plutôt que sur une seule mesure prise au début. Cela peut entraîner des longueurs très variables dans le temps.
• L'organisation de l'entreprise est basée sur des résumés et des définitions. Et si chaque fois que votre entreprise devait se développer, elle devait définir le nouveau rôle à partir de zéro? Ça ne marcherait pas. Alors, s'ils décident de choisir un rôle similaire et de le modifier légèrement en fonction de leurs besoins. Tout le monde serait enfermé car il serait impossible de déplacer des ressources.

La copie n'a de place que lorsque la pièce copiée est permanente. Sinon, chaque copie crée une toute nouvelle branche à traiter - testée, maintenue et mise à niveau séparément.

L'abstraction combat cela en attachant toutes les branches ensemble dans un seul tronc et en isolant les modifications des branches plus petites ou même des feuilles.

Je pense que vous parlez de code en double, pas de copier-coller (à l'aide d'extraits de code et similaires).

Voici une analogie d'un livre d'histoire qui l'illustre très bien. Avant la presse de Gutenberg, les moines étaient assis et écrivaient les livres à la main et réécrivaient le même livre encore et encore. Les livres que les moines écrivaient étaient souvent avec des bugs et grâce à Gutenberg ce problème a été éliminé.

Autre analogie: les distributeurs automatiques de billets. Vous avez un distributeur automatique de billets qui peut servir différentes cartes et les sert toujours bien. La duplication de code crée différents distributeurs automatiques de billets, donc tout le monde devrait aller à un autre et parfois la machine vous donnerait même un BSOD.

Il y a un article génial sur le copier-coller de Jeff http://www.codinghorror.com/blog/2009/04/a-modest-proposal-for-the-copy-and-paste-school-of-code-reuse. html

PS Je sais qu'il y avait une presse à imprimer avant Gutenberg.

Aux non-programmeurs, je suppose que nous parlons de gens d'affaires, donc je serais bref et impliquerais les réalités de l'argent.

1. Chaque ligne de code vous coûte de l'argent (qu'elle soit écrite ou copiée)
2. Chaque bug vous coûte beaucoup plus que chaque ligne.
3. Chaque ligne de code ajoute des bogues potentiels
4. Code dupliqué = bogues dupliqués
5. Les bogues dupliqués ne sont presque jamais détectés dans le même cycle de test.

Couper et coller = Burning Money.

Puis-je ne pas répondre à la question mais dire que vous n'avez vraiment pas besoin d'une analogie ici, et essayer de trouver la bonne analogie pour chaque idiome ou modèle de développement semble pervers et est souvent contre-productif. C'est comme essayer de faire du yoga avec les pieds plats ...

Il y a quelques raisons pour lesquelles le copier / coller entraîne des problèmes, il propage les bogues existants dans les zones nouvellement collées, dans certains environnements où il était considéré comme une amélioration des performances, il est en fait maintenant plus lent (je peux fournir des exemples si quelqu'un est intéressé, mais cela revient à JIT et pensez-vous vraiment que vous êtes plus intelligent qu'un compilateur moderne?).

Cela montre que le développeur est paresseux ou égoïste ou les deux. Si c'est une bataille que vous livrez en équipe en ce moment, en fonction de votre position dans cette équipe (chef d'équipe / développeur jnr, développeur snr, quoi que ce soit), vous devez le corriger, éventuellement par arbitrage au sein de votre organisation.

EDIT: à la lumière du commentaire ci-dessous, qu'il s'agit d'un code examinant le code tiers au nom du tiers (ou peut-être même d'un quatrième parti :)) Il y a certaines choses utiles que je peux ajouter avec espoir.

Premièrement, lorsque le code a été produit pour le tiers, y avait-il des mesures en place? Lignes de code (LoC) par exemple.

Je pense toujours qu'une partie de ce que j'ai dit ci-dessus compte toujours. J'aurais probablement dû aussi demander quel était le but de l'examen. Si c'est pour obtenir un devis pour le maintenir ou le remplacer, vous devez poser beaucoup de questions différentes.

Quoi qu'il en soit, vous évaluez la qualité du code, eh bien, copier toute pâte relève de la catégorie "Le développeur a montré une compréhension adéquate de la conception de l'abstraction et / ou du contrôle du flux de programme":

Commentaire: Le développeur n'a pas montré de compréhension de l'abstraction et son approche du contrôle de flux de programme était sujette à des erreurs. Vous pouvez introduire ici la "complexité cyclomatique". C'est en fait assez facile à comprendre, et en un sens, je pense que j'aurais pu trouver une réponse: D Yay pour moi.

Ok, la complexité cyclomatique est comme ça. Vous avez une carte. Il a votre position de départ et toutes les destinations possibles. Cela ne doit pas nécessairement être beaucoup. Pensez, parking, café, toilettes. La complexité cyclomatique est une mesure du nombre d'itinéraires différents disponibles pour se rendre à votre position de départ vers l'une des destinations.

Le code copié et collé augmentera probablement la complexité cyclomatique car il inclura une logique répétée qui aurait pu être abstraite dans son propre bloc (ou méthode) nommé.

Semble raisonnable?

Prenez un mot anglais pour quelque chose. Imaginez maintenant que chaque fois que vous vouliez décrire cette chose, vous utilisiez la définition complète du dictionnaire au lieu du simple mot. Serait-il facile pour les autres de vous comprendre?

Je forme une image mentale de quelque chose qui n'est pas présent ou qui n'est pas le cas (imaginez) cela Indiquant une action ou un état qui est conditionnel à un autre; Passé simple de volonté. Indiquant la futurité par rapport à un temps passé. Indiquer une action dans le passé qui s'est produite de manière répétée ou courante (serait) assez difficile; nécessitant un grand effort physique ou mental pour accomplir ou comprendre ou endurer (difficile).

Cela ne ferait pas de mal non plus d'afficher un exemple avant et après de code réel qui a été refactorisé pour supprimer la duplication.

Il existe également des problèmes de sécurité et d'intégrité du code.

Comme démontré ici , il est possible d'incorporer des données malveillantes dans des caractères Unicode qui sont transférés dans le presse-papiers.

Selon la façon dont votre éditeur réagit aux caractères unicode, cela peut entraîner des modifications inattendues de votre code source, des sorties de compilateur inattendues ou certaines choses auxquelles je n'ai pas encore pensé.

Il y a quelques itinéraires différents que je pourrais voir prendre ici:

1. Plagiat - Certains s'en souviennent peut-être de l'école où le vol de propriété intellectuelle est un gros non. La programmation du copier-coller peut être comme ça car quelqu'un peut ne pas comprendre la source ou ce qui peut provenir de l'utilisation d'une solution particulière qui a été simplement copiée et collée aveuglément sans analyser dans quelle mesure cela fonctionne et comprendre pourquoi cela peut ou peut ne pas être une solution efficace au problème.

2. Suivre aveuglément les instructions - La plupart des gens auraient probablement eu des expériences pour se rendre dans un endroit où ils n'étaient pas auparavant. Certains peuvent avoir utilisé MapQuest ou Google Maps pour trouver un lieu, puis suivre les instructions données. Il y a eu des histoires de personnes se perdant ou ne trouvant tout simplement pas où elles étaient censées se trouver, même si le logiciel a donné des instructions précises sur la façon d'y arriver. C'est l'autre gros danger du copier-coller, c'est comme si quelqu'un vous donnait simplement les directions pour aller de A à B sans vous laisser voir une carte de la région qui pourrait rendre un voyage un peu plus difficile. Si cela ne semble pas difficile, vous pouvez monter la mise en demandant à la personne de se rendre de A à B avec un bandeau pour qu'elle doive s'appuyer sur d'autres sens pour déterminer la direction dans laquelle elle fait face et atteindre une cible.

Les données, les informations, les connaissances et la sagesse peuvent être un bon modèle qui pourrait être référencé pour montrer pourquoi la recherche et le remplacement ne sont pas efficaces comme solution car le copier-coller est très mécanique et sans beaucoup de réflexion pour que les données transférées puissent être sans la connaissance et la sagesse de l'utiliser correctement. On pourrait regarder l'énergie nucléaire pour des exemples de la façon dont la compréhension de la différence peut être assez puissante. Comparez un réacteur nucléaire avec une bombe nucléaire en termes de sécurité et d'utilisation pour voir comment savoir exactement ce qui va où ne suffit pas pour exploiter en toute sécurité la puissance de l'atome.

Imaginez que vous ayez un groupe d'élèves et un ensemble de règles pour l'école. Au lieu d'afficher les règles dans un lieu commun, tous les étudiants doivent se référer à vous et remettez à chacun une copie des règles. Chaque étudiant est informé qu'il doit suivre à la lettre sa copie du règlement.

Modifiez maintenant l'une des règles en disant qu'en cas de catastrophe, vous devez vous rendre dans le nouveau refuge pour sinistrés. Vous devez aller voir chaque élève et modifier son ensemble de règles. Si l'un des élèves est raté et qu'une tornade frappe, l'élève ira à l'ancien endroit et mourra d'une mort horrible.

Quelqu'un vous envoie un e-mail avec un modèle de document joint. N'hésitez pas à continuer à l'utiliser jusqu'à ce que le modèle change. Ne vous inquiétez pas, ils n'oublieront pas de vous envoyer une copie actualisée.

Le modèle de coût CoCoMo.

http://en.wikipedia.org/wiki/COCOMO

Effort appliqué (E) = a * (KLOC) ** b, où b> 1,0

Cet exposant signifie que l'effort de construction / maintenance / support / réécriture augmente plus rapidement que le nombre de lignes de code.

Il y a un autre aspect important de cette mauvaise pratique que personne n'a encore pris en considération: en copiant aveuglément (complet ou partiel) le code de quelqu'un d'autre ( sans leur permission ), vous pourriez enfreindre les lois sur le droit d'auteur .

Le codage copier-coller que je vois est celui où le développeur ne comprend pas ou ne veut pas raisonner ce qu'il fait, et copie ensemble différentes parties qui font déjà "plus ou moins" ce dont ils ont besoin, en les secouant au hasard à la fin pour les assembler.

Il y a trois problèmes majeurs à cela:

1. Il n'en résulte jamais de code sans bogue. Déjà.
2. S'ils ne comprenaient pas le code en l'écrivant, ils ne pourraient jamais le comprendre pendant le débogage. Seul quelqu'un d'autre peut nettoyer le gâchis qu'ils ont fait, à un coût supplémentaire.
3. S'ils évitent de penser au code qu'ils écrivent, ils évitent d'apprendre. S'ils évitent d'apprendre, ils ne seront jamais un bon programmeur. S'ils ne seront jamais un bon programmeur, pourquoi font-ils partie de votre équipe?

Disons que vous avez 5 copines (vous vous ruse) et que vous souhaitez leur envoyer un message de valentine. Vous tapez la première lettre, ajoutez son nom et mentionnez quelque chose de mémorable que vous avez partagé. Vous copiez et collez ensuite la lettre quatre fois, chaque fois qu'il manque une instance du nom de la petite amie # 1 avec copier-coller parce que vous avez fait une faute de frappe. Maintenant, 4 de vos cinq petites amies sont en route pour la maison de la petite amie # 1.