Abbiamo una responsabilità per migliorare il vecchio codice?

Stavo guardando qualche vecchio codice che ho scritto. Funziona, ma non è un ottimo codice. Ora ne so più di quanto non facessi in quel momento, quindi potrei migliorarlo. Non è un progetto attuale, ma è attuale, funzionante, codice di produzione. Abbiamo la responsabilità di tornare indietro e migliorare il codice che abbiamo scritto in passato o è l'atteggiamento corretto "se non è rotto, non aggiustarlo"? La mia azienda ha sponsorizzato un corso di revisione del codice alcuni anni fa e uno dei principali aspetti da asporto era che a volte è abbastanza buono; Vai avanti.

Quindi, ad un certo punto dovresti semplicemente chiamarlo abbastanza bene e andare avanti, o dovresti provare a spingere i progetti per migliorare il vecchio codice quando pensi che potrebbe essere migliore?

A meno che non apporti modifiche a questo "vecchio codice" per correggere bug o aggiungere funzionalità, non mi preoccuperei di migliorarlo solo per il gusto di farlo. Se vuoi eventualmente migliorarlo, assicurati di disporre di unit test in grado di testare il codice prima di iniziare il refactoring.

È possibile utilizzare il "vecchio codice" per apprendere pratiche migliori. Se lo fai, è un'esperienza di apprendimento part-time e non dovresti aspettarti che quel codice sostituisca ciò che è attualmente rilasciato o distribuito da clienti / clienti.

Rifattorizzare le aree di codice che è necessario modificare più spesso . Dal momento che visiti queste aree frequentemente, il refactoring migliorerà la tua comprensione del codice e la leggibilità per quando dovrai visitarle di nuovo, mentre non ha senso ricorrere al codice di refactoring che nessuno guarderà mai più.

Inoltre, se si refacturing aree di codice solo quando è necessario modificarle, si fornisce una scusa valida se il refactoring provoca una regressione . Certo, prova a coprire i tuoi refactoring con unit test, ma questo non è sempre possibile, soprattutto con il codice legacy e dovresti aspettarti che i grandi refactoring creino regressioni di tanto in tanto.

Se hai bisogno di aggiungere funzionalità e il tuo design ti sta rallentando o causando la duplicazione, allora refactor . Quando progetto il codice, quasi mai prevedo esattamente quali cambiamenti saranno necessari in futuro. Tuttavia, quando aggiungo nuove funzionalità, di solito finisco con il refactoring del codice condiviso. Al momento, ho aggiunto un terzo ciclo di feature / refactoring, il mio refactoring si sta già pagando da solo e il mio codice condiviso è abbastanza stabile.

TLDR: refactor secondo necessità, non vi è alcun obbligo.

Tutto ciò che fai ha un costo. Hai tempo limitato per programmare. Tutto ciò che fai in programmazione dovrebbe essere guardato contro, "Qual è il vantaggio di farlo?" e "Qual è il vantaggio di fare qualcos'altro?"

Se non si tiene conto del costo opportunità (Qual è il costo di fare qualcos'altro?), La qualità è gratuita. È meglio migliorare il tuo codice. Imparerai qualcosa. Funzionerà meglio. Venderà di più.

La vera domanda è qual è la prossima cosa migliore che potresti fare con il tuo tempo? E poi hai fatto dei compromessi.

Venderà più software?

Provocherà meno mal di testa da sostenere?

Che cosa imparerai?

Diventerà più esteticamente piacevole?

Migliorerà la tua reputazione?

Poni queste domande (e tutte le altre rilevanti per te) per questa e altre attività nella tua coda, e ciò ti aiuterà a rispondere se vale la pena risolvere. Questi compromessi sono il motivo per cui l'economia è importante per i programmatori. Joel l'ha detto prima di me, e un vecchio mentore me l'ha detto anche prima di Joel.

O se vuoi una risposta più semplice, basta guardare la TV fino a quando non hai corretto il codice. :-)

Penso che dovresti iniziare ponendoti la domanda che sembra essersi persa. In che modo il codice è negativo? E con questo ti stai davvero chiedendo quanto segue:

• Il codice non fa quello che dovrebbe fare?
• Il codice causa problemi durante la manutenzione del software?
• Il codice è completamente autonomo?
• Hai in programma di aggiornare o sostituire il codice in qualsiasi momento nel prossimo futuro?
• Esiste un valido caso aziendale che puoi fare per aggiornare il codice che ti interessa?

