Come rimanere produttivi quando si tratta di codice estremamente mal scritto?

Mi dispiace dirtelo, ma non tutti i lavori sono pieni di sole e glamour. La maggior parte delle attività di sviluppo comportano lavori di drudge come questo. Triste ma vero.

Hai il compito di svolgere un lavoro importante, anche se è noioso fino al punto di guardare la vernice asciutta. È importante per due motivi: 1. Aggiunge la registrazione necessaria ad un sistema di grandi dimensioni in modo che quando qualcosa va storto avrai uno strumento che ti aiuterà a trovarlo. e 2. Ti dà familiarità con il codice di base in modo che se e quando qualcosa va storto puoi saltare dentro e sistemarlo.

In pratica stai creando la tua rete di sicurezza qui. Glamour, no, ma sì importante!

Quindi, detto questo come dovresti motivarti? Quando ho un compito sconvolgente al lavoro, ho fissato degli obiettivi per me stesso. Termina l'esecuzione dell'attività x entro la fine della settimana. Se faccio il mio obiettivo, mi ricompenso. Nuovo ristorante voglio provare? Vai venerdì sera se finisco. Il nuovo film è appena uscito? Vedilo nel fine settimana se finisco.

Trovo di parlare con il mio supervisore e di fargli sapere dove sono e come sto procedendo mi rende responsabile. Se dico loro che farò il lavoro entro venerdì, mi sento più propenso a farlo entro venerdì b / c. Ho detto loro che l'avrei fatto.

Continua a credere che una volta che avrai completato questo compito e lo avrai fatto bene, in tempo e nel budget che la gente noterà e quando arriverà quel nuovo shinny, il tuo nome potrebbe essere suggerito come colui che lo ottiene. :)

Conserva un file di snippet di codice candidato da inviare a thedailywtf.com. Anche se non hai intenzione di inviarli, ti dà un lato positivo nel trovare un codice che sia anche peggiore della media.

Mi trovavo in una situazione simile, con il compito di ripulire un grande numero di codice scritto e copiato in modo massivo e incollato.

Per mantenere la mia motivazione e il mio equilibrio, ho scritto uno script chiamato current_score che contava la LOC nel progetto (che diminuiva costantemente, eliminando la duplicazione e passando agli algoritmi migliori) e confrontandolo con il LOC quando ho iniziato . Ogni volta che mi sentivo scoraggiato o frustrato dalla montagna di codice che stavo affrontando, correre current_score mi avrebbe dato un senso di progresso tangibile e mi avrebbe ricordato quanto avevo già realizzato. Ed è stato divertente vedere quanto è alto il punteggio che potrei accumulare quando affronto una sezione di codice particolarmente brutta.

Cercherei metriche simili che potresti facilmente scrivere per darti un senso di progresso e trasformarlo in un gioco di sorta. Linee di codice (esegui wc -l ), complessità ciclomatica (che dovrebbe andare giù mentre ripulisci quei "nidi" nidificati, linee di codice che sono state toccate da te al posto del tuo predecessore (penso che FishEye puoi dirti questo per $ 10), ecc. Potresti anche scrivere uno script Perl senza molti problemi per contare il numero di blocchi di codice che non hanno ancora dichiarazioni di registrazione.

Ho visto questo libro consigliato: Lavorare efficacemente con il codice legacy , ma per fortuna non ho avuto un bisogno di leggerlo.

Come stai facendo, devi rifattorizzare ciò di cui hai bisogno in modo che tu possa capire il codice e solo ricordare che stai rianimando un sistema, che pagherà quando lo mantieni.
Questo dovrebbe sperare di mettere una molla nel tuo passo sulla via di casa.

Cerca di rompere il progetto in blocchi. Ogni giorno impara come funziona un pezzo specifico. Cercando di capirlo tutto in una volta è probabilmente quello che ti sta stressando.

Sii orgoglioso di rendere il progetto migliore. Ci sono altri programmatori con cui puoi parlare? Aiuta a stare in piedi intorno al refrigeratore d'acqua discutendo / ridendo dell'ultima logica che hai trovato. Cerco di farlo per mantenere un'atmosfera gioviale al lavoro.

prendi appunti dettagliati per organizzare le tue domande, i tuoi pensieri e la tua comprensione del sistema. Questo ha funzionato a meraviglia per me quando si tratta di sistemi legacy di grandi dimensioni. Aiuta a cristallizzare la tua comprensione, aiuta a mettere le domande aperte in parole e, poiché i tuoi pensieri sono già messi insieme, rende più facile comunicare spontaneamente con gli altri su problemi / domande / idee / ecc.

Ad esempio, mentre sto esaminando una parte del codice, prenderò costantemente appunti a me stesso. Questa è la mia conversazione con me stesso. Il semplice atto di scrivere aiuta a far uscire più pensieri e mi aiuta a capire meglio le cose. Dopo un po 'potrei avere un Eureka e ho bisogno di disegnare un piccolo diagramma con il "quadro più grande" su carta per illustrare ciò che ho appena pensato o quali pezzi ho appena messo insieme. Lo faccio sempre solo su carta, liberandomi di tutte le distrazioni del computer. Questo mi consente di essere più metodico e riflessivo su quello che sto facendo.

Questo è fondamentalmente un modo conveniente per avere una conversazione perpetua con un esperto di dominio :)

So che potresti sentirti improduttivo perché lo stai osservando dal punto di vista di "Aggiungo solo il logging" quando, in realtà, stai aggiungendo la registrazione e eseguendo un sacco di refactoring. Il tuo supervisore è probabilmente a conoscenza della situazione del codice. Tutti potrebbero non apprezzarlo ora, ma quando avrai una richiesta per aggiungere una funzionalità davvero interessante e stimolante, sarai felice di aver ripulito il codice.

In questi casi tendo a riscrivere una sezione di codice. Per fare in modo che un'area risucchi di meno e poi aggiungo qualche altra registrazione. Quindi ripulisci altro codice. Il codice errato è solo cattivo se lo lasci lì.

Gamify your work. Ad esempio, concediti 5 punti ogni volta che fai una buona domanda sul codice e 10 punti ogni volta che rispondi. Regalati un badge ogni volta che rifatti un metodo o aggiungi una nuova funzione. Una volta accumulato abbastanza punti ottieni privilegi come pause caffè o biscotti. Una volta completato l'intero progetto, hai il privilegio di regalarti qualcosa che desideri veramente.

Il trucco per non annoiarsi o arrabbiarsi così da rimanere produttivi è accettare che il codice sia mal progettato. Accettare la tua posizione per dover comprendere e aggiornare il codice ti consentirà di non continuare a commentare "quanto è stupido" e invece accettarlo tranquillamente e andare avanti.

Un altro trucco è avere una buona homelife che non vede l'ora che arrivi alla fine della giornata. Fidanzata, amici, giochi qualsiasi cosa funzionerà, per darti l'obiettivo di superare la giornata e rendere il faticoso codice anche se non valido.

"Lavorare efficacemente con il codice legacy" di Michael Feathers può aiutare.

Se sei preoccupato di rompere le cose quando le cambi, scrivi prima alcuni test, assicurati che passino prima e dopo aver apportato le modifiche. Scrivere il test dovrebbe aiutarti a riassumere e capire cosa fa un dato pezzo di codice e ti permetterà di modificarlo con sicurezza.