9 modi per padroneggiare il codice terribile, veloce

Ti è stato dato il compito di implementare una nuova funzionalità su una vecchia base di codice, ma il codice sembra terribile. Come puoi capirlo il più rapidamente possibile? Qui ci sono diverse scorciatoie per aiutare a imparare le parti importanti del nuovo codice senza perdersi nei dettagli irrilevanti.

Come programmatori, spesso dobbiamo unire nuovi progetti e la qualità del codice può essere ovunque. Anche con un team organizzato, mantenere la qualità del codice coerente in un progetto di medie e grandi dimensioni è una sfida.

Ecco perché comprendere rapidamente un codice scadente può essere un’abilità preziosa da avere. Può aiutare a diventare molto produttivo in breve tempo e ridurre lo stress che di solito viene fornito con l’essere il nuovo ragazzo e dover giocare catch-up. Essere in una conversazione con un collega e non sapere di cosa sta parlando quella persona metà del tempo è una sensazione terribile.

D’altra parte, questa è un’opportunità privilegiata per mostrare al tuo cliente o capo il tuo valore e che puoi aggiornarti rapidamente e impressionarli. La maggior parte degli sviluppatori impiegano settimane o mesi per diventare davvero produttivi con una base di codice che non hanno costruito da soli.

Ecco come padroneggiare rapidamente il codice terribile.

Chiedi aiuto. È la strategia più efficiente

Altre persone hanno già imparato come funziona il codice, quindi perché non chiederglielo? Si potrebbe pensare che ti fa apparire come il novizio, ma mostrando curiosità può avere un forte impatto sulla vostra immagine come un dipendente. Se l’aspettativa del tuo capo era che tu diventassi produttivo velocemente senza fare domande, questo è un errore di valutazione da parte sua.

Ognuno prende tempo per arrivare fino a velocità. Fai domande e impressionerai le persone che hanno l’atteggiamento giusto per il lavoro di squadra.

In molti casi, gli sviluppatori originali avranno preso decisioni strane o inaspettate, ed è qui che parlare del codice sarà molto più prezioso che leggerlo. Questo è ancora più il caso se la documentazione è carente. Ricorda, gli sviluppatori esistenti hanno una preziosa conoscenza del progetto che non è scritta da nessuna parte.

Crea un elenco di concetti che non hanno senso per te

Potrebbero esserci concetti di business nuovi per te o eccessivamente complessi. È importante ottenere chiarimenti su di loro prima di provare a lavorare sul codice che gestisce questi concetti, per evitare malintesi che potrebbero richiedere un po ‘ di tempo per capirlo.

Potrebbe anche essere il caso che queste idee siano erroneamente etichettate o rappresentate in modo inaspettato in un database. Quindi evita di essere stressato per avvolgere il tuo cervello intorno a questo, e vai alla fonte e chiedi ai tuoi colleghi di lavoro.

Allo stesso modo, potrebbero esserci moduli, classi o entità che non hanno nomi appropriati. Prendi nota di loro. Elementi scarsamente nominati possono portare a grande confusione, quindi documentali presto, così come qualsiasi altra cosa che influenzerà negativamente la tua capacità di pensare a come funziona il codice.

Semplifica la riproduzione dei bug

Aggiungendo il controllo delle versioni del codice e una macchina virtuale come Docker o Vagrant, ridurrai notevolmente il tempo necessario per riprodurre un bug e testare il tuo lavoro su una nuova funzionalità.

Qualsiasi tipo di malinteso su come funziona il codice potrebbe portarti lungo un percorso di costruzione della cosa sbagliata, o perché ciò che stai costruendo potrebbe già essere lì e non l’hai visto, o perché le cose non funzionano come pensavi.

A questo punto, si desidera avere il controllo della versione Git nel progetto. In questo modo sarete in grado di tornare a una versione stabile, o anche solo lavorare su rami separati che possono essere scartati se necessario.

È anche possibile ottenere una maggiore riproducibilità con Git, dal momento che è possibile utilizzare lo stash per aggiungere codice di test o debug mentre si scava in un problema difficile da tracciare.

