Abbiamo una responsabilità per migliorare il vecchio codice?

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 avere test unitari che testino il codice prima di iniziare a rifarlo.

Puoi utilizzare il "vecchio codice" per apprendere le migliori pratiche. Se lo fai, è un'esperienza di apprendimento a tempo parziale e non dovresti aspettarti che quel codice sostituisca ciò che è attualmente pubblicato o distribuito da clienti / clienti.

Rifatta le aree del codice che devi modificare più spesso . Poiché visiti frequentemente queste aree, il refactoring migliorerà la tua comprensione del codice e della leggibilità per quando dovrai visitarle di nuovo, mentre non c'è alcun motivo per il codice refactoring che nessuno vedrà mai più.

Inoltre, se si refittano le aree di codice solo quando è necessario modificarle, fornisce una scusa valida se il refactoring provoca una regressione . Certo, cerca di coprire i tuoi refactoring con i test unitari, ma questo non è sempre possibile, specialmente con il codice legacy e dovresti aspettarti grandi rifrattori per creare regressioni di tanto in tanto.

Se devi aggiungere funzionalità e il tuo design rallenta o causa la duplicazione, allora refactor . Quando progetto codice non prevedo quasi mai esattamente quali cambiamenti saranno necessari in futuro. Tuttavia, quando aggiungo nuove funzionalità, di solito finisco per refactoring il codice condiviso. Per il momento, ho aggiunto un terzo ciclo di funzionalità / refactoring, il mio refactoring sta già pagando da solo e il mio codice condiviso è abbastanza stabile.

TLDR: refact in base alle esigenze, non vi è alcun obbligo.

Tutto ciò che fai ha un costo. Hai un tempo limitato per programmare. Tutto quello che fai in programmazione dovrebbe essere guardato contro, "Qual è il vantaggio di fare questo?" 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?

Causerà meno mal di testa da supportare?

Che cosa imparerai?

Diventerà più esteticamente gradevole?

Migliorerà la tua reputazione?

Fai queste domande (e tutte le altre rilevanti per te) per questa e altre attività nella tua coda, e questo ti aiuterà a rispondere se vale la pena aggiustarlo. Questi trade-off 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 ancora prima di Joel.

O se vuoi una risposta più semplice, basta smettere di guardare la TV finché non hai risolto il codice. : -)

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

• Il codice non fa quello che dovrebbe fare?
• Il codice sta causando 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?
• C'è un caso aziendale valido che puoi fare per aggiornare il codice che ti riguarda?

Se c'è una cosa che ho imparato nel corso degli 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 per 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 è comunque se il codice che hai scritto prima rischia di diventare un problema legacy che diventa più difficile da gestire nel tempo.

Ciò di cui stiamo realmente parlando qui è se il codice che ti dà fastidio sia facile o difficile da mantenere e quanto sia costoso che la manutenzione sia nel tempo. Questa è essenzialmente una domanda sul debito tecnico, e se valga la pena ripagare quel debito con una piccola manutenzione chirurgica ora, o se il debito è abbastanza piccolo da poterlo lasciar scivolare per un po '.

Queste sono domande che devi davvero valutare rispetto al carico di lavoro presente e futuro, e dovrebbero essere discusse a lungo con il tuo management e il tuo team al fine di ottenere una migliore comprensione su dove investire le tue risorse e se il tuo vecchio il codice vale il tempo che potresti dover spendere per farlo, se non del tutto. Se riesci a fare un buon business case per introdurre il cambiamento, allora fallo con tutti i mezzi, ma se sei di fronte all'impulso di manipolare il codice perché ti senti imbarazzato per il modo in cui lo hai scritto, allora suggerisco che non c'è spazio per 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 era disponibile per te ieri.

Sicuramente non migliorarlo solo per migliorarlo. Come altri hanno detto (ed è un buon senso), miglioriamo tutti (per un certo valore di "migliore") col passare del tempo. Detto questo, rivedere il codice (sia formalmente che informalmente) illumina spesso questi frammenti che probabilmente non avremmo mai più rivisto.

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

• Identifica le persone del team che riescono davvero a tornare indietro ea migliorare il codice, come una sorta di pulizia del cervello o un'attività piacevole di dimensioni ridotte che dà un senso di realizzazione e trova il tempo nel programma da svolgere 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 calma o di diminuzione.

