Come riparare il modello copia / incolla?

Dove lavoro, le persone (i consulenti) si sentono pressate per rilasciare funzionalità il più rapidamente possibile. Quindi, invece di dedicare troppo tempo a pensare a come fare le cose nel modo giusto o perché non vogliono rompere nulla, il codice viene copiato da moduli diversi e modificato.

Non è facile evitarlo, poiché la base di codice è aperta a tutta l'azienda. Molte persone ci lavorano.

Ora che il casino è già lì, qual è il modo migliore per rimuovere quei licenziamenti senza rompere troppo?

Una parte della risposta è Refactoring .

Innanzitutto, inizia a scrivere unit test per assicurarti di non interrompere accidentalmente nulla con le modifiche. Quindi iniziare a migliorare il design, rimuovere duplicati, ecc. In piccoli passaggi, eseguire i test unitari dopo ogni passaggio, risolvere eventuali problemi in caso di esito negativo di un test o ripristinare immediatamente se si verifica un problema più grande di quello che è possibile risolvere facilmente.

L'altra parte è l' educazione .

Alle persone deve essere insegnato a non lasciarsi alle spalle il codice negativo. Questa è certamente una battaglia a lungo termine, poiché le abitudini e i processi di pensiero sono difficili (a volte persino impossibili) da cambiare . Tuttavia, senza di essa, continuerai a ricevere una scorta infinita di codici errati che urlano per essere riformattati.

Puoi scegliere di fare revisioni del codice di gruppo per aprire una discussione sulle buone e cattive abitudini di codifica e diffondere i meriti del primo. Non basta dire "devi (non) scrivere codice come questo", devi convincere le persone con logica e fatti concreti. Come "se hai questo pezzo di metodo duplicato sulla base del codice n volte, cosa pensi che ci siano possibilità che se viene trovato un bug in quel metodo, sarà 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 con la scrittura di codice sciatto, continueranno sicuramente a scegliere il percorso più semplice. Se la società continua a valutare la "consegna rapida" per manutenibilità a lungo termine, nulla cambierà :-( Quindi potrebbe essere necessario discuterne anche con il management. Un modo per farli capire è questo: refactoring significa mantenere pulito il codice, facile da capire e mantenere: omettere il refactoring è come accumulare debito sulla tua carta di credito. Puoi cavartela per un po ', ma se non gestisci attivamente le tue abitudini di acquisto e i tuoi debiti, un giorno si sbriciolerà inevitabilmente sulle spalle. Nella vita di un progetto software, il fallimento è quando il progetto diventa irraggiungibile: diventa più facile riscriverlo da zero piuttosto che aggiungere una nuova funzionalità alla base di codice esistente. Oppure gli utenti sono così stufi del livello inferiore di supporto e funzionalità che passano semplicemente alla concorrenza.

Come parte dell'educazione come ha detto @Peter, puoi introdurre un rilevatore di copia e incolla come PMD e utilizzarlo come parte del tuo ciclo di costruzione 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 da cui iniziare le discussioni.

le persone (i consulenti) si sentono spinte a rilasciare funzionalità il più rapidamente possibile

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

Non è facile evitarlo, poiché la base di codice è aperta a tutta l'azienda. Molte persone ci lavorano.

La "base di codice è aperta a tutta l'azienda" non è un problema. Non importa

Ciò che conta è che esiste un sistema di premi di gestione in atto per il copia e incolla. La causa principale è che le persone vengono ricompensate (ovvero pagate, elogiate o promosse o estese) per il copia e incolla.

Non puoi spezzarlo senza cambiare radicalmente la cultura da "premuto per rilasciare le funzionalità il più rapidamente possibile" a "premiato per aver apportato le modifiche appropriate e ben collaudate della base di codice".

Devi

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

2. Devi documentare incessantemente ed esporre costi e rischi per il resto del tuo mandato presso quell'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 prendersi il merito del nuovo approccio che li farà apparire bene e sarai ignorato.

È molto importante ridurre il copia e incolla. Ma è difficile cambiare la cultura di un'organizzazione. Devi fornire molti fatti e devi fare il caso più e più volte ai dirigenti che non sono d'accordo con te.

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

