La manutenzione del codice è in genere un progetto speciale o è considerata parte del lavoro quotidiano?

Se possiedi un codice legacy, penso che sia spesso pragmatico ripulire o codice refactoring quando è necessario immergersi in quel codice, ad es. per correggere un bug o aggiungere una nuova funzionalità. Altrimenti rischi di sprecare tempo o di rompere il codice che non sarebbe mai stato mantenuto in ogni caso.

Di solito non dedico del tempo a ripulire il codice per il gusto, ma piuttosto mentre si lavora su un bug / funzione una buona regola è sempre quella di lasciare il codebase in un modo migliore di quello che hai trovato. Ciò che è in termini di factoring e copertura dei test.

Quando stai scrivendo un nuovo codice dovresti cercare di mantenerlo pronto fin dall'inizio.

Dipende. All'inizio del ciclo di vita di un progetto, sono letteralmente in tutto il codice, ripulendo le cose ovunque io le veda. Mentre tentiamo di stabilizzarci per il rilascio, ne faccio sempre meno. La prossima volta che il prodotto si trova in un ciclo di sviluppo, eseguirò un altro (più piccolo) giro di pulizia, quindi stabilizzerò per il rilascio. Col passare del tempo, provo non a pulire, tranne dove sto aggiungendo una nuova funzionalità o correggendo un bug, semplicemente a causa del rischio di apportare questi tipi di modifiche. Ho un buon numero di test unitari, ma comunque, c'è un rischio ogni volta che esegui "cleanup" su un'app in produzione.

Nel mio progetto attuale, fa parte del mio lavoro quotidiano. Ho compiti di refactoring programmati abbastanza regolarmente come parte del normale lavoro di sviluppo. Io tendo a concentrarmi su alcune aree specifiche e faccio refactoring su larga scala in blocchi di un giorno, distribuiti su diversi mesi. In media, trascorro da metà a un giorno il refactoring per ogni due settimane di iterazione.

Questo è (sorpresa a sorpresa) un progetto legacy abbastanza ampio. Era stato esternalizzato a diversi subappaltatori e 2 anni fa era ai margini dell'abisso, pieno di bug, molto inaffidabile, con utenti molto infelici (giustamente). È stato allora che il nostro team ha preso il comando e ha iniziato l'operazione di salvataggio (sono entrato nel team circa un anno dopo). Ormai la situazione è decisamente migliore, ma c'è ancora molta strada da fare.

Fortunatamente, il nostro management capisce la situazione e sa che dobbiamo ripagare un enorme debito tecnico accumulato, quindi ci permettono di fare il normale refactoring e riconoscere il nostro impegno anche quando non comporta cambiamenti tangibili e visibili per il utenti. Sanno che questa è un'app business critical e che devono investire nella sua sostenibilità a lungo termine, invece di cercare di risparmiare sui costi a breve termine (ci hanno provato, visto i risultati e imparato la lezione). In questo senso, questo è un posto di lavoro onirico. In tutti i precedenti progetti legacy in cui ho lavorato, lo stato del codice era più o meno lo stesso, ma la gestione era lontana da questo livello di comprensione.

Segui la regola del boy scout, lascia tutto il codice che tocchi in condizioni migliori di quando sei arrivato. Questo dovrebbe essere parte delle attività quotidiane di codifica. Puoi anche eseguire metriche sulla base di codici utilizzando vari strumenti. Ma il metodo migliore è renderlo parte dell'attività quotidiana.

Certo che lo è. Chiunque dica diversamente funziona in un universo alternativo.

Fa parte del lavoro quotidiano, ma molte aziende più piccole non gradiranno ammetterlo. C'è tutto sulle nuove funzionalità, sull'innovazione, sulle cose per cui è possibile caricare un client.

È piuttosto difficile caricare i client per la manutenzione della propria base di codice quando non l'hanno richiesto e non ne traggono alcun vantaggio tangibile.