• 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 dei 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 la guida e chiaramente inquadrato come un esercizio per rendere il codice migliore perché non è conforme agli standard / norme attuali.

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

Non necessariamente. Tuttavia, se si sta eseguendo la manutenzione del codice e si è imbattuti in qualcosa che potrebbe essere migliore, è possibile cambiarlo se si dispone dei test unitari appropriati per assicurarsi di non aver creato una regressione.

Se non esistono test di questo tipo e non puoi essere sicuro che si comporti esattamente come dovrebbe, è meglio lasciarlo da solo.

Dal punto di vista dell'ingegnere, mi piacerebbe molto lavorare sul vecchio codice fino a quando non può più essere migliorato. Ma c'è un caso aziendale per questo? Alla fine della giornata, il codice è lì per contribuire alla linea di fondo, la redditività del tuo posto di lavoro. Se non lo è, basta lasciarlo.

C'è un grande avvertimento, se migliorando il codice, eviterete che si verifichi un bug, (pensando alle grandi palle Y2K quassù ..) lo farei sicuramente con qualcuno più in alto, forse il vostro business unit manager e discutere le conseguenze del miglioramento del codice.

Per quanto mi riguarda, la domanda può essere riformulata e generalizzata: "Perché qualcuno dovrebbe spendere risorse aggiuntive (tempo, denaro, mentale, ecc.) se quel pezzo di codice concreto funziona bene ora? Non è uno spreco di risorse? (s)? "

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

1. Per che cosa ho intenzione di apportare modifiche?
2. Dovrò supportare questo codice? Quando può accadere (vicino / lontano futuro)?
3. Questo codice è abbastanza comodo da funzionare? (Al momento)
4. Posso essere sicuro che tutti i cambiamenti che faccio sono sicuri? Di solito, test diversi aiutano a rispondere a questa domanda.
5. Quali conseguenze posso incontrare se commetto errori durante la modifica del codice? È possibile ripristinare le mie modifiche rapidamente? Sarà una perdita di tempo?
6. ...

In realtà, dovresti porci molte domande. Non c'è un elenco completo e finale di loro. Solo tu e probabilmente i tuoi compagni di squadra puoi trovare la risposta.

P.S. Ho notato che tendo a riscrivere il codice molto spesso, mentre il mio amico e compagno di squadra tendono a lasciarlo intatto. Questo perché rispondiamo alle domande citate in modo diverso. E devo dire che rispondiamo male spesso ... perché non possiamo predire 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 auto degli anni '70?

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

Non c'è una risposta semplice per quanto vale la pena di rifacimento. Generalmente non dovresti farlo a meno che a) sia un buon esercizio di apprendimento per te o b) risparmieresti tempo a lungo termine con un codice migliore. Ricorda che ogni cambiamento rischia di bug.

Come nota a margine vorrei strongmente sostenere i test unitari. È molto facile ridurre il refrattario, specialmente se non si dispone di un comportamento corrente chiaramente contrassegnato con pause automatiche.

Credo che abbiamo la responsabilità di scrivere il miglior codice possibile che possiamo oggi. Ciò significa utilizzare tutto ciò che abbiamo imparato in passato e rifiutare di prendere scorciatoie nel nostro design. Se le pressioni del programma causano qualcosa da tagliare, non credo che la qualità del nostro software debba essere presa in considerazione, quella piccola clip di carta animata, d'altra parte ...

Ora, se stai lavorando e scopri che il codice con cui devi interagire non è scritto al livello che sei attualmente in grado di scrivere, allora è ragionevole correggerlo SE sei in grado di farlo in maniera controllata e metodica . Personalmente ho un'esperienza molto minima con questo tipo di Refactoring, come tutti (quasi tutti?) Ho provato il tutto "lascia solo cambiare tutto e pregare che funzioni" e si è fatto male da quello abbastanza male. Suggerirei di esaminare le discussioni di Martin Fowler (o il suo libro o uno dei numerosi articoli ) sull'argomento. Sembra che abbia ispirato la maggior parte dell'attuale pensiero sul processo.

Ovviamente a volte potresti non essere in grado di pulire il codice come desideri. Joel Spolsky ha scritto un articolo sul motivo per cui potresti dedicare alcune settimane al semplice refactoring del tuo codice. Leggilo qui e sì è un po 'vecchio, ma penso che l'informazione è ancora pertinente.