Per conoscere l’architettura del progetto, eseguire le attività di configurazione e documentazione precocemente.

Lo stesso si può dire delle macchine virtuali e della riproducibilità. Sono diventati onnipresenti per qualsiasi team di sviluppo moderno, ma sicuramente ti imbatterai in progetti che non li stanno usando o addirittura pronti per essere eseguiti all’interno di uno. A volte il primo passo come nuovo membro del team è quello di documentare i passaggi che hai preso per far funzionare un ambiente e alla fine trasformare quei passaggi in uno script di installazione della VM.

Costruire un diagramma di componenti

Una mappa mentale di concetti di business, un diagramma entità-relazionale (ERD) delle tabelle del database, e un semplice diagramma di componenti del codice può notevolmente aiutare a ridurre il dolore di comprendere nuovo codice. Non ricordi come funziona qualcosa? Tieni aperto l’ERD.

In effetti, qualsiasi strumento grafico che ti aiuti a digerire rapidamente le informazioni e ad avere una vista di dieci mila piedi di un progetto sarà prezioso. Altri esempi di strumenti che potrebbero aiutarti sono grafici di dipendenza, registri e una mappa dello stack tecnologico del progetto.

Uno dei più grandi consumatori di tempo in fase di sviluppo è il punto di integrazione tra i sistemi. Avere una visione globale del panorama del progetto ti aiuterà a identificare quali punti di integrazione sono interessanti da esaminare. Questi sono i punti che hanno più lavoro messo in loro, e il maggior numero di bug.

D’altra parte, la tecnologia si muove velocemente e potrebbero esserci opportunità di sostituire ampie parti della base di codice con soluzioni più moderne e adeguatamente integrate. Un vecchio framework potrebbe aver sviluppato un modo nuovo e ufficiale per risolvere un problema, o una libreria completamente nuova potrebbe essere stata sviluppata con una migliore compatibilità in mente.

Utilizzare strumenti di visualizzazione e modellazione per visualizzare il quadro generale.

Preparati per i test automatici

Prima di iniziare a rompere le cose, è sempre prudente aggiungere test unitari pertinenti. Il problema con il test e il codice scadente è che il codice scadente è solitamente strettamente accoppiato e difficile (se non impossibile) da testare. Non è possibile isolare componenti che sono intrecciati e indivisibili.

In questi casi, fare un passo indietro e testare da più lontano. Di solito questo significa fare test di integrazione, per i quali ci sono molti strumenti disponibili. Le app Web possono essere testate contro le richieste HTTP, quindi è almeno possibile verificare che il sistema risponda allo stesso modo agli stessi input.

Il test di integrazione ha prestazioni molto peggiori rispetto ai test unitari, tuttavia. Ogni volta che puoi, implementa i test unitari in modo da poter avere un feedback più rapido sulle modifiche al codice. Se ciò non è possibile, optare per test funzionali o addirittura di integrazione.

Questo passaggio dovrebbe far luce sulle parti del codice che necessitano di lavoro. Se c’è una grande quantità di codice strettamente accoppiato, questo è un buon obiettivo per il refactoring dopo che i test di integrazione sono stati eseguiti e quindi per i test unitari in seguito.

Identifica strategie di codifica insolite o inadeguate

È ora di iniziare a fare un po ‘ di refactoring, ma da dove inizi?

Di solito, il posto migliore è dove le cose sembrano strane o dove le migliori pratiche di sviluppo non sono state seguite. Per lo sviluppo web, ciò potrebbe significare controller fat con codice modello strettamente accoppiato.

Tieni presente che le stesse strategie potrebbero essere in uso altrove. Quindi, se, ad esempio, si identifica che i controller fat sono presenti, è probabile che gli sviluppatori precedenti non abbiano tentato di avere controller thin. Ci si può aspettare di vedere lo stesso problema anche in altri controller, poiché ciò rifletteva lo stile o le carenze del processo di sviluppo prima d’ora.

All’inizio, lavorare su un piccolo compito

Correggere un piccolo bug su una funzionalità concettualmente semplice sarà molto illuminante e ti aiuterà a sentirti produttivo fin dall’inizio.

Questa è un’idea simile a quella che Andy Hunt e Dave Thomas chiamano “proiettili traccianti” nel programmatore pragmatico. La logica di fondo è la stessa: lavorare su qualcosa end-to-end per dimostrare a te stesso che è possibile, e poi migliorare progressivamente su quel lavoro iniziale.

L’approccio “tracer bullet”. Credito: Il programmatore pragmatico

Un buon esempio del tipo di semplice miglioramento che puoi fare è prendere piccoli passaggi di refactoring con codice semplice. Identificare una pratica di programmazione comune che non viene seguita e applicarla.

Uno dei miei preferiti per questo è blocchi condizionali non nidificanti. Quindi, invece di avere diversi blocchi if-if-if, uno all’interno dell’altro, nega il primo e restituisce, e fai lo stesso per tutti i controlli di tipo validazione che puoi trovare. Questo può essere semplice come invertire un controllo ” if ” e spostare del codice, quindi il rischio è quasi inesistente e il codice flat sarà più facile da leggere.

Assicurati di lavorare prima sulle funzionalità di refactoring che sono facili da testare, perché anche se le modifiche sono a basso rischio, è sempre una buona idea essere in grado di convalidare il tuo codice prima di inviarlo alla produzione.

Mettiti su un terreno familiare prima di affrontare il codice critico

Impara sempre come viene impostato il progetto per primo e solo dopo immergiti nel lato architettonico. I pezzi più critici del codice di business e di integrazione sono i più difficili da capire e modificare. Evitare di mettersi nei guai nella fase iniziale.

Come regola generale, evitare problemi di business che richiederebbero di sapere più di quanto si fa attualmente sul progetto, o sul lato business. Questo di solito significa stare lontano da transazionali, pagamenti o codice matematico fino a quando non inizia a diventare un terreno familiare.

Una volta che sei produttivo, sei a tuo agio con lo stile di codifica per il progetto e non hai problemi a risolvere problemi semplici, è ora di lavorare sulle cose più difficili, ma non prima.

Anche se c’è una certa urgenza per risolvere i problemi di pagamento, ad esempio, questo tipo di attività può essere incredibilmente rischioso. Un errore ci potrebbe costare caro il progetto, e che sarà su di voi pure. Assolutamente rifiutare di lavorare su compiti ad alto rischio nella fase iniziale, se possibile.

Come affrontare uno stack tecnologico sconosciuto

Per l’ultimo punto, un problema comune che ho incontrato è che ogni nuovo progetto di solito include alcune tecnologie che non ho familiarità con.

Quando ciò accade, ho un paio di strategie che mi aiutano a velocizzare velocemente. Il percorso ovvio per l’apprendimento è leggere la documentazione e familiarizzare con la nuova tecnologia. Ma mentre imparerai molto sulla struttura, quel percorso non ti aiuterà a imparare i casi d’angolo, che in genere vengono con l’esperienza. (“Caso angolare” è un termine ingegneristico che si riferisce a una situazione che si verifica al di fuori dei normali parametri operativi.)

Un modo per accelerare questo processo di acquisizione di esperienza è prendere risorse basate su domande come Stack Overflow e Quora e leggerle come un libro. Trova le domande più popolari sulla libreria che stai imparando e scopri in che tipo di problemi si imbattono in altre persone. Non ti imbatterai necessariamente in te stesso, ma solo sapere cosa è possibile è come far brillare una luce brillante sulla tua mappa mentale di quelle nuove idee.

Sfrutta le domande di overflow dello stack per acquisire esperienza velocemente. Credito: Stack Overflow

Per un approccio più mirato, trovare informazioni sulle funzionalità della libreria utilizzate nel nuovo progetto in modo specifico. Guarda in quelli che sono nuovi per te e imparali prima del tempo, prima che tu debba toccare quel codice.

Condividi le tue idee