Manutenzione del codice: mantenere uno schema errato quando si estende un nuovo codice per essere coerenti o no?

Il refactoring è fatto meglio a piccoli passi, e preferibilmente solo se hai dei test unitari per coprire il codice. Quindi, se non hai ancora dei test, cerca di scriverli prima, e fino ad allora, segui i refacting più semplici, più infallibili, preferibilmente automatizzati. Un grande aiuto in questo è Lavorare efficacemente con il codice legacy di Michael Feathers.)

In generale, mirare a migliorare il codice ogni volta che lo tocchi. Segui la regola Boy Scout ( coniato da Robert C. Martin ) lasciando il codice più pulito di quello che hai trovato. Quando aggiungi un nuovo codice, prova a tenerlo separato dal codice errato esistente. Per esempio. non seppellirlo nel mezzo di un metodo lungo, aggiungi invece una chiamata a un metodo separato e inserisci il tuo nuovo codice. In questo modo, si sviluppano gradualmente isole più grandi di codice clean (er) all'interno della base di codice esistente.

Aggiornamento

Refactoring cost will be heavier than its benefits. [...] You, as developer, do you prefer to maintain easy stupid boring code OR to have some helpers that will do the stupid boring code at your place ?

Ho sottolineato quale credo sia il punto chiave qui. Ci interessa sempre valutare costi e benefici del refactoring prima . Come nel tuo caso, molti di noi hanno risorse limitate per il refactoring, quindi dobbiamo usarli saggiamente. Trascorri quel prezioso tempo sul refactoring dove porta i maggiori benefici con il minimo sforzo.

Come mente creativa, ovviamente preferirei produrre un codice perfetto, bello ed elegante, e riscrivere tutto ciò che non assomiglia ai miei ideali :-) In realtà però, sono pagato per produrre software che risolve problemi reali per i suoi utenti , quindi dovrei pensare a produrre più valore per i loro soldi a lungo termine.

Il vantaggio del refactoring appare solo se vi sono risparmi sufficienti nel tempo e sforzi per comprendere, mantenere, correggere ed estendere il codice a lungo termine . Quindi se un pezzo di codice - per quanto brutto - viene raramente o mai toccato, non ci sono bug noti in esso e non conosco le caratteristiche imminenti nel futuro prevedibile che mi richiederebbe di toccarlo, preferisco lasciarlo in pace.

Dato che non hai tempo per il refactoring e il codice è gestibile, tienilo coerente. La prossima volta assicurati di includere il refactoring nel preventivo.

Essere coerenti aiuta solo il prossimo sviluppatore quando il codice circostante è in buona forma. Pensa a quanto tempo hai impiegato per capire il codice in questione e per trovare i giusti "punti di estensione" per aggiungere le tue modifiche. Se segui la tendenza attuale, il prossimo deve capire il codice esistente e il tuo nuovo codice quando deve apportare modifiche.

Se si rifatta il codice in funzioni significative, il prossimo avrà un tempo più semplice per capire cosa sta succedendo e dovrà impiegare meno sforzi per aggiungere le sue modifiche. Pensare in questo modo. Supponi che il prossimo ragazzo sei tu. Cosa preferiresti vedere quando rivisitassi questo blocco di codice, lo stesso pasticcio che stai guardando ora o qualcosa di più logicamente costruito?

La coerenza ha una priorità elevata. Ovviamente, chiunque sia sano di mente preferirebbe un'elegante soluzione DRY ovunque, invece di un boilerplate incollato a copia ovunque, ma preferiresti davvero due approcci diversi nella stessa base di codice per averne una applicata coerentemente? Cosa succede se qualcuno inventa una soluzione ancora più intelligente e la applica in modo incoerente? Quindi hai tre diversi modi di fare la stessa cosa.

Ho visto molto codice disordinato risultante dagli sviluppatori che hanno trovato un "modo migliore" per fare qualcosa, ma non applicarlo coerentemente su una base di codice. Se fa parte di una strategia pianificata e coordinata per applicare gradualmente un nuovo modello, potrebbe funzionare, ma ogni schema implementato in modo incoerente rischia di peggiorare il sistema.

Forse potresti prendere in considerazione il refactoring in fasi più piccole, in modo tale che ogni passaggio possa essere applicato all'intero codebase in un colpo solo. Per esempio. estraendo una parte più piccola del boilerplate in una funzione helper in ogni iterazione. Col passare del tempo finisci con tutto il boilerplate in una classe di supporto. Può sembrare davvero brutto perché non è stato progettato ma è cresciuto, ma puoi correggerlo ora perché hai tutto il codice in un unico posto.

Qualsiasi refactoring che elimina il codice duplicato è un buon refactoring e non dovrebbe essere posticipato a meno che non sia imminente una scadenza. Il tempo speso per il refactoring una volta, è facilmente compensato dal tempo vinto nelle future implementazioni. Grazie al refactoring i meccanismi interni non sono più visibili, quindi dovrebbe diventare più facile da capire, non più difficile da seguire.

Secondo me è un malinteso comune che il codice refactored sia più difficile da seguire. Questo è solitamente un argomento di persone che hanno familiarità con ciò che viene refactored, e non il risultato refactored. Per i nuovi arrivati, il risultato refactored sarà più chiaro.

Eventuali bug / funzionalità possono essere corretti / implementati in un punto centrale in un secondo momento e sono automaticamente disponibili ovunque nella tua applicazione. Questo è un enorme guadagno che è generalmente molto sottostimato. In generale, un refactoring totale di un componente non richiede molto tempo. (giorni invece di mesi) Quando si confronta questo a tempo perso a causa di bug, dovendo capire il codice che potrebbe essere stato rifatto, il costo del refactoring diventa minimo.

Aggiornamento relativo alla risposta di Péter Török: Non è forse posticipando il refactoring "perché ci vuole tempo", aumenta il tempo di refactoring in un secondo momento? Il refactoring non dovrebbe richiedere molto tempo, se fatto più spesso.

Come spiegare al tuo capo che passerai qualche giorno a scrivere un codice che non aggiunge nulla al prodotto, è difficile, ed è una domanda completamente diversa. :)

Non riesci a creare una nuova interfaccia / classi che funziona come facciata sul vecchio codice, introducendo il tuo nuovo codice nel tuo stile che può essere facilmente esteso?

Va bene andando avanti. Usa le funzioni invece di tagliare e incollare. Ciò non richiede il refactoring, ma ti dà l'inizio di una base per il futuro refactoring.

You, as developer, do you prefer to maintain easy stupid boring code OR to have some helpers that will do the stupid boring code at your place ?

Non capisco la domanda rivista. Penso che la maggior parte delle persone, come me, preferirebbe non mantenere "stupido noioso codice". Non so cosa intendi per aiutante, mi dispiace.

Il poster ha risposto alla propria domanda non apportando grandi cambiamenti in questo momento. Bella scelta. Ho problemi con l'arroganza di uno sviluppatore che sanno cosa è meglio per il business. Un grande refactoring in sordina ... perché sai meglio del tuo capo? Qualsiasi manager capace può valutare i vantaggi.

Se il refactoring non è un'opzione allora la domanda diventa più di una discussione sull'ora, sul luogo, ecc ... giusto per farlo. La coerenza è molto importante. Tuttavia, il codice longevo spesso beneficia del "rinnovo". Altri hanno discusso di questo ...