Spero che questo aiuti

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

Migliore / migliorato è un confronto multiasse. Pensi di riuscire a renderlo più veloce, più piccolo, più efficiente in termini di 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 pagarti per perdere tempo a riscrivere questo codice, invece di scrivere un nuovo codice o riscrivere un altro pezzo di codice?

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

Spingere una modifica alla produzione introduce una possibilità non nulla di rompere le cose (i test unitari e funzionali riducono solo questa possibilità, non la eliminano), e dovrebbero essere fatti solo quando i benefici attesi superano il rischio.

Quale altro punto da considerare: intendi spingere questa modifica alla produzione o semplicemente al ramo di sviluppo? La barra per i due scenari è completamente diversa. Se sta solo entrando nel ramo di sviluppo e potrebbe non entrare mai in produzione, allora l'opportunità significa in sostanza che stai guardando il codice per qualche motivo, e non richiede molto tempo. Può essere rivisto come richiesto se una spinta dovesse mai accadere, e lasciata fuori se è considerata ingiustificata a quel tempo. Se, d'altro canto, sta andando alla produzione ora, come ho detto sopra, è necessario considerare se questo cambiamento vale il costo: in termini di tempo speso per fare la spinta, e i benefici dell'uso del nuovo codice.

Una buona regola empirica è che se ti ci è voluto tempo per capire cosa sta facendo il codice, e se questo tempo potrebbe essere ridotto andando avanti da alcuni ben definiti refactoring, allora servirai le necessità del business e di la tua squadra seguendo questi passaggi.

Se il codice non trae beneficio dall'analisi, se i nomi dei campi non sono diventati espressivi dell'intenzione del codice e i metodi non sono stati suddivisi in blocchi leggibili, l'azienda ha perso qualcosa di valore: il tuo stato di comprensione . Con strumenti come Visual Studio e ReSharper, questi tipi di refactoring sono sicuri, logici e potenzialmente di grande valore per la futura produttività e sicurezza degli sviluppatori.

Come dice lo zio Bob Martin, "lascia sempre il pulitore del campo più pulito di quello che hai trovato."

Questa è una domanda da porre alla direzione della tua azienda.

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

Hai il tempo e le risorse per avere un team di controllo qualità. TEST cosa hai modificato per assicurarti che non sia rotto?

Sono caduto in questa trappola prima di dove sarei in un modulo che corregge un bug, e vedere il codice I o qualcun altro ha scritto che era inefficiente o poco elegante, cambiarlo e finire con più problemi da affrontare che se Ho appena corretto il bug che dovevo risolvere.

Dipende.

Se il codice in questione è veramente rotto, in modo tale che contenga bug che inevitabilmente affioreranno in un punto (ad esempio, un contatore che a un certo punto traboccherà e causerà problemi fastidiosi), quindi correggerli potrebbe valerne la pena - ma se lo fai, metti al primo posto tutte le possibili protezioni per evitare di introdurre nuovi bug: assicurati di avere test unitari significativi che coprano tutto ciò che tocchi, che tutte le tue modifiche siano riviste da qualcuno competente, insisti a testare accuratamente, assicurati di poter tornare indietro alla vecchia versione in qualsiasi momento, eseguire il backup di tutti i dati prima di entrare in produzione, distribuire prima in un ambiente di accettazione e farlo testare da utenti effettivi, ecc. Dovrai anche ottenere l'approvazione prima di andare avanti: se il bug è veramente una bomba a orologeria, e il tuo manager è un po 'competente, sarai in grado di convincerlo a farti aggiustare (e se non ottieni l'approvazione, allora forse è un segno che ti sbagli).

OTOH, se la tua lamentela è pura mancanza di eleganza del codice, allora non osare toccarla. Sta facendo un servizio fedele in produzione da un po 'di tempo, cambiare il codice ti soddisfa solo, ma non aggiunge alcun valore, e come ogni cambiamento, c'è il rischio che tu rompa qualcosa. Anche se non lo fai, il tuo tempo è prezioso (letteralmente: ti viene pagato per quello che fai, quindi ogni minuto del tuo tempo costa denaro), e dal momento che non stai aggiungendo alcun valore effettivo, un tale cambiamento sarebbe una perdita netta per l'azienda e il progetto.