Se c'è una cosa che ho imparato negli anni, è che non puoi permetterti di indovinare te stesso dopo il fatto. Ogni volta che risolvi un problema nel codice, impari qualcosa e probabilmente vedrai come la tua soluzione - o qualcosa di simile - potrebbe essere stata una soluzione migliore a un problema che hai risolto in modo diverso anni fa. Questa è una buona cosa, perché ti mostra che hai imparato dalle tue esperienze. La vera domanda, tuttavia, è se il codice che hai scritto prima diventerà probabilmente un problema legacy che diventa più difficile da gestire nel tempo.

Ciò di cui stiamo davvero parlando qui è se il codice che ti dà fastidio è facile o difficile da mantenere e quanto è costoso che la manutenzione possa essere col passare del tempo. Questa è essenzialmente una domanda sul debito tecnico, e se vale la pena ripagare quel debito usando un po 'di manutenzione chirurgica ora, o se il debito è abbastanza piccolo da poterlo far scivolare per un po'.

Queste sono domande che devi davvero valutare rispetto al tuo carico di lavoro presente e futuro e dovrebbero essere discusse a lungo con la tua direzione e il tuo team al fine di comprendere meglio dove investire le tue risorse e se vale la pena il tuo vecchio codice il tempo che potresti dover dedicare, se non del tutto. Se riesci a fare un buon caso commerciale per introdurre il cambiamento, allora fallo sicuramente, ma se stai affrontando l'impulso di armeggiare con il codice perché ti senti in imbarazzo per il modo in cui l'hai scritto, allora suggerisco che non c'è spazio all'orgoglio personale quando si tratta di mantenere il vecchio codice. Funziona o no, ed è facile da mantenere o costoso da mantenere, e non è mai buono o cattivo semplicemente perché l'esperienza di oggi non è stata a tua disposizione ieri.

Sicuramente non migliorarlo solo per il gusto di migliorarlo. Come altri hanno già detto (ed è buon senso), tutti miglioriamo (per un certo valore di "migliore") col passare del tempo. Detto questo, rivedere il codice (in modo formale o informale) spesso illumina questi bit e pezzi che probabilmente non vorremmo mai più vedere la luce del giorno.

Anche se non credo che abbiamo la responsabilità di tornare indietro e migliorare il codice che non è fondamentalmente rotto, insicuro o dipende da funzionalità in un elenco deprecato / EOL, ecco alcune cose che ho fatto in passato in questa situazione :

