Ho sempre evitato di duplicare il codice indipendentemente dalla circostanza. Ad esempio, se ho un pezzo funzionante di funzionalità che deve essere riutilizzato da entità diverse, ho sempre il refactoring per rendere disponibile questa funzionalità. In nessun caso dovrei duplicare il codice. Sono probabilmente un po 'rigido quando si tratta di questo, ma in realtà non mi piace duplicare il codice.
Al momento ho avuto un leggero disaccordo con il nostro Team Lead che ha suggerito che invece di refactoring, dovrei copiare tutta la parte di funzionalità richiesta in una classe diversa e quindi decidere il miglior refactoring in un secondo momento. Questo è anche dopo aver confermato che i miei precedenti sforzi di refactoring non hanno infranto nessuno dei test unitari.
Ho avuto questa conversazione anche oggi con il mio precedente manager e il suo mentore, che si sono entrambi schierati con il mio caposquadra. La loro argomentazione è che l'indebitamento tecnico è OK, e quasi sempre preferibile, specialmente se si stanno imbattendo in vincoli temporali, cosa che capisco. La mia contro-discussione era sì, non vogliamo saltare le scadenze ma bisogna sempre considerare il costo del refactoring e questo di solito dovrebbe essere il primo istinto, specialmente se stiamo semplicemente spostando le funzionalità in una nuova posizione che la rende accessibile a tutti. Il corretto test dell'unità può anche garantire che gli sforzi di refactoring non interrompano la funzionalità esistente. Inoltre, non è sempre meglio pagare il debito ora piuttosto che dopo? Posso solo immaginare cosa comporterà questo compito se tutti i membri del team duplicassero semplicemente il codice.
È sufficiente dire che dovevamo accettare di non essere d'accordo. Nel suo libro intitolato Clean Code , Robert Martins enfatizza il refactoring continuo durante lo sviluppo, quindi è stato sorpreso dalla risposta del mio precedente manager.
Che cosa ne pensi?