Perché "copiare e incollare" di codice è pericoloso? [chiuso]

A volte, il mio capo si lamenterà con noi:

Perché abbiamo bisogno di così tanto tempo per implementare una funzione?

In realtà, la funzione è stata implementata in un'altra applicazione prima, devi solo copiare e incollare i codici da lì. Il costo dovrebbe essere basso.

È davvero una domanda difficile, perché copiare e incollare i codici non è una cosa così semplice dal mio punto di vista.

Hai qualche buon motivo per spiegarlo al tuo capo non tecnico?

Se trovi un bug nel tuo codice copia-incolla, dovrai risolverlo in ogni posto che hai fatto e spero che tu possa ricordarli tutti (questo vale anche per i requisiti modificati).

Se mantieni la logica in un posto, è più facile cambiarla quando necessario (quindi se decidi che l'applicazione deve essere aggiornata, la fai solo in un posto).

Chiedi al tuo capo di leggere il principio DRY (non ripetere te stesso).

Quello che stai descrivendo sembra l'uso perfetto per le biblioteche , dove condividi il codice e lo conservi in ​​un solo posto.

Avrei sempre copiato e incollato il codice solo se avessi intenzione di riformattarlo subito dopo, assicurandomi in seguito di estrarre il codice comune in modo da poter riutilizzare quanta più logica possibile. E subito dopo intendo minuti e ore dopo, non giorni e settimane.

Sarebbe molto meglio condividere il codice creando una libreria piuttosto che copiarlo usando copia e incolla.

Otterrai comunque un vantaggio in termini di velocità rispetto alla riscrittura (cerca DRY) ma avrai solo un posto dove conservare il codice.

La ragione ovvia è che ti assumi un "debito" per il futuro: qualsiasi modifica che tu abbia mai bisogno di fare nel codice (non solo correzioni di bug, qualsiasi modifica) ora sarà due volte più costosa da fare perché devi aggiornare due posizioni - e più rischioso perché alla fine ne dimenticherai uno. In altre parole, farlo funzionare più velocemente ora renderà il tuo lavoro ancora più lento in futuro, il che può essere un buon senso degli affari ma di solito non lo è.

Ma la ragione più importante è che il presupposto "questo è lo stesso di quello" è più spesso che sottilmente sbagliato. Ogni volta che il codice dipende da presupposti non detti per essere corretto, copiarlo in un altro posto si traduce in errori a meno che questi presupposti non valgano anche nel nuovo posto. Pertanto, il codice incollato è spesso errato dall'inizio e non solo dopo la modifica successiva.

Per quanto riguarda il design, il codice incollato è sicuramente un disastro, con il potenziale per causare molti problemi in futuro. Ma ti stai chiedendo perché ti ci vuole molto lavoro in questo momento , la risposta è: perché non è mai solo copia e incolla.

Se il codice originale è stato scritto per essere riutilizzato, come una libreria abbastanza indipendente, tenendo conto della flessibilità e dell'uso del client - quindi fantastico, ma non è un copia-incolla, sta usando una libreria di codici. Il vero copia-incolla del codice di solito va più così:

• "Certo, ho già un codice che fa esattamente questo!"
• "Aspetta, quale di queste cinque versioni di codice è quella che voglio usare come fonte?"
• "Hmmm, cosa fanno tutte queste funzioni 'util_func_023'? Non le ho documentate? Di quali ho bisogno adesso?"
• "Oh, sì, questo codice utilizza Code Base Y. Immagino che devo [ sceglierne uno: copiare tutta la Code Base Y nel mio nuovo progetto / trascorrere un giorno districando l'unica funzione che desidero da Code Base Y / trascorrere una settimana districando il una funzione che desidero dalla base di codice Y]. "
• "Ho copiato tutto, yay!"
• "Perché non funziona?"
• Questo è il punto in cui impieghi ore / giorni / settimane a eseguire il debug del codice esistente simile a quello che desideri, invece di scrivere il codice con cui vuoi iniziare.

In sintesi, il codice esistente che non può essere utilizzato direttamente può, nella migliore delle ipotesi, servire da buon riferimento per la scrittura di codice simile. Certamente non può essere rimosso completamente e dovrebbe funzionare in un sistema completamente diverso. In generale, è un presupposto sicuro che qualsiasi codice che è stato scritto e completato, dovrebbe essere rovinato il meno possibile - anche quando si tratta di una copia e non dell'originale stesso.

Se vuoi basare il tuo progetto sul copia-incolla, devi iniziare con il codice in un modo che consenta un facile riutilizzo, senza copiare quel codice originale e fare casino con esso. Vale la pena farlo, e se questo è ciò che il tuo capo si aspetta, allora entrambi dovete assicurarvi che sia così che progettate e lavorate in primo luogo.

copia e incolla è un disastro in attesa di accadere. Il tuo capo dovrebbe valutare il prezzo della spedizione in anticipo rispetto al prezzo della spedizione del codice non funzionante all'utente finale molto presto.

Se avete già implementato le caratteristiche e hanno bisogno di copiare e incollare di riutilizzarli, suona come avete fatto qualcosa di sbagliato. Non puoi mettere queste funzionalità in una libreria in modo da poterle riutilizzare senza copia / incolla?

Il principio DRY (non ripetere te stesso): DRY su wikipedia .

"Ogni pezzo di conoscenza deve avere un'unica, inequivocabile, autorevole rappresentazione all'interno di un sistema."

altro collegamento .

Mi sembra che il peggior malinteso del tuo capo non tecnico sia che il tuo lavoro stia scrivendo prevalentemente. Pensano che puoi risparmiare molto tempo eliminando la digitazione.

Penso che la migliore educazione che potresti dare a questa persona sia quella di sottolineare tutto il lavoro che fai che non sta scrivendo. Anche se la maggior parte di quel lavoro di solito avviene in modo invisibile, nella tua testa, contemporaneamente alla digitazione.

Certo, eliminare la digitazione farà risparmiare un po 'di tempo. Ma poi la parte molto più grande, senza scrivere, del tuo lavoro diventa più grande e consuma tempo risparmiando e altro ancora.

Sei sicuro che il tuo capo voglia conoscere il principio DRY, i bug e altre cose tecniche?

Quel tipo di commenti che di solito senti quando il tuo capo o la tua azienda hanno sottovalutato il tempo necessario per completare un progetto. E sulla base di stime errate è stato firmato un contratto, ecc. Nella maggior parte dei casi i programmatori non sono stati coinvolti nelle stime.

Perché questo succede? A volte lo sponsor del progetto ha un budget troppo ridotto. Forse un processo aziendale che stai automatizzando utilizzando il software non vale lo sforzo del tuo team. I gestori in genere tendono ad essere molto chiusi per cattive notizie in questi casi. All'inizio del progetto c'è un pio desiderio. Quindi i manager cercano di incolpare i programmatori. Nel tuo caso indirettamente tramite copia e incolla. In casi estremi questa si chiama marcia della morte .

Copiare e incollare il codice di solito porta alla programmazione per coincidenza

Penso che " un'altra applicazione " sia la chiave qui, se l'altra applicazione è già testata e in uso, non dovrebbe essere cambiata per usare una libreria comune, quindi non puoi condividere il codice con essa.

All'interno della stessa applicazione , "copia e incolla" è un problema, ma tra basi di codice sviluppate da team diversi o con cicli di rilascio diversi, "copia e incolla" può essere l'opzione migliore.

Ho lavorato per un'azienda simile. Essendo un tirocinante, allora non lo sapevo meglio, quindi quando ho iniziato un nuovo progetto, il mio capo mi ha anche suggerito di incollare il codice da qualche altra parte. Bene, come puoi pensare, l'intero software è stato un bel casino, fino al punto che quando hai provato a correggere un bug, sono comparsi due nuovi bug.

Anche se l'altra applicazione ha già la funzione di cui hai bisogno, il codice per quella funzione potrebbe semplicemente non adattarsi alla tua attuale applicazione senza una riscrittura importante. È come prendere il motore di una Ford e provare a inserirlo in una Toyota. In genere, esiste una regola empirica secondo cui se si deve modificare più del 25% del codice copiato, è meglio (più economico) riscriverlo da zero.

L'estrazione del codice in questione in una libreria sembra avvincente, ma potrebbe essere più difficile di quanto sembri, a seconda di come è costruito quell'altro sistema. Ad esempio, il codice per quella funzione potrebbe essere difficile da estrarre perché si interfaccia con molti altri codici in modi impuri (ad esempio accedendo a molte variabili globali ecc.)

Di 'al tuo capo che la parte del nome di ogni singola variabile include il nome del vecchio progetto e ora devi cambiarli tutti, manualmente. Se il tuo capo non sa (o vuole sapere) perché copiare / incollare è male, potrebbe anche crederlo :)

Sì, il problema più grande è che non è solo copia e incolla, ma copia e incolla, quindi modifica leggermente.

Successivamente, quando una delle varianti incollate presenta un problema, viene modificata. Più tardi, un'altra variante viene cambiata.

Quindi, scopri che tutte le varianti devono cambiare perché la copia originale aveva dei bug. Ora sei davvero avvitato perché tutte le aree incollate non sono più le stesse.

E non lo sapresti, questo tipo di codifica schifosa di solito è quasi del tutto priva di commenti.

Per me, la differenza è che quando hai più copie di codice che fanno la stessa cosa, quello che hai è un mucchio di codice. Quando hai solo un pezzo di codice che fa ogni cosa particolare, allora hai un sistema.

I comportamenti di un sistema possono essere cambiati abbastanza facilmente con modifiche a punto singolo: cambiare il comportamento di un gruppo di codice richiede un sacco di codice.

Mi piacciono i sistemi, non un sacco di codice.

Ci sono compromessi tra la velocità di sviluppo della funzionalità immediata di fronte a te (specialmente quando l'applicazione è piccola) e i costi di manutenzione a più lungo termine man mano che l'applicazione cresce.

Copia e incolla è più veloce per la funzionalità immediata, ma ti costerà caro man mano che l'applicazione aumenta di dimensioni, in termini di correzione di bug e di modifiche a livello di sistema e di mantenimento dei flussi di lavoro tra i diversi componenti dell'applicazione.

Questo è l'argomento che gli imprenditori devono ascoltare. È simile ai costi accettati per la gestione di una flotta di veicoli, tuttavia, con il software, gli aspetti rotti dell'architettura del software sono generalmente nascosti al lato aziendale e possono essere visti solo dagli sviluppatori.

Ha ragione che se il team ha implementato funzionalità simili in precedenza, ripetere sarà molto più facile la seconda volta.

Tuttavia, dovresti probabilmente spiegare che ogni applicazione è diversa. Solo perché hai installato una porta in una casa non significa che puoi installare un'altra porta in un'altra casa in pochissimo tempo - sarai più veloce a causa dell'esperienza (# porte installate), ma ci vorrà ancora tempo per procurarti l'attrezzatura , montare la porta, accertarsi che sia a piombo e avvitarla nel telaio.

nella mia azienda, lavoriamo sempre con classi e metodi e realizziamo documentazione tecnica per loro. Penso che sia la migliore pratica se puoi usare le tue applicazioni di ricerca svn con buone chiavi per trovare la classe di metodo usata prima :)