• Identifica le persone del team che scavano davvero tornando indietro e migliorando il codice, come una sorta di pulizia del cervello o un compito piacevole e di dimensioni ridotte che dà un senso di realizzazione e trova il tempo per loro di farlo su base regolare. Ho sempre avuto almeno uno di questi tipi di persone in una squadra, e questo approccio può anche aumentare il morale (o almeno l'umore) se siamo tutti in un periodo di pausa o di riposo.

• Usalo come base per un esercizio di apprendimento. Per stagisti, studenti o membri nuovi / junior del team, il refactoring del vecchio codice con la guida di membri senior del team offre loro l'opportunità di comunicare con i nuovi membri del team, comprendere meglio il sistema e prendere l'abitudine di scrivere / aggiornare i test unitari e lavorare con l'integrazione continua. È importante notare che questo esercizio è fatto con una guida e chiaramente definito come un esercizio per rendere il codice migliore perché non conforme agli standard / norme attuali.

Quindi, nessuna responsabilità per ripararlo, ma quella roba vecchia può essere davvero utile. E unit test e CI sono i tuoi amici!

Non necessariamente. Tuttavia, se stai eseguendo la manutenzione del codice e ti imbatti in qualcosa che potrebbe essere migliore, potresti cambiarlo a condizione che tu abbia i test unitari appropriati per assicurarti di non aver creato una regressione.

Se tali test non esistono e non si è sicuri che si comporterà esattamente come dovrebbe, è meglio lasciarlo da solo.

Dal punto di vista di un ingegnere, sicuramente mi piacerebbe molto lavorare sul vecchio codice fino a quando non sarà più possibile migliorarlo. Ma c'è un caso aziendale per questo? Alla fine della giornata, il codice è lì per contribuire alla linea di fondo, la redditività del posto di lavoro. Se non lo è, lascialo.

C'è un grosso avvertimento, se migliorando il codice, eviterai che si verifichi un bug (pensando alle grandi palline Y2K quassù ..) lo farei sicuramente emergere con qualcuno più in alto, forse il responsabile della tua unità aziendale, e discutere le conseguenze del miglioramento del codice.

Quanto a me, la domanda può essere riformulata e generalizzata: "Perché qualcuno dovrebbe spendere risorse aggiuntive (tempo, denaro, mente, ecc.) Se quel pezzo di codice concreto funziona bene adesso? Non è uno spreco di risorse ?"

Ogni volta che trovo un codice legacy, penso a diverse cose che sembrano essere importanti.

1. Per cosa ho intenzione di fare cambiamenti?
2. Dovrò supportare questo codice? Entro quanto tempo (prossimo / lontano futuro)?
3. Questo codice è abbastanza comodo da lavorare? (Proprio adesso)
4. Posso essere sicuro che tutte le modifiche che faccio siano sicure? Diversi test di solito aiutano a rispondere a questa domanda.
5. Quali conseguenze posso incontrare se commetterò errori durante la modifica del codice? È possibile ripristinare rapidamente le mie modifiche? Sarà una perdita di tempo?
6. ...

In realtà, dovresti farti molte domande. Non esiste un elenco completo e finale di essi. Solo tu e probabilmente i tuoi compagni di squadra potete trovare la risposta.

PS Ho notato che tendo a riscrivere il codice molto spesso, mentre il mio amico e il mio compagno di squadra tendono a lasciarlo intatto. Questo perché rispondiamo alle domande menzionate in modo diverso. E devo dire che rispondiamo molto spesso a questi errori ... perché non possiamo prevedere il futuro.

Microsoft ha bisogno di aggiornare Windows? Tutte le distribuzioni * nix devono continuare ad evolversi? O un esempio più pratico, tutti guidano ancora le macchine degli anni '70?

Normalmente puoi scrivere meglio il codice la seconda volta, hai imparato di più sul dominio scrivendolo inizialmente.

Non esiste una risposta semplice per la pena rifacimento. Generalmente non dovresti a meno che a) non sia una buona esperienza di apprendimento per te oppure b) risparmierai tempo a lungo termine con un codice migliore. Ricorda che ogni cambiamento rischia bug.

Come nota a margine, raccomanderei fortemente i test unitari. È molto semplice fare il refacoring soprattutto se non hai un comportamento attuale chiaramente contrassegnato con pause automatizzate.

Credo che abbiamo la responsabilità di scrivere il miglior codice possibile oggi. Ciò significa utilizzare tutto ciò che abbiamo imparato in passato e rifiutarci di prendere scorciatoie nel nostro design. Se le pressioni programmate causano il taglio di qualcosa, non credo nemmeno che la qualità del nostro software debba essere presa in considerazione, quella piccola graffetta animata ordinata, d'altra parte ...

Ora se stai lavorando e scopri che il codice con cui devi interagire non è scritto fino al livello che sei attualmente in grado di scrivere, allora è ragionevole correggerlo SE sei in grado di farlo in modo metodico controllato. Personalmente ho un'esperienza molto minima con questo tipo di refactoring, come tutti (quasi tutti?) Ho provato l'intero "lascia semplicemente cambiare tutto e pregare che funzioni" e mi ha morso abbastanza. Suggerirei di esaminare le discussioni di Martin Fowler (o il suo libro o uno dei tanti articoli ) sull'argomento. Sembra che abbia ispirato gran parte dell'attuale pensiero sul processo.

Naturalmente a volte potresti non essere in grado di pulire il codice come desideri. Joel Spolsky ha scritto un articolo sul motivo per cui potresti voler dedicare qualche settimana al semplice refactoring del tuo codice. Leggi qui e sì, è un po 'vecchio, ma penso che le informazioni siano ancora pertinenti.

Spero che aiuti

Sento che il refactoring / miglioramento del vecchio codice definisce lo stesso programmatore. Volere migliorare il codice che hai scritto un anno fa mostra solo i tuoi progressi e se migliora l'applicazione e hai la capacità, il tempo e l'approvazione per migliorarla, fallo.

Migliore / migliorato è un confronto multiasse. Pensi di poterlo rendere più veloce, più piccolo, più efficiente nell'impiego delle risorse, più leggibile, informazioni più utili, risultati più precisi, più flessibile, più generale, in grado di funzionare su più sistemi, eliminare una dipendenza da un prodotto separato?

