Come risolvere il modello copia / incolla?

Una parte della risposta è Refactoring .

In primo luogo, inizia a scrivere test unitari per assicurarti di non rompere accidentalmente nulla con le tue modifiche. Quindi inizia a migliorare la progettazione, rimuovendo duplicazioni, ecc. In piccoli passi, eseguendo i test delle unità dopo ogni passaggio, risolvendo eventuali problemi se uno dei test fallisce o ripristinando immediatamente se si verifica un problema più grande di quello che è possibile risolvere facilmente.

L'altra parte è istruzione .

Le persone devono essere insegnate a non lasciare codice cattivo dietro. Questa è certamente una battaglia a lungo termine, poiché le abitudini e processi di pensiero sono difficili (a volte persino impossibili) da cambiare . Tuttavia, senza di esso, continuerai a ricevere una fornitura infinita di codice errato che urla per essere refactored.

Puoi scegliere di fare revisioni di codice di gruppo per aprire una discussione sulle buone e cattive abitudini di codifica e diffondere i meriti del primo. Non è sufficiente dire "devi (non) scrivere un codice come questo", devi convincere le persone con logica e fatti concreti. Come "se hai questo pezzo di metodo duplicato sopra il codebase n volte, cosa pensi che sia probabile che se un bug viene trovato in quel metodo, verrà corretto in ogni copia del codice del metodo? "

La tua azienda potrebbe anche aver bisogno di rivedere gli incentivi e i criteri di accettazione per i consulenti - se riescono a cavarsela scrivendo il codice sciatto, sicuramente continueranno a scegliere il percorso più facile. Se la società continua a valutare la "consegna rapida" rispetto alla manutenibilità a lungo termine, non cambierà nulla :-( Quindi potrebbe essere necessario discuterne anche con la gestione. Un modo per farle capire è: refactoring significa mantenere il codice pulito, facile da capire e mantenere. Omettere il refactoring è come accumulare debiti sulla carta di credito . Puoi farla franca per un po ', ma se non stai gestendo attivamente le tue abitudini di acquisto e debiti, si sgretolerà inevitabilmente sulle vostre spalle un giorno Nella vita di un progetto software, la bancarotta è quando il progetto diventa non mantenibile: diventa più facile riscriverlo da zero piuttosto che aggiungere una nuova funzionalità alla base di codice esistente. così stufo del livello inferiore di supporto e funzionalità che semplicemente passano alla concorrenza.

Come parte dell'istruzione, come ha detto @Peter, puoi introdurre una copia & rilevatore di incolla come PMD e usalo come parte della tua build cycly per aiutare a far rispettare questa parte dei tuoi standard di codifica.

Assicurati che lo standard di codifica dei tuoi progetti copra questo modello in modo da avere una base di partenza per iniziare le discussioni.

people (consultants) feel pressed to release features as fast as possible

Non hai un problema tecnico, hai un problema sociale. In effetti, hai un problema di gestione.

It's not easy to prevent this, since the code base is open to the whole company. Lots of people work on this.

Il "codice base è aperto all'intera azienda" è un non-problema. Non importa.

Ciò che importa è che esiste un sistema di gestione dei premi in vigore per il copia e incolla. La causa principale è che le persone vengono premiate (vale a dire, pagate o elogiate o promosse o estese) per il copia e incolla.

Non puoi rompere questo senza cambiare fondamentalmente la cultura da "premere per rilasciare funzionalità il più velocemente possibile" a "premiato per apportare le opportune, ben collaudate modifiche al codice base."

Devi

1. Inizia in alto, con i manager che rafforzano i premi. Devi esporre la pratica corrente e documentare costi e rischi. Devi proporre un'alternativa che riduca costi e rischi.

2. Devi incessantemente documentare ed esporre costi e rischi per il resto del tuo mandato in quella organizzazione. Implacabile. Basata sui fatti. Costo e rischio. Ogni settimana più costi e più rischi da copia e incolla.

3. Dovrai aiutare i manager a prendere atto del nuovo approccio che li farà sembrare buoni e verrai ignorato.

È molto importante ridurre il copia e incolla. Ma è difficile cambiare la cultura di un'organizzazione. Devi fornire molti fatti e devi ricorrere all'infinito ai manager che non sono d'accordo con te.

Ora ho un codice base che stava iniziando a marcire da quello. Avevo più di 10 funzioni statiche per modulo che erano sostanzialmente identiche alle stesse funzioni statiche in altri moduli. Ognuno si è comportato solo in modo abbastanza diverso da giustificare una nuova incarnazione per poter fare le cose il più rapidamente possibile.

Oggi, ho dovuto aggiungere un'altra funzione e non potevo più farcela. Ho creato una nuova libreria, combinando le funzioni 100 + in 10 funzioni rientranti che alterano leggermente il loro comportamento basato su flag di bit e poi hanno scritto una serie di test per assicurarci che qualsiasi modifica a quella libreria non abbia infranto qualcos'altro.

Tempo totale trascorso: 4 ore. Ero pronto per andare in una maratona di 20 ore, se necessario, e fui sorpreso di quanto velocemente riuscissi a tenere sotto controllo un pasticcio crescente. Come bonus, è stato più facile correggere in seguito una serie di problemi di dipendenza dell'intestazione. Inoltre, dal momento che molte delle nostre risorse proprietarie sono ora in oggetti statici per il collegamento, possiamo dare ai nostri clienti che ottengono l'accesso al codice sorgente più di quanto abbiamo fatto in precedenza.

Il mio consiglio: mordere il proiettile e ridimensionare quel pasticcio ora prima di farlo diventa davvero cattivo . Probabilmente non ci vorrà tutto il tempo che pensi, ma crea un nuovo ramo per te stesso nel caso in cui.

Inoltre, puoi ancora copiare / incollare per ottenere funzioni fuori dalla porta mentre risolvendo il problema fondamentale. Al termine, estrai il materiale incollato e utilizza invece la nuova libreria.

Sono d'accordo con le risposte fornite finora. Dovresti:

• crea unit test
• refactoring
• educare
• metti in pratica gli standard di codifica e rileva le violazioni

D'altro canto, è necessario esaminare le cause per cui le persone devono copiare e incollare la pasta.

• le persone potrebbero non essere in grado di riutilizzare il codice in un buon modo perché è accoppiato a molto
• le persone potrebbero non sapere che esiste una libreria che possono usare
• Il codice della libreria potrebbe non essere abbastanza generico e preparare la tua versione è molto più semplice rispetto all'utilizzo di una libreria esistente
• Potrebbe non esserci una buona strategia di controllo delle versioni (non di controllo del codice sorgente) e la modifica di una libreria generica potrebbe causare anche la verifica di molte altre applicazioni.

Quindi penso di fermare il pattern di copia / incolla di cui hai bisogno per rendere più facile il riutilizzo.

• rende le biblioteche individuabili e ben documentate
• rende le librerie indipendenti da ogni cosa
• pensa a una buona strategia di versioning
• garantisce la compatibilità con le versioni precedenti
• pensa alla facile estensibilità delle librerie

leggi Linee guida per la progettazione di framework

Spero che questo aiuti.

Esiste una strong attitudine "copia incolla considerata dannosa". Penso che sia buono, ma va un po 'troppo lontano. Copia incolla come esercizio per scoprire le somiglianze e le differenze tra due metodi o classi - come un passaggio nel processo di triangolazione - penso sia salutare. Ma smettere di triangolazione completa - di eliminare la duplicazione introdotta da copia incolla - è davvero dannoso.

Se riesci a trovare modi per usare quell'atteggiamento più sfumato, per dire agli sviluppatori "non è male!", ma piuttosto "è incompleto, puoi lavorare con me per completare il refactoring?", quindi potresti ritrovarti con più conversazioni costruttive.

Mi preoccupo dello stesso problema qui, e il mio punto di vista è: Non cercare di evitarlo in anticipo, basta fare un refactoring quando diventa troppo cattivo.

Il modulo al momento sto lavorando su startet come copia di un altro modulo, ora sto cambiando tutto ciò che deve essere diverso. Una volta fatto questo, e il nuovo modulo è finito, lo confronterò con il modulo originale e scoprirò quali parti sono più o meno immutate e dovrebbero essere spostate in una libreria, classe genitore astratta ecc.

Chiunque è responsabile è in difetto. Non ci si può aspettare che una persona riveda ogni riga di codice, ma fissa gli standard e i tempi.

Gli appaltatori (o chiunque sia a corto termine su un progetto) possono essere messi nella posizione in cui sono solo compensati per averlo fatto funzionare la prima volta. C'è qualche incentivo per farlo fare al più presto. Il codice copiato potrebbe non avere mai bisogno di essere modificato e se lo è non sarà da loro.

Potresti provare a costringerli a risolverlo nel loro tempo libero. Poi cominceranno a farlo dall'inizio, ma poi prenderanno una quantità innumerevole di tempo per fare le cose. Penso che AmmoQ abbia la giusta idea di ridefinire le cose che stanno causando problemi.

L'unico modo per eliminare il codice copia / incolla è il codice (IMHO), avere una persona (o preferibilmente di più) per controllare il codice e quando trovano il codice che sembra provenire da una copia / incolla, lascia che il programmatore refactoring.

Come suggerito, questo è principalmente un problema nell'organizzazione. Cerca di iniziare educando le persone (non dimenticare il livello di gestione diretta sopra la tua posizione). Aiuta moltissimo a iniziare a prendere una o due persone sul treno e lasciare che il virus si diffonda. Quando la maggioranza pensa che questa sia una buona idea, descriverla e provare a introdurre recensioni per garantire che rimanga così. Questo è un processo molto lento e noioso, ma non può cambiare rapidamente. All'inizio costerà più tempo, quindi è importante che la gestione conosca e supporti l'obiettivo a lungo termine.

@Anders K. Le recensioni sono un buon mezzo per mantenere la pratica in atto. Quando costringere le persone a scrivere codice che non ci credono crea molto attrito. Torneranno nella vecchia haabit non appena possibile. Sono fermamente convinto che dovresti iniziare con l'educazione per acquisire slancio.