Oggi ho dovuto aggiungere un'altra funzionalità e non potevo più accettarla. Ho creato una nuova libreria, ho combinato le funzioni 100+ in 10 funzioni rientranti che modificano leggermente il loro comportamento in base ai bit flag e quindi ho scritto una serie di test per accertarmi che eventuali modifiche a quella libreria non interrompessero nient'altro.

Tempo totale impiegato: 4 ore. Ero pronto a partecipare a una maratona di 20 ore se necessario e sono stato sorpreso dalla rapidità con cui ho messo sotto controllo un disordine crescente. Come bonus, è stato più facile risolvere successivamente un mucchio di problemi di dipendenza dell'intestazione. Inoltre, poiché molte delle nostre cose proprietarie sono ora in oggetti statici per il collegamento, possiamo offrire ai nostri clienti che hanno accesso al codice sorgente più di quanto non facessimo in precedenza.

Il mio consiglio: mordere il proiettile e rimodellare quel disastro ora prima di farlo diventa davvero male . Probabilmente non ci vorrà tutto il tempo che pensi, ma crea un nuovo ramo per te per ogni evenienza.

Inoltre, puoi sempre copiare / incollare per ottenere funzionalità fuori dalla porta mentre risolvi il problema fondamentale. Al termine, basta estrarre le cose incollate e utilizzare invece la nuova libreria.

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

• creare test unitari
• refactoring
• educare
• impegnarsi negli standard di codifica e rilevare le violazioni

D'altra parte, devi guardare a ciò che induce le persone a copiare e correggere.

• le persone potrebbero non essere in grado di riutilizzare il codice in un buon modo perché è associato a molto
• le persone potrebbero non sapere che esiste una biblioteca che possono usare
• Il codice della libreria potrebbe non essere abbastanza generico e cuocere 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 anche causare il test di molte altre applicazioni.

Quindi penso che per interrompere il modello copia / incolla sia necessario rendere più semplice il riutilizzo.

• rendere le biblioteche individuabili e ben documentate
• rendere le biblioteche indipendenti da tutto
• pensa a una buona strategia di versioning
• assicurare la retrocompatibilità
• pensa alla facile estensibilità delle biblioteche

leggi le Linee guida per la progettazione del framework

Spero che sia di aiuto.

C'è un forte atteggiamento "copia incolla considerato dannoso". Penso che sia buono, ma va un po 'troppo lontano. Copia incolla come un esercizio per scoprire le somiglianze e le differenze tra due metodi o classi - come un passo nel processo di triangolazione - penso che sia salutare. Ma interrompere la completa triangolazione - eliminare la duplicazione introdotta da copia incolla - è davvero dannoso.

Se riesci a trovare il modo di usare quell'atteggiamento più sfumato, per dire agli sviluppatori non "che male!", Ma piuttosto "che è incompleto, puoi lavorare con me per completare il refactoring?", Potresti ritrovarti a conversare in modo più costruttivo.

Mi occupo dello stesso problema qui, e la mia opinione è: non cercare di evitarlo in anticipo, rifattorizza solo quando diventa troppo grave.

Il modulo al momento sto lavorando su startet come una 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 invariate e dovrebbero essere spostate in una libreria, in una classe genitore astratta ecc.

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

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

Potresti provare a forzarli a risolverli nel loro tempo libero. Quindi cominceranno a farlo dall'inizio, ma poi impiegheranno un tempo straordinario per fare le cose. Penso che AmmoQ abbia la giusta idea di refactoring di cose che causano problemi.

L'unico modo per eliminare il codice copia / incolla è (IMHO) revisioni del codice, chiedi a una persona (o preferibilmente di più) di controllare il codice e quando trova il codice che sembra provenire da un'azione copia / incolla lascia che il programmatore rifletta.

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 molto a iniziare a far salire una o due persone sul tuo treno e a diffondere il virus. Quando la maggioranza pensa che sia una buona idea falla descrivere e cerca di introdurre recensioni per garantire che rimanga così. Questo è un processo molto lento e noioso, ma non può cambiare rapidamente. All'inizio avrà un costo aggiuntivo, quindi è importante che la direzione conosca e supporti l'obiettivo a lungo termine.

@Anders K. Le recensioni sono un buon mezzo per mantenere la pratica in atto. Quando costringono le persone a scrivere codice in cui non credono crea molto attrito. Cadranno nel vecchio habbit non appena possibile. Sono fermamente convinto che dovresti iniziare con l'istruzione per guadagnare slancio.