Perché la tua azienda dovrebbe pagare per dedicare del tempo a riscrivere questo codice, invece di scrivere un nuovo codice o riscrivere qualche altro pezzo di codice?

Dovresti apportare miglioramenti man mano che l'opportunità si presenta, ma opportunità significa che stai già lavorando sul codice o hai identificato un motivo commerciale per apportare la modifica.

Spingere una modifica alla produzione introduce una possibilità diversa da zero di rompere le cose (i test unitari e funzionali riducono solo questa possibilità, non la eliminano) e dovrebbero essere fatti solo quando il beneficio atteso supera il rischio.

Qual è un altro punto da considerare: intendi spingere questo cambiamento nella produzione o semplicemente nel ramo di sviluppo? La barra per i due scenari è completamente diversa. Se sta andando solo nel ramo di sviluppo e potrebbe non entrare mai in produzione, allora l'opportunità significa sostanzialmente che stai guardando il codice per qualche motivo, e non richiede tempo. Può essere riesaminato come richiesto se dovesse mai avvenire una spinta e tralasciato se considerato ingiustificato in quel momento. Se d'altra parte, andrà alla produzione ora, come ho detto sopra, è necessario considerare se questa modifica vale il costo: in termini di tempo impiegato per fare la spinta e i vantaggi dell'utilizzo del nuovo codice.

Una buona regola empirica è che se ti ci è voluto del tempo per capire cosa sta facendo il codice e se questa volta potrebbe essere ridotto andando avanti con alcuni refactoring ben scelti, allora stai servendo le esigenze dell'azienda e del tuo team da facendo questi passi.

Se il codice non beneficia della tua analisi, se i nomi dei campi non sono diventati espressivi dell'intento del codice e i metodi non sono stati suddivisi in blocchi leggibili, l'attività ha perso qualcosa di valore: il tuo stato di comprensione. Con strumenti come Visual Studio e ReSharper, questi tipi di refactoring sono sicuri, neutri dalla logica e potenzialmente utili per la produttività e la fiducia degli sviluppatori.

Come dice lo zio Bob Martin, "Lascia sempre il campeggio più pulito di quanto tu abbia trovato."

Questa è una domanda da porre al management della tua azienda.

Hai il tempo e le risorse necessarie per tornare indietro e apportare modifiche al vecchio codice?

Hai il tempo e le risorse per far testare un team di controllo qualità su ciò che hai modificato per assicurarti che non sia rotto?

Sono caduto in questa trappola prima dove sarei stato in un modulo che risolveva un bug e vedevo il codice che io o qualcun altro ho scritto che era inefficiente o inelegante, lo cambiavo e finivo con più problemi da affrontare che se avessi appena risolto il bug che mi era stato assegnato il compito di correggere.

Dipende.

Se il codice in questione è veramente rotto, in modo che contenga bug che inevitabilmente affioreranno in un punto (ad esempio, qualche contatore che a un certo punto traboccerà e causerà problemi spiacevoli), allora risolverli potrebbe valere la pena, ma se tu fai, metti in atto tutte le possibili misure di sicurezza per evitare di introdurre nuovi bug: assicurati di avere test unitari significativi che coprono tutto ciò che tocchi, fai rivedere tutte le modifiche da qualcuno competente, insisti a testare accuratamente, assicurati di poter tornare al vecchio versione in qualsiasi momento, eseguire il backup di tutti i dati prima di andare in produzione, distribuire prima in un ambiente di accettazione e farlo testare da utenti reali, ecc. Avrai anche bisogno di ottenere l'approvazione prima di andare avanti: se il bug è davvero una bomba a tempo e il tuo manager è in qualche modo competente,sarai in grado di convincerlo a permetterti di risolverlo (e se non ottieni l'approvazione, allora forse è un segno che ti sbagli).

OTOH, se il tuo reclamo è una semplice mancanza di eleganza del codice, non osare toccarlo. Fa un servizio fedele in produzione da un po 'di tempo, cambiare il codice ti soddisfarà, ma non aggiungerebbe alcun valore e, come ogni cambiamento, c'è il rischio che tu rompa qualcosa. Anche se non lo fai, il tuo tempo è prezioso (letteralmente: vieni pagato per quello che fai, quindi ogni minuto del tuo tempo costa denaro), e dal momento che non stai aggiungendo alcun valore effettivo, tale cambiamento sarebbe una perdita netta per l'azienda e il progetto.