Quando si sviluppa su una vecchia base di codice, dovrei usare Best Practices o andare per la coerenza [duplicato]

Potresti aver risposto alla tua domanda senza rendertene conto:

These projects are still utilized in production environments (without issue) and have new features implemented on a yearly cycle.

Se è davvero così, l'implementazione probabilmente non è così male come pensi. Se il software funziona ed è relativamente facile da mantenere, lo hai inchiodato. Inoltre, se riesci ad aggiungere facilmente nuove modifiche strutturali drastiche, allora hai veramente inchiodato.

Ricorderai sempre ieri con ciò che sai oggi e deciderà che ieri è in qualche modo inferiore a oggi. Questo è ciò che chiamiamo crescita e miglioramento, tuttavia ciò non implica che in qualche modo la giornata di ieri debba essere risolta.

Perché, oh, perché impiegheresti molto tempo a rendere un programma mantenibile, estensibile e funzionale esattamente la stessa cosa che era quando hai iniziato? Ci saranno evidenti vantaggi per gli utenti che non sono misurati in milionesimi di secondo o linee di codice che vedono raramente (se mai)?

Se, durante il ciclo di vita del programma, ti rendi conto che i metodi o le funzioni deprecati rendono il design esistente non tanto sensato quanto originariamente fatto, potrebbe essere necessario apportare alcune modifiche. Potrebbe anche essere necessario introdurre una funzione che giustifica alla fine tornare indietro e fare un sacco di ri-factoring.

Non rifare il factoring di qualcosa in produzione solo per il ri-factoring. L'intero obiettivo è scrivere codice che non debba essere drasticamente modificato in futuro, e sembra che tu abbia raggiunto quell'obiettivo. Perché cortocircuitare un successo?

Lascia il codice meglio di come l'hai trovato

C'è sempre una scarica di adrenalina per implementare rapidamente alcune nuove funzionalità o pattern quando trovi un brutto pezzo di codice, ma prima di saltare e ripulirlo ci sono pochi punti da sostenere. Dato che questo è il codice di produzione e sta funzionando, non è sempre adatto per eliminarlo e scrivere il tuo, che dovrà essere testato rigorosamente.

Dovresti identificare gli usi esistenti e in che modo i tuoi nuovi cambiamenti avranno un impatto su di esso, vale la pena investire del tempo poiché alcuni potrebbero aver bisogno di una rapida svolta per un problema.

Mi sto occupando di tutto ciò che era prima perché alcune funzionalità tendono a essere perse ( a volte non sempre e ti ritrovi a fissare il codice di nuovo tra una settimana )

In alcuni casi sarebbe impossibile modificare o potrebbero avere sforzi devastanti nel senso della timeline, il denaro e il mantenimento potrebbe essere un'opzione migliore.

Quindi prova ad elaborare alcune di queste righe e presumo che troveresti altri suggerimenti che si riversano in avanti, in ogni momento offri a la leggibilità una precedenza più alta rispetto alle ottimizzazioni (a meno che non ostacoli realmente qualcosa)

Devi mantenere la compatibilità, non la coerenza.

Segui regola boy scout , cioè lascia sempre più pulito di quello che hai trovato (incluso il tuo nuovo codice)

Ciò non significa che devi immergerti e refactoring fino a quando non è perfetto, significa solo refactoring incrementale quando ha senso farlo.

Cammina leggermente, perché calpesti i miei sogni.

Penso che la chiave di questo sia il buy-in. Sono sempre un sostenitore per il refactoring e il miglioramento del design del codice esistente, ma se si finisce per andare in tangente che nessun altro segue il tuo codice sembrerà così estraneo a loro che non sarà molto utile . Peggio ancora, potrebbero arrabbiarsi con te per aver rinnovato tutto il loro duro lavoro senza almeno qualche input nel processo e offrendo resistenza ad esso. Questa area è stata notevolmente migliorata dalle recensioni del codice. Con la revisione del codice, tutti i membri del team possono vedere la direzione che sta prendendo l'altro e offrire suggerimenti in modo che la base di codice si evolva con coerenza costante (assumendo che sia iniziata con coerenza).

Quindi, cerca di ottenere revisioni del codice se non lo sono già. Inoltre, quando si effettua un importante refactoring (o in alternativa alle revisioni del codice) invia una email ai membri del team facendogli conoscere le tue idee e chiedendo suggerimenti o critiche. Se ti accorgi che nulla di tutto ciò funziona e sei frustrato dalla resistenza ai miglioramenti, potrebbe essere il momento di trovare un lavoro in cui il cambiamento è accolto anziché temuto.