Come si superano i propri pregiudizi di codifica quando viene consegnato il codice legacy? [chiuso]

Come programmatori, siamo spesso orgogliosi delle nostre capacità e abbiamo opinioni molto forti su cosa sia il codice "buono" e il codice "cattivo".

In qualsiasi momento della nostra carriera, probabilmente abbiamo avuto qualche sistema legacy lasciato cadere sui nostri giri e abbiamo pensato "Mio Dio, questo codice fa schifo!" perché non rientrava nella nostra idea di quale dovrebbe essere un buon codice, nonostante possa essere stato un codice perfettamente funzionante e gestibile.

Come ti prepari mentalmente quando cerchi di concentrarti sul lavoro di un altro programmatore?

Per qualsiasi base di codice legacy, il modo corretto di prepararsi mentalmente per affrontarlo è iniziare scrivendo unit test per esso .

Che faccia schifo o no, devi prima avere la sicurezza di poterlo cambiare senza rompere le cose!

Non posso dirvi quante volte ho detto "Oh, questo è totalmente sbagliato", l'ho riscritto e poi ho scoperto a fondo il motivo per cui quel codice è stato scritto in quel modo. Di solito, è un requisito non ovvio non scritto / non documentato. Almeno, questo è vero nel codice legacy su cui sto attualmente lavorando.

Aspetti di essere abbastanza a lungo da imbatterti nel tuo merdoso codice legacy. È un'esperienza umiliante e parte del processo di apprendimento. Desidero ardentemente il tempo in cui sapevo tutto.

Penso che Fosco abbia avuto un grande punto di vista nel metterlo nel contesto di potenziali limiti di tempo e funzionalità. A volte sei costretto a far funzionare qualcosa.

E infine, arriva a capire che è per questo che hai un lavoro.

Ridi, sforzati di non giudicare troppo, e basta. Non è bello essere un vero nazista di codice ... Esiste sicuramente qualcosa di "abbastanza buono" o addirittura "abbastanza buono al momento". Ci sono molte volte in cui qualcosa viene sviluppato o bendato per risolvere una crisi, quindi mai rivisitato.

Se è davvero male, vedi se riesci a fare un caso per riscriverlo .. se non è importante, entra e esci.

Scegli le tue battaglie. Conoscere la differenza tra "Non lo scriverei in questo modo" e "Questo crea una seria sfida di mantenimento o supporto"

Spesso trovo utile avere un'idea di ciò che gli sviluppatori originali pensavano fosse buono.

Cerca modelli e temi per quello che hanno fatto e molte volte scopri che c'erano delle ragioni per alcune delle strane decisioni.

A volte scopri che lo sviluppatore originale era effettivamente cattivo, ma hai un'idea di che tipo di cattivo vendessero allora.

Ad ogni modo, dopo aver fatto questo dovresti avere una migliore immagine di dove potresti iniziare una riscrittura o come sarebbe una soluzione rapida senza dover rifattare tutto.

Ancora più importante, non dare per scontato che solo perché è brutto, è un male. Niente ti fa sembrare più sciocco che passare il tempo a modernizzare qualcosa solo per scoprire che è meno capace dell'originale.

Se ho il tempo di attaccarlo e uccidere il codice scritto male.

È guerra.

Ho sempre pensato che il brutto codice sia un codice che ha visto molti debug, con molte sottigliezze che non sono evidenti con un'ispezione superficiale. Se lo sostituisco o lo ridisegno profondamente, devo assicurarmi di comprendere assolutamente ogni aspetto di ciò che fa il codice. Se non ho il tempo di arrivare in fondo, devo adottare un approccio a rischio minimo, apportando il minimo cambiamento possibile per raggiungere i miei obiettivi.

Di solito farò una piccola correzione / modifica e proporrò una funzionalità per lo sviluppo successivo che scuserebbe arrivare al fondo delle cose e refactoring il tutto. Quindi faccio del mio meglio per ignorare il codice fino a quando la funzione non finisce sulla roadmap.

Quando il codice legacy ha più di un paio d'anni, potrebbe essere stato scritto in quel modo a causa delle limitazioni nella lingua, nei sistemi operativi ecc. Esistenti al momento della scrittura del codice. Ehi, adesso sembra brutta, ma poi è andata male? Cerco di supporre che lo sviluppatore avesse una ragione per quello che ha fatto. Questa ragione potrebbe non essere più applicabile, ma supponendo che ci fosse una invece della semplice incompetenza (i giovani programmatori penseranno la stessa cosa al tuo codice tra 5 anni forse anche meno) ti rende meno arrabbiato. Se funziona e non ci sono problemi ad esso associati, custodisci quel codice legacy, non importa quanto brutto, in quanto ti consentirà di risolvere problemi più interessanti.

In passato, quando non avevo avuto il tempo di pisciare sul codice di qualcun altro e di batterlo nel "mio" stile, ho dovuto ricorrere ad essere molto guidato dalle attività:

Cosa sto cercando di aggiungere a questo codice / correzione / far funzionare?

Quello che sto facendo sta lavorando per raggiungere quell'obiettivo? In caso contrario, smetti di farlo e torna all'ultima volta che stavo apportando modifiche orientate alle attività.

Ho finito con questo compito? In tal caso, smetti di armeggiare con il codice, anche se sembra che sia stato scritto da uno stampo marziano non senziente.

A meno che tu non sia pronto a possedere il codice e le eventuali correzioni necessarie in futuro, non toccarlo. Supererai la tendenza a voler riparare qualcosa quando rompi qualcosa che non hai scritto perché non l'hai studiato abbastanza bene prima di entrare, e ci vogliono 2 giorni e un'esercitazione antincendio per farlo funzionare di nuovo .

Non fraintendetemi ... ci sono motivi legittimi per il refactoring del codice, ma se un'azienda richiede che il codice funzioni, e lo "aggiustate" senza conoscerne le conseguenze prima di entrare, chiedete un mondo di dolore .

Rifattorizzare un po 'alla volta può essere utile, ma fai molta attenzione a cambiare qualsiasi piccolo aspetto di come si comporta effettivamente il codice a meno che tu non capisca perché quel comportamento è presente e cosa influenza. Sfortunatamente, il codice che ne ha più bisogno a volte è il più difficile da modificare senza toccare il comportamento, anche se di solito è possibile raddrizzare parti di esso o almeno commentarlo.

In questi giorni sto lavorando quasi esclusivamente al codice legacy e penso sempre "Oh sh% t, cosa stavano pensando?" . Quindi inizio a scrivere unit test per il codice e questo è il punto in cui devo davvero analizzare il flusso di controllo e le dipendenze.

A volte non è possibile scrivere facilmente unit test. Ma mentre provo a ottenere informazioni sul codice e capirò perché è stato scritto così com'è. A volte ciò dimostrerà che il codice è davvero un casino, a volte capisco il processo di pensiero degli sviluppatori originali e posso aggiungere documentazione utile o riscrivere un pezzo di codice quando voglio aggiungere una nuova funzionalità.

Per me aiuta a pensare che il mio codice sarà lo stesso per me quando torno tra 12 mesi .

Con l'esperienza arriva il giudizio per sapere quando il codice è davvero pessimo e quando è appena scritto in uno stile diverso. Se è perfettamente funzionale e mantenibile e c'è una buona copertura dei test automatizzati , allora non è male e devi solo aprire la tua mente. Probabilmente imparerai qualcosa. Il codice errato non è funzionale e mantenibile.

Ecco alcuni marcatori di codice veramente cattivo:

• Grandi blocchi di logica sono stati duplicati invece di refactored.
• Dipendenze circolari tra classi o pacchetti
• Alto accoppiamento; bassa coesione
• Variabili inutilizzate, scrittura su variabili che non vengono mai lette, codice non raggiungibile.
• Reimplementazione delle funzioni di libreria standard, ad es. Formattazione della data.
• Logica inutilmente complessa; cioè 50 righe di codice in cui 10 farebbe bene.
• Nessun commento che descriva lo scopo di classi o metodi.
• Commenti fuorvianti.

La mancanza di test automatizzati non significa che il codice sia errato, ma significa che il progetto è errato.

Questi non sono una questione di gusti; queste pratiche rendono la manutenzione del programma molto più costosa.

Come ti prepari?

Accetta il fatto che ci vuole un po 'di tempo per poter lavorare con successo su una nuova base di codice. Se è "perfettamente mantenibile" e c'è un'elevata copertura dei test, ci vuole meno tempo ma non accadrà immediatamente. Se il codice è errato, la prima cosa che faccio è avvertire le parti interessate che è in cattive condizioni e che i progressi iniziali saranno lenti. Se sono scettici, appoggio il mio reclamo mostrando loro un campione di problemi nel codice reale e spiegando come varia dalle migliori pratiche del settore.