Qual è un buon modo conciso per spiegare i pericoli della programmazione copia-incolla ai non programmatori? [chiuso]

Sto cercando una buona analogia o metafora che possa illustrare i problemi della programmazione copia-incolla ai non programmatori. Occasionalmente eseguo revisioni di codice / sistema per potenziali clienti e uno dei problemi comuni che vedo sono enormi quantità di codice copia-incolla su tutte le loro basi di codice. È qualcosa che chiamo abitualmente nelle recensioni e ogni volta devo spiegare perché questo è un problema (questo è particolarmente difficile con i clienti che sanno abbastanza sulla programmazione per capire che il riutilizzo è una buona cosa, ma non abbastanza per capire perché copia-incolla non è una buona forma di riutilizzo). Ovviamente, posso (e fare) spiegare il problema in termini di manutenzione del codice, ma sarebbe bello avere una buona e concisa analogia per questo problema che colpirebbe i programmatori. Bonus se l'analogia mostra perché la ricerca e sostituzione non è una soluzione efficace per questo problema. Eventuali suggerimenti?

Solo per chiarire (in base alla risposta di Jaroslav di seguito) - Non sto parlando di utilizzare frammenti di codice qui; quello che vedo (spesso in modo inquietante) è la copia e incolla di vaste strisce di codice, o un pezzo di codice a dieci righe per ottenere alcuni dati utente (completi di query SQL incorporata) incollati in dozzine di pagine PHP o ASP.NET. Quindi, duplica il codice da un'altra parte dello stesso progetto.

Aggiornamento: ci sono molte risposte davvero buone qui; Ho spiegato nei commenti perché ho scelto la risposta di Scott Whitlock, ma raccomanderei caldamente anche la risposta di whatsisname se hai a che fare con clienti che hanno familiarità con la produzione.

È così ... hai un orologio in casa. Grande! Sai che ore sono, ma devi sempre andare in quella stanza per vederlo.

Ma ovviamente vuoi sapere che ore sono senza andare in quella stanza per tutto il tempo, quindi acquisti altri orologi e li distribuisci in casa. Ognuno di questi orologi è indipendente. Tutti mantengono il proprio tempo. Questo significa:

• Quando l'ora cambia a causa dell'ora legale, è necessario modificarle tutte
• Anche quando sono tutti impostati, sono tutti un po 'diversi e raramente concordano perfettamente. Nel corso del tempo vanno alla deriva.

Ora immagina lo stesso problema in una grande struttura con dozzine o centinaia di orologi. Ecco perché hai bisogno di qualcosa come questo orologio in rete che si sincronizza con una base dei tempi centrale. In questo modo il tempo viene definito una volta e una sola volta .

La programmazione di copia e incolla è come acquistare più orologi indipendenti. Non si ridimensiona.

Immagina di progettare un aereo. Hai un solo motore a reazione. Si vende bene. Ora progetterai un aereo a 4 motori per lunghi tragitti attraverso l'oceano.

Ora, non crei un set completo di specifiche tecniche e disegni per ogni singolo motore, vero? No, usi lo stesso motore in tutti e quattro i posti. Ora immagina di avere 4 serie di disegni e di dover cambiare qualcosa. Ora è necessario modificarlo in tutti e quattro i disegni del motore. Cosa succede se dimentichi accidentalmente di cambiare qualcosa nel 4 ° motore perché stavi distanziando?

Quindi supponiamo che tu stia cambiando la lunghezza di una vite o una filettatura del tubo. Ora non puoi semplicemente "cercare e sostituire" nel tuo database di disegni tecnici, potresti accidentalmente cambiare le viti di montaggio nelle pompe del carburante perché avevano le stesse dimensioni. Oppure la linea idraulica che alimenta il timone della coda utilizzava lo stesso filo, ma ora è diversa e non puoi più alimentare la coda.

Ora immagina di essere infastidito dall'NTSB perché i tuoi motori lanciano casualmente le pale della turbina ed esplodono mentre volano a sud della Florida. Ora quali disegni del motore guardi? Tutti loro, uno di loro? Come fai a sapere che tutti e quattro sono uguali? Forse le correzioni sono state fatte, ma sono applicate solo al motore uno, perché il ragazzo che ha progettato i motori è partito un anno fa per suonare in una band reggae ed è stato l'unico a ricordare che i quattro motori sono in file separati, e il il ragazzo che ha riparato la turbina che esplode era il suo sostituto.

Copiare e incollare il codice è analogo ad avere disegni duplicati di parti componenti, siano esse una vite o un motore. Vuoi astrarre componenti fino a pezzi fondamentali che vengono riutilizzati il ​​più possibile.

Non duplicare i motori, basta scrivere il codice che monta i motori sull'ala.

Devi spiegarlo in termini di condivisione della stessa risorsa rispetto alla duplicazione della stessa risorsa.

Ad esempio, avrebbe senso per ogni casa in una grande città avere una centrale elettrica dedicata che fornisce elettricità alla casa o avrebbe più senso che ogni casa condivida la stessa centrale elettrica? Se qualcosa va storto con un particolare componente utilizzato nelle centrali elettriche e sono necessarie riparazioni, sarebbe più facile effettuare le riparazioni in un unico posto e tutti traggono beneficio da queste riparazioni rispetto alle riparazioni in ciascuna centrale elettrica dedicata e solo benefici della casa individualmente.

"Ehi, guarda, tutti gli interventi chirurgici sono in qualche modo simili, vero? Quindi non ti dispiacerebbe se copio casualmente istruzioni chirurgiche per procedure diverse da chirurghi diversi per la tua operazione?"

Copia e incolla è come provare a produrre parti senza stampo. È lento e otterrai un utilizzo una tantum da ciascuna parte, poiché una volta determinato che è difettoso o rotto, non puoi semplicemente riparare lo stampo per creare un sostituto adatto.

Nella ricerca di un'analogia, per prima cosa dobbiamo considerare i pericoli della programmazione copia e incolla :

• Bug introdotti perché la copia non si adatta esattamente (variabili non necessarie e percorsi del codice non ripuliti)
• Maggiori requisiti di test : l'astrazione aiuta a rimuovere la necessità di test di regressione mentre testate solo ciò che avete cambiato e cambiate solo le foglie, non i rami.
• La duplicazione duplica tutto, bug inclusi. Ogni correzione di bug o funzionalità che si applica a entrambe le sezioni di codice ora costa il doppio dell'implementazione e c'è un'alta probabilità di dimenticarlo completamente.
• La ricerca e la sostituzione aggrava il problema sopra riportato, poiché non è possibile trovare facilmente il codice duplicato.

L'arma principale nella lotta contro la programmazione copia e incolla è l' astrazione . Quindi, per trovare una buona analogia, cerca esempi di astrazione nel mondo che ci circonda.

L'astrazione si basa sull'idea di impostare definizioni e quindi procedere all'utilizzo di tali definizioni nell'esecuzione. Come sarebbe il mondo senza definizioni?

• Le definizioni sono una parte fondamentale del linguaggio legale. Immagina un contratto che non avesse definizioni fondamentali ma che fosse completamente definito ogni volta che veniva usato.
• Definizioni e modelli sono utilizzati nella costruzione. Un problema comune nella costruzione è fare ogni nuovo taglio basato sull'ultimo piuttosto che su una singola misurazione presa all'inizio. Ciò può comportare lunghezze selvaggiamente variabili nel tempo.
• L'organizzazione aziendale si basa su abstract e definizioni. E se ogni volta che la tua azienda dovesse espandersi, dovrebbero definire da zero il nuovo ruolo? Non funzionerebbe. E se decidessero di scegliere un ruolo lavorativo simile e modificarlo leggermente per adattarlo. Tutti sarebbero bloccati in posizione perché sarebbe impossibile spostare le risorse.

La copia ha un posto solo quando il pezzo da copiare è permanente. Altrimenti, ogni copia crea un nuovo ramo da gestire: testato, gestito e aggiornato separatamente.

L'astrazione combatte questo legando tutti i rami insieme in un tronco e isolando le modifiche a rami più piccoli o persino foglie.

Penso che stai parlando di codice duplicato, non di copia e incolla (usando snippet e simili).

Ecco un'analogia da un libro di storia, che la illustra molto bene. Prima della stampa di Gutenberg i monaci erano seduti e scrivevano i libri a mano e riscrivevano lo stesso libro più volte. I libri che i monaci scrivevano erano spesso con bug e grazie a Gutenberg questo problema veniva eliminato.

Un'altra analogia: i bancomat. Hai un bancomat in grado di servire varie carte e sempre bene. La duplicazione del codice crea diversi bancomat, quindi ognuno dovrebbe sceglierne uno diverso e a volte la macchina potrebbe persino darti un BSOD.

C'è un fantastico articolo sull'incollaggio di copie da Jeff http://www.codinghorror.com/blog/2009/04/a-modest-proposal-for-the-copy-and-paste-school-of-code-reuse. html

PS So che prima di Gutenberg c'era una macchina da stampa.

Con i non programmatori presumo che stiamo parlando di uomini d'affari, quindi sarei breve e coinvolgerei le realtà del denaro.

1. Ogni riga di codice ti costa denaro (scritta o copiata)
2. Ogni bug ti costa molto di più di ogni riga.
3. Ogni riga di codice aggiunge potenziali bug
4. Codice duplicato = bug duplicati
5. I bug duplicati non si trovano quasi mai nello stesso ciclo di test.

Taglia e incolla = Burning Money.

Non posso rispondere alla domanda ma dire che qui non hai davvero bisogno di un'analogia e cercare di trovare l'analogia giusta per ogni linguaggio o modello di sviluppo sembra perverso ed è spesso controproducente. È come provare a fare yoga con i piedi piatti ...

Ci sono alcuni motivi per cui copia / incolla porta a problemi, propaga i bug esistenti in aree appena incollate, in alcuni ambienti in cui era considerato un miglioramento delle prestazioni, in realtà ora è più lento (posso fornire esempi se qualcuno è interessato, ma dipende da JIT e pensi davvero di essere più intelligente di un compilatore moderno?).

Mostra che lo sviluppatore è pigro o egoista o entrambi. Se questa è una battaglia che stai combattendo in una squadra in questo momento, a seconda della tua posizione in questa squadra (responsabile della squadra / jnr dev, snr dev, qualunque cosa) devi farla riparare, possibilmente per arbitrato all'interno della tua organizzazione.

EDIT: Alla luce del commento qui sotto, che si tratta di revisione del codice di terze parti per conto di terze parti (o forse anche di una quarta parte :)) Ci sono alcune cose utili che posso aggiungere con speranza.

Innanzitutto, quando il codice è stato prodotto per la terza parte, disponevano di metriche? Linee di codice (LoC) per esempio.

Penso ancora che alcune delle cose che ho detto sopra contino ancora. Probabilmente avrei dovuto anche chiedere quale fosse l'obiettivo della recensione. Se è necessario ottenere un preventivo per mantenerlo o sostituirlo, è necessario porre molte domande diverse.

Ad ogni modo, stai valutando la qualità del codice, beh, copia qualsiasi incolla rientra nella categoria "Lo sviluppatore ha mostrato un'adeguata comprensione dell'astrazione e / o della progettazione del controllo del flusso del programma":

Commento: lo sviluppatore non è riuscito a mostrare alcuna comprensione dell'astrazione e il suo approccio al controllo del flusso del programma era soggetto a errori. Puoi introdurre "Complessità ciclomatica" qui. In realtà è abbastanza facile da capire, e in un certo senso penso che avrei potuto trovare una risposta: D Yay per me.

Ok La complessità ciclomatica è così. Hai una mappa. Ha la tua posizione iniziale e ogni possibile destinazione. Non deve essere molto. Pensa, parcheggio, bar, bagno. La complessità ciclomatica è una misura del numero di percorsi diversi che ci sono per arrivare alla posizione di partenza verso una delle destinazioni.

Il codice di copia e incolla probabilmente aumenterà la complessità ciclomatica perché includerà una logica ripetuta che potrebbe essere stata sottratta nel proprio blocco (o metodo).

Sembra ragionevole?

Prendi una parola inglese per qualcosa. Ora immagina ogni volta che vuoi descrivere quella cosa, hai usato la definizione completa del dizionario anziché solo la parola. Quanto sarebbe facile per gli altri capirti?

Ho formare un'immagine mentale di qualcosa che non è presente o non è questo il caso (immagino) si indica un'azione o stato che è subordinata in un altro; Passato semplice di volontà. Indica la futilità relativa a un tempo passato. Indicare un'azione in passato che è avvenuta ripetutamente o comunemente (sarebbe) non sarebbe abbastanza facile; che richiede un grande sforzo fisico o mentale per realizzare, comprendere o sopportare (difficile).

Inoltre, non sarebbe male mostrare un esempio reale prima e dopo del codice reale che è stato refactored per rimuovere la duplicazione.

Esistono inoltre problemi di sicurezza e integrità del codice.

Come dimostrato qui , è possibile incorporare dati dannosi in caratteri unicode trasferiti negli Appunti.

A seconda di come il tuo editor risponde ai caratteri unicode, ciò può comportare cambiamenti inattesi del codice sorgente, output del compilatore imprevisti o alcune cose a cui non ho ancora pensato.

Ci sono un paio di percorsi diversi che ho potuto vedere prendendo qui:

1. Plagio - Alcuni potrebbero ricordarlo dalla scuola in cui il furto della proprietà intellettuale è un grande no-no. La programmazione di copia e incolla può essere proprio così poiché qualcuno potrebbe non capire l'origine o quali gotcha potrebbero derivare dall'uso di una particolare soluzione che è stata semplicemente copiata e incollata alla cieca senza analizzare quanto bene funziona e capire perché questo potrebbe essere o meno una soluzione efficace al problema.

2. Seguire ciecamente le indicazioni - La maggior parte delle persone avrebbe probabilmente avuto esperienze dovendo arrivare in un posto in cui non era mai stata in precedenza. Alcuni potrebbero aver utilizzato MapQuest o Google Maps per trovare un luogo e quindi seguire le indicazioni fornite. Ci sono state storie di persone che si sono perse o semplicemente non hanno trovato dove avrebbero dovuto essere, anche se il software ha dato istruzioni specifiche su come arrivarci. Questo è l'altro grande pericolo del copia-incolla è che è come se qualcuno ti avesse appena consegnato le indicazioni per andare da A a B senza farti vedere alcuna mappa della zona che potrebbe rendere un viaggio leggermente più difficile. Se ciò non sembra difficile, potresti alzare la posta chiedendo alla persona di andare da A a B indossando una benda in modo che debbano fare affidamento su altri sensi per determinare quale direzione stanno affrontando e raggiungere un obiettivo.

Dati, informazioni, conoscenza e saggezza possono essere un buon modello a cui si può fare riferimento per mostrare perché la ricerca e la sostituzione non sono efficaci come soluzione perché il copia e incolla è molto meccanico e senza pensarci tanto che i dati trasferiti potrebbero essere senza la conoscenza e la saggezza di usarlo correttamente. Si potrebbe guardare l'energia nucleare per esempi di come comprendere la differenza può essere abbastanza potente. Contrasta un reattore nucleare con una bomba nucleare in termini di sicurezza e uso per vedere come sapere esattamente cosa va dove non è abbastanza per sfruttare in sicurezza il potere dell'atomo.

Immagina di avere un gruppo di studenti e un insieme di regole per la scuola. Invece di pubblicare le regole in un luogo comune, tutti gli studenti devono fare riferimento a ciascuna mano una copia delle regole. A ogni studente viene detto che devono seguire la loro copia delle regole alla lettera.

Ora modifica una delle regole dicendo che in caso di disastro dovresti andare al nuovo rifugio. Devi andare da ogni studente e modificare il loro insieme di regole. Se uno degli studenti viene perso e un tornado colpisce lo studente andrà nel vecchio posto e morirà di una morte orribile.

Qualcuno ti invia un'e-mail con un modello di documento allegato. Sentiti libero di continuare a usarlo fino a quando il modello non cambia. Non ti preoccupare, non dimenticheranno di inviarti una copia aggiornata.

Il modello di costo CoCoMo.

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

Sforzo applicato (E) = a * (KLOC) ** b, dove b> 1.0

Tale esponente significa che lo sforzo di costruire / mantenere / supportare / riscrivere cresce più rapidamente del numero di righe di codice.

C'è un altro aspetto importante di questa cattiva pratica che nessuno ha ancora preso in considerazione: copiando ciecamente il codice (completo o parziale) da qualcun altro ( senza la sua autorizzazione ) potresti infrangere le leggi sul copyright .

La codifica copia-incolla che vedo è quella in cui lo sviluppatore non capisce o non vuole ragionare su ciò che sta facendo e copia insieme parti diverse che già fanno "più o meno" ciò di cui hanno bisogno, scuotendole casualmente alla fine per farli stare insieme.

Ci sono tre problemi principali in questo:

1. Non risulta mai in codice privo di bug. Mai.
2. Se non hanno capito il codice durante la scrittura, non sono mai riusciti a capirlo durante il debug. Solo qualcun altro può ripulire il disastro che hanno fatto, a un costo aggiuntivo.
3. Se evitano di pensare al codice che stanno scrivendo, evitano di imparare. Se evitano di imparare, non saranno mai un buon programmatore. Se non saranno mai un buon programmatore, perché fanno parte della tua squadra?

Supponiamo che tu abbia 5 ragazze (sei un furbo cane) e desideri inviare a tutte loro un messaggio di San Valentino. Digiti la prima lettera, aggiungi il suo nome e menzioni qualcosa di memorabile che avete condiviso. Quindi copia e incolla la lettera quattro volte, ogni volta manca un'istanza del nome della ragazza n. 1 con copia e incolla perché hai fatto un errore di battitura. Ora, 4 delle tue cinque ragazze stanno andando a casa della ragazza n. 1.