Come convincere un collega che la duplicazione del codice è un male?

Question

Un mio collega è stato attuando una nuova funzionalità in un progetto lavoriamo su insieme e lo ha fatto prendendo un file contenente l'implementazione di una funzionalità simile dallo stesso progetto, la creazione di una copia di esso rinominare tutte le dichiarazioni globali e modificando leggermente l'attuazione. Così ci siamo ritrovati con due file di grandi dimensioni che sono quasi identiche a parte la ridenominazione.

Ho cercato di spiegare che rende il nostro progetto più difficile da mantenere, ma lui non vuole cambiare nulla dire che è più facile per lui a programmare in modo tale e che non c'è alcuna ragione per correggere il codice se " non è rotto".

Come gli ho convincerlo che tale duplicazione del codice è un male?

È legato alla questa domanda , ma io sono più interessato alle risposte mirate ad un tecnico (un altro programmatore ), ad esempio un riferimento a una fonte autorevole come un libro sarebbe grande. Ho già provato argomenti semplici e non ci sono riuscito.

Answer 1

Chiedetegli che cosa farà quando trova un bug nel suo codice. Quanti posti si ha ora bisogno di risolvere il problema in?

Si può anche fargli vedere le risposte a questa domanda (Perché è “copia e incolla” del codice pericoloso?).

Answer 2

Quando si desidera il caffè, lo rendono farlo un sorso alla volta dalla caffettiera al posto di un intero coppa. Ciò è particolarmente efficace se si aggiunge la panna e lo zucchero, che dovrà essere agghindato in porzioni minuscole. Questo dovrebbe illustrare come le attività ripetitive sono molto ingombranti e faticoso (come la correzione di 20 pezzi di codice piuttosto che uno).

Poi, lo inviare un link a questo intervento, così da poter vedere tutte le altre persone che hanno la schiena.

Answer 3

Ci sono due opzioni qui:

1. Lui è una persona razionale che semplicemente non ha troppa esperienza . In questo caso, si può eventualmente razionalizzare il tuo ragionamento, forse mostrandogli un esempio più chiaro di duplicazione del codice qualcun altro nel codice. È inoltre possibile trovare un bug nella copia originale (o, meglio ancora, un paio di bug), e dirgli ora il suo codice è rotto e deve risolvere il problema.

2. E 'un testardo asino : Quindi non si deve sprecare energia su di lui. Vai al suo capo e lasciare che il prendersi cura sporgenza di esso. Alcune persone sono proprio così.

Mentre la prima opzione è ovviamente molto meglio, a volte non si dispone di una scelta. E se sarà quello che alla fine bisogno di mantenere il suo codice a 3:00 del mattino perché qualche importante cliente inizia a gridare dall'altra parte della terra - allora è sicuramente il tuo problema, e il vostro capo dovrebbe gestirlo.

E, infine, se il vostro capo si pensa sbagli, probabilmente siete nel posto sbagliato.

Answer 4

dargli una copia di refactoring .

Answer 5

Migliora la tua versione del codice tanto che è frustrato dalla gelosia, poi dire - se si fosse appena collegato al mio codice ...

Answer 6

Il tuo collega sta ottimizzando la sua efficacia a breve termine, sacrificando il più a lungo efficacia a lungo termine dell'organizzazione (ad esempio, il resto dei suoi collaboratori, nonché come se stesso). Eventuali modifiche richieste nel primo file sono probabilmente necessaria la seconda, ma nessuno si ricorderà ... e che causerà 2 cicli di trovare e correggere, piuttosto che uno.

È possibile eseguire un rivelatore clone sul codice e semplicemente mostrare i risultati al suo manager.

Wikipedia su codice duplicato per una lista.

È possibile vedere i campioni di clone detecion per varie lingue utilizzando il nostro CloneDR rivelatore. È stato progettato di trovare un rilevare grandi blocchi di codice con rinomina coerenti e può mostrare esattamente quello che è successo.

Answer 7

Perché quando si trova un bug, è necessario modificare in due punti. Perché quando si desidera aggiungere una nuova funzionalità, è necessario aggiungere in due punti.

Answer 8

Appello per il vostro capo per motivi tecnici. Se il capo è d'accordo con i metodi del collega / e / o non lo rende risolvere il problema, poi ci aint molto si può fare se fare appello alla ragione, non funziona.

Answer 9

Non si tratta di rendere il vostro amico risolvere questo momento. Si tratta di far crescere la vostra squadra.

fargli capire che egli è stato ingiusto per la squadra e il progetto. Se lui non è ancora d'accordo ad esso, lo ottenere una tazza di caffè e gli chiedo di sedersi sorseggiando, mentre si potrebbe prendere sulla sua tastiera e effettivamente risolvere il codice di fronte a lui.

Si potrebbe ottenere vergogna e non farlo la prossima volta (grande vittoria). Ho usato questo 4 volte e ha sempre funzionato!

In bocca al lupo.

Answer 10

Ci sono un sacco di ragioni valide per non duplicare il codice, ma basta chiedere ... fa la tua squadra vogliono mantenere 100K righe di codice (con duplicazioni di codice), o 50K righe di codice? Può sembrare la duplicazione del codice a questo punto è minima, che è il motivo per cui il vostro collega non vede l'importanza del concetto di asciutto, ma immaginate se s / he duplica sempre più codice per i prossimi 5 anni. Chi sta per sostenere che il codice? La tua squadra? E se s / he lascia il lavoro di un giorno? Non la tua squadra vuole mantenere questa merda? :) Se no, allora hai già fatto un caso molto interessante di non duplicare il codice, per non parlare di "più duplicazioni" = "più inclini ad avere più bug in futuro".

Answer 11

Gli dica che non si sa mai dove un'applicazione può andare in un business ... Una semplice applicazione di test a volte può ottenere modificato più e più volte, e alla fine finiscono per essere utilizzato un sacco ... Ho visto questo spesso in piccole imprese. E poi, invece di partire everyting più e perdere tempo su cose che avrebbero potuto essere fissati in precedenza, si può semplicemente farlo ora, breve e dolce, mentre può essere ...

Answer 12

Probabilmente partendo dal presupposto che non è rotto, e non sarà. Inoltre, il perfetto è nemico del bene. Io non credo che sia ignaro dei pericoli di copia / incolla, ha solo una diversa valutazione del rischio di errori di te.

Forse si potrebbe rompere per lui, per mostrare quanto sia facile. Se non è possibile, forse ha ragione.

Answer 13

Se è superiore (o supervisore) per voi, chiedete maggiori spiegazioni - la sua possibile saperne di più sul contesto ... forse vale la pena doesnt il refactoring del codice (forse è un piccolo progetto)

.

Se è uguale a te, si può riferire al suo superiore, proponendo questa soluzione (che è uno migliore).

Se siete superiore a lui, solo "chiedere" lui per fare la tua strada ...

Answer 14

In primo luogo, riconoscete che ha ragione:. Copia-incolla è davvero più veloce oggi

Quindi, dire che il problema è il costo a lungo termine, e che il costo aumenterà perché con la duplicazione, il sistema non è così ordinato, come potrebbe essere. Ha introdotto il disordine, il disordine, e più il disordine che hai, più è difficile per il lavoro con un sistema. L'applicazione di un certo sforzo ora di organizzare meglio sarà (di solito) pagare nel lungo periodo. E 'proprio come mantenere la vostra scrivania o in camera organizzati.

Questa è l'idea di Ivar Jakobson di software entropia