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

Per qualsiasi codice legacy, il modo corretto per prepararti mentalmente a gestirlo è iniziare scrivendo test di unità per esso .

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

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

Aspetti di essere in giro abbastanza a lungo da imbatterti nel tuo pessimo codice legacy. È un'esperienza umiliante e parte del processo di apprendimento. Ho nostalgia del tempo in cui sapevo tutto.

Penso che Fosco abbia avuto il grande vantaggio di essere in grado di inserirla nel contesto di tempo potenziale e amp; restrizioni di funzionalità. A volte sei costretto a far funzionare qualcosa.

E per ultimo, vieni a capire che questo è il motivo per cui hai un lavoro.

Ridi di farlo, cerca di non giudicarlo troppo e fallo passare. Non è bello essere un vero codice-nazista ... Esiste sicuramente qualcosa come "abbastanza buono" o anche "abbastanza buono in quel momento". Ci sono molte volte in cui qualcosa viene sviluppato o bendato per risolvere una crisi, quindi mai rivisitato.

Se è davvero brutto, vedi se riesci a creare un caso per riscriverlo .. se non è importante, entra e usciti.

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

Spesso trovo utile avere un'idea di ciò che gli sviluppatori originali ritenevano opportuno.

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

A volte si scopre che l'originale dev era in realtà cattivo, ma si ha un'idea di che tipo di male stavano vendendo allora.

In ogni caso, dopo aver fatto ciò dovresti avere una visione migliore di dove potresti iniziare una riscrittura o quale sarebbe una soluzione rapida senza dover refactoring di tutto.

Soprattutto, non dare per scontato che solo perché è brutto è brutto. 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 lo attacco e uccido il codice scritto male.

È guerra.

Ho sempre ragione che quel brutto codice è codice che ha visto molti debuggings, con molte sottigliezze che non sono chiare con un'ispezione superficiale. Se lo sostituisco o lo riprogetto profondamente, devo assicurarmi di comprendere assolutamente ogni aspetto di ciò che fa il codice. Se non ho il tempo di scendere in fondo, devo adottare un approccio di rischio minimo, facendo il più piccolo cambiamento possibile per raggiungere i miei obiettivi.

Di solito farò una piccola correzione / cambiamento, e proporrò una funzionalità per lo sviluppo successivo che potrebbe scusare l'idea di andare al fondo delle cose e rifattorizzare l'intera faccenda. Quindi faccio del mio meglio per ignorare il codice fino a quando la funzione non termina sulla roadmap.

Quando il codice legacy ha più di un paio di anni, potrebbe essere stato scritto in quel modo a causa di limitazioni nella lingua o nei sistemi operativi ecc. che esistevano al momento della scrittura del codice. Ehi sembra brutto ora, ma è stato poi male? Cerco di pensare che lo sviluppatore abbia una ragione per quello che ha fatto. Quella ragione potrebbe non essere più applicabile, ma supponendo che ce ne fosse una invece che una generale incompetenza (i giovani programmatori penseranno la stessa cosa del tuo codice in 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ù eccitanti.

In passato, quando non avevo il tempo di incazzare il codice di qualcun altro e di averlo battuto in "mio" stile, ho dovuto ricorrere a un compito molto determinato:

Che cosa sto cercando di aggiungere a questo codice / correzione / lavoro?

È ciò che sto facendo lavorando per raggiungere quell'obiettivo? In caso contrario, smetti di farlo e ripristina l'ultima volta che ho apportato modifiche orientate all'attività.

Ho finito con questo compito? Se è così, 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 disposto a possedere il codice e le eventuali correzioni necessarie in futuro, non toccarlo. Supererai la tendenza a voler aggiustare qualcosa quando rompi qualcosa che non hai scritto perché non lo hai studiato abbastanza bene prima di entrare, e ti ci vogliono 2 giorni e una esercitazione antincendio per farlo funzionare di nuovo .

Non fraintendetemi ... ci sono dei motivi legittimi per il codice refactoring, ma se un business richiede che il codice funzioni, e lo "aggiustate" senza sapere le conseguenze prima di entrare, state chiedendo un mondo di dolore.

Il refactoring un po 'alla volta può essere utile, ma sii molto attento a cambiare ogni piccolo aspetto di come si comporta effettivamente il codice, a meno che tu non comprenda perché quel comportamento è lì e che cosa influenza. Sfortunatamente, il codice che ne ha bisogno è peggiore a volte è più difficile da cambiare senza toccare il comportamento, anche se di solito puoi raddrizzare parti di esso, o almeno commentarlo.

Al giorno d'oggi sto lavorando quasi esclusivamente al codice legacy e penso sempre "Oh sh% t, cosa stavano pensando?" . Quindi inizio a scrivere test unitari 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 test unitari. Ma mentre cerco di ottenere informazioni sul codice, capirò perché è stato scritto così com'è. A volte questo dimostra 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 è utile pensare che il mio codice sarà uguale a me stesso quando tornerò su di esso in 12 mesi .

Con l'esperienza arriva il giudizio di sapere quando il codice è veramente cattivo, e quando è appena scritto in uno stile diverso. Se è perfettamente funzionante e mantenibile e c'è una buona copertura di test automatizzata , allora non è male e hai solo bisogno di aprire la tua mente. Probabilmente imparerai qualcosa. Il codice errato non è funzionale e mantenibile.

Ecco alcuni indicatori di codice veramente scadente:

• Grandi blocchi di logica sono stati duplicati anziché refactored.
• Dipendenze circolari tra classi o pacchetti
• Alto accoppiamento; bassa coesione
• Variabili non utilizzate, 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; 50 linee di codice dove 10 farebbe bene.
• Nessun commento che descriva lo scopo delle classi o dei metodi.
• Commenti fuorvianti.

Una mancanza di test automatici non significa che il codice sia cattivo, ma significa che il progetto è cattivo.

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

How do you prepare yourself?

Accetta il fatto che ci vuole un po 'per essere in grado di lavorare con successo su un nuovo codice base. Se è "perfettamente mantenibile" e la copertura del test è elevata, ci vuole meno tempo ma non accadrà immediatamente. Se il codice è cattivo, la prima cosa che faccio è avvertire gli stakeholder che è in cattive condizioni e il progresso iniziale sarà lento. Se sono scettici, accendo il mio reclamo mostrando loro un esempio di problemi nel codice reale e spiegando come varia dalle migliori pratiche del settore.