Legacies Never Die: come gestire il codice legacy

Quando viene visualizzato il termine “codice legacy”, di solito viene detto o ricevuto con una sfumatura di disprezzo. Una ricerca preliminare su Google per “legacy code meme” porta in primo piano centinaia e centinaia di macro di immagini di persone che si strappano i capelli, sembrano sfinite o estremamente deluse.

Quando ho iniziato a lavorare come sviluppatore di software 6 mesi fa, non avevo idea di cosa fosse il codice legacy o cosa comportasse lavorare con esso.

Durante il mio quarto mese come sviluppatore junior, mi è stato chiesto di aggiungere un filtro di ricerca modale a un’app creata da uno dei miei colleghi due o tre anni fa. Sembrava abbastanza facile; Avevo passato la maggior parte degli ultimi quattro mesi a lavorare su un’app incredibilmente complessa per un altro client che coinvolgeva il nostro stack standard: TypeScript/React/Redux/Redux-Saga. Avevo già risolto molti problemi unici e mi sentivo sicuro della mia capacità di codifica abbastanza da creare una semplice modale per passare i parametri di query al back-end.

Come avrai intuito, non era così semplice. Ma perché?

Cos’è il codice legacy e perché può essere difficile gestire

Il codice legacy è un codice ereditato da un altro sviluppatore o team che utilizza tecnologie meno recenti che non sono più supportate o sono state sostituite da una versione più recente. Molti programmatori dicono che “il codice diventa codice legacy non appena viene scritto”. La differenza funzionale tra codice” normale ” e codice legacy potrebbe semplicemente essere che ha convenzioni diverse rispetto a quelle con cui sei abituato a lavorare.

Nel mio caso, l’app a cui sono stato assegnato utilizzava Flow piuttosto che TypeScript, e non era così fortemente tipizzata come ero abituato. Ciò ha reso un po ‘ più difficile per me capire la struttura dei dati che venivano recuperati dal back-end. Nessun tipo significava che stavo eseguendo TypeErrors sul runtime molto più frequentemente, il che può essere difficile da eseguire il debug quando si scrive una funzionalità di grandi dimensioni. Inoltre, l’app utilizzava una versione molto più vecchia di React che doveva essere riconciliata con una versione compatibile della libreria di componenti che volevo utilizzare per costruire il modale.

Prima di entrare nel nocciolo di come gestire il codice legacy con un senso di equilibrio e razionalità, voglio aggiungere un disclaimer che il codice legacy non è tutto male e lavorare su un progetto legacy non deve essere terribile. Al contrario, lavorare sul codice legacy mi ha insegnato ad essere flessibile, paziente e, soprattutto, l’esperienza mi ha permesso di risolvere i problemi con una nuova prospettiva in un contesto nuovo.

In effetti, mi ha reso uno sviluppatore migliore di quanto non fossi prima di iniziare a lavorare attraverso la suddetta base di codice, e spero che anche il tuo progetto legacy possa insegnarti qualcosa.

Come gestire il codice legacy a livello tecnico

Foto di Jeff Sheldon su Unsplash

Leggere la documentazione e il codice commenti quando possibile

In un mondo perfetto, ogni codebase ha un README robusto che contiene spiegazioni concise di come funziona il progetto, commenti di codice che spiegano la logica esatta dell’autore originale, e l’intera applicazione ha perfettamente senso. Tuttavia, questo è raramente il caso. Molti READMEs non vengono aggiornati man mano che i progetti si sviluppano, le persone dimenticano di scrivere commenti, presumono che la loro logica sia ovvia per un nuovo sviluppatore, o semplicemente esauriscono il tempo per prendersi cura di queste cose.

Guarda la base di codice nel suo complesso

Se ti perdi e non sai da dove cominciare, poniti queste domande:

• Qual è lo scopo dell’app?
• Come scorrono i dati attraverso l’app?
• In che modo la tua funzione si inserisce nell’app?

Quando puoi avere un’idea del quadro generale, è più facile capire come affrontare al meglio il problema. Forse è necessario creare un nuovo file e creare un nuovo componente. Forse hai bisogno di scrivere una funzione di utilità e testarla. Qualunque sia il caso, comprendere il contesto più ampio del tuo problema è un buon primo passo per creare una soluzione.

Prova l’app manualmente e con test unitari quando possibile

Rompere temporaneamente un’app mentre aggiungi una nuova funzionalità è inevitabile, indipendentemente dal livello di sviluppatore che sei. Questo è normale e previsto, specialmente se sei nuovo al lavoro, lavorando in una base di codice legacy con uno stack non familiare o una combinazione dei due.

Il modo migliore per evitare che queste rotture diventino problemi a lungo termine è testare accuratamente la tua app con test unitari e test manuali. Avere questi test in atto e sapere esattamente che tipo di copertura si ottiene fuori di loro farà risparmiare voi e futuri sviluppatori un sacco di tempo. Inoltre, test rigorosi rendono l’app più scalabile e ti danno anche una leggera corsa alla dopamina ogni volta che i test vengono eseguiti.

Per i test unitari, è possibile utilizzare framework di test come Jest o Jasmine.

Per i test manuali, ti consigliamo di sviluppare una matrice di test e assicurarti che il documento sia accessibile ai futuri sviluppatori. Per la matrice, si desidera definire un insieme di azioni, il comportamento previsto, il comportamento effettivo quando si prova, e altri dettagli che sono importanti, in questo modo:

tratterò di come implementare entrambi i tipi di test di efficienza nel flusso di lavoro in un post futuro.

Chiedi aiuto

Supponendo che il tuo progetto sia stato scritto da un dipendente attuale o ex sul posto di lavoro, qualcun altro probabilmente sa cosa sta succedendo nell’app, o almeno ne sa abbastanza per farti staccare. Imparare a ingoiare il tuo orgoglio e chiedere a qualcun altro è un passo scomodo per alcuni, ma necessario per crescere come sviluppatore, e forse il tuo collega può insegnarti alcuni nuovi trucchi.

Un buon modo per fare un uso efficiente del tuo tempo (e del loro) è formulare domande informate. Prova a tornare a guardare la base di codice nel suo complesso e capire le lacune nella tua comprensione. Non solo li aiuterà a capire meglio qual è il tuo problema, ma dimostra che hai preso l’iniziativa di cercare di risolvere il problema da solo.

Sapere quando tagliare le perdite

Se stai spendendo troppo tempo cercando di mettere il piede nella porta e non hai fatto alcun passo serio verso l’implementazione della funzione dopo aver provato i passaggi precedenti, potrebbe valere la pena di refactoring il codice intorno alla tua funzione. Non arrenderti troppo facilmente, ma tieni anche a mente quali sono le tue scadenze e cosa si aspetta da te il tuo project manager.

Detto questo, ci sono degli svantaggi nell’andare in questo modo:

• Riscrivere il codice può introdurre bug, anche se questo può essere in qualche modo aggirato con un buon test delle unità.
• Riscrivere il codice può rimuovere funzionalità nascoste, anche se questo può anche essere aggirato con buoni test unitari.
• Se hai poco tempo, scrivere codice al di fuori della tua funzione in aggiunta alla tua funzione potrebbe effettivamente richiedere più tempo rispetto alla semplice costruzione attorno ad essa.

Tutto sommato, usa il tuo miglior giudizio. Ci sono pro e contro per entrambe le scelte, ed è tutto dipende dalle circostanze individuali e dal budget del progetto.

Come affrontare il codice legacy a livello psicologico

Foto di Simon Migaj su Unsplash

Ora che abbiamo coperto gli aspetti tecnici della gestione del codice legacy, parliamo di come affrontarlo utilizzando le nostre soft skills. Dopo tutto, gli sviluppatori sono persone, non solo i robot di codifica, e affrontare problemi impegnativi su progetti che richiedono creatività e paternità possono essere emotivamente tassanti, non solo per te, ma anche per i tuoi colleghi.

Sii umile e gentile

Questo è qualcosa che ammetterò timidamente che ho bisogno di praticare di più. Quando mi è stato assegnato il progetto modale del filtro, ero abbastanza vocale su come janky e poco attraente il codice doveva affrontare mentre l’autore originale del codice era seduto a 15 piedi di distanza da me. Intendevo che i miei commenti fossero uno scherzo, ma col senno di poi riconosco che ero arrogante e offensivo, e che avrei dovuto essere più empatico.

Ci sono molti fattori che possono portare al codice legacy che sembra “spento” che dovresti prendere in considerazione prima di iniziare a criticare l’autore o assumere il peggio su di loro (Questo è vagamente legato all’errore di attribuzione fondamentale!).

L’autore originale potrebbe aver avuto le sue ragioni per scrivere il codice nel modo in cui lo hanno fatto.

I vincoli di tempo e i vincoli tecnologici possono causare a una persona di scrivere codice che funziona, ma non ha necessariamente la migliore convenzione. Se ti immagini in una situazione con non abbastanza tempo, strumenti obsoleti e una lista di cose da fare lunga un miglio, probabilmente non scriveresti nemmeno il codice migliore!

Le convenzioni cambiano.

Nei vecchi progetti di Olio Apps, la convenzione per il codice utilizza virgolette singole per dichiarare stringhe e due spazi erano uguali a una scheda. Avevamo più piccoli componenti React nidificati all’interno di un singolo file. Nella nostra convenzione attuale, usiamo virgolette doppie e quattro spazi, e ogni componente React, non importa quanto piccolo, vive nel proprio file.tsx nella directorycomponent. E tra diversi anni, sono sicuro che cambierà anche questo.

Tutto il codice alla fine diventa legacy

Questo si ricollega al punto precedente: il tuo codice alla fine sarà legacy. Mentre sali la scala dell’anzianità, i nuovi sviluppatori saranno assunti e dovranno mantenere il tuo vecchio codice. Potresti scrivere codice pulito, impeccabile e ASCIUTTO, ma una volta che le convenzioni cambiano o le tendenze cambiano, i nuovi sviluppatori potrebbero visualizzare il tuo codice allo stesso modo in cui visualizzi il codice legacy di altri.

Sii orgoglioso dei piccoli successi

Non è facile lavorare al di fuori delle tue convenzioni abituali; c’è una ragione per l’enorme quantità di memi e battute sul trattare con il codice legacy. Se hai mai imparato una lingua al di fuori della tua lingua madre, sai come ci si sente a dimenticare una parola o un termine nella tua seconda lingua, ma ricordalo nella tua lingua madre e non essere in grado di tradurre attraverso il divario. Lo stesso vale per cambiare tra convenzioni moderne e legacy. A volte ci vuole solo un minuto per orientarsi.

Nell’essere in grado di navigare con successo il codice legacy, stai mostrando la tua capacità di essere adattabile, che è un’abilità importante che ti avvantaggia nel tuo lavoro attuale e in tutti i tuoi lavori futuri, indipendentemente dal fatto che questi lavori siano nel campo della tecnologia o meno. Codice legacy è il parco giochi perfetto per praticare questa abilità.

In conclusione:

Usa questo tempo per rafforzare la tua scrittura di codice

Ora che hai avuto l’esperienza di lavorare in una base di codice legacy, dovresti allontanarti da esso con un senso migliore di ciò che ti piace e non ti piace in termini di strumenti e convenzioni. Queste sono cose che si possono portare avanti in progetti futuri, e ti fanno meglio a rivedere il codice degli altri, offrendo critiche costruttive, e dando mentorship.

Sviluppare applicazioni per l’utente e il futuro sviluppatore

Se hai avuto l’esperienza di grande documentazione e commenti di codice o nessuna documentazione o commenti di codice, si può vedere come sia la documentazione e commenti sono potenti strumenti per aiutare i futuri sviluppatori navigare il progetto. Condividi un obiettivo comune di volere un’app liscia, funzionale e ASCIUTTA; mantenere la documentazione e lasciare commenti di codice informativi è un buon modo per colmare questa lacuna.

Ricorda che anche il tuo codice sarà legacy un giorno

L’ho già menzionato alcune volte, ma è importante ribadire che anche il tuo codice sarà legacy, non importa quanto siano ASCIUTTI e incontaminati il tuo codice e la tua logica.

L’asporto più importante è quello di essere flessibile, umile, e che si può sicuramente imparare nuovi trucchi dal vecchio codice.