Come rimanere produttivi quando si tratta di codice scritto in modo estremamente scorretto?

Non ho molta esperienza nel lavoro nell'industria del software, essendo autodidatta e avendo partecipato all'open source prima di decidere di fare un lavoro. Ora che lavoro per soldi, devo anche occuparmi di cose spiacevoli, il che è normale ovviamente.

Recentemente mi è stato assegnato il compito di aggiungere la registrazione a un grande progetto di SharePoint che è stato scritto da un programmatore che ovviamente stava imparando a programmare il lavoro. Dopo 2 anni di collaborazione, il cliente è passato alla nostra azienda, ma il danno è stato fatto e ora in qualche modo ho bisogno di mantenere questo codice.

Non che il codice fosse troppo difficile da leggere. Nonostante i problemi - ogni progetto ha una classe con diversi metodi incollati, enormi ifannidamenti, sistemi ungheresi, connessioni non sovrapposte - è ancora leggibile.

Tuttavia, mi sono trovato assolutamente improduttivo nonostante abbia lavorato su qualcosa di semplice come aggiungere la registrazione. Fondamentalmente, ho solo bisogno di passare attraverso il codice passo dopo passo e aggiungere alcune chiamate di traccia. Tuttavia, l'idiozia del codice è così fastidiosa che mi stanco entro 10 minuti dall'inizio . All'inizio, avevo l'abitudine di aggiungere usingcostrutti, ridurre l'annidamento invertendo quelli if, rinominare le variabili in nomi leggibili, ma il progetto è grande e alla fine ho rinunciato. So che questo non è il compito che dovrei fare, ma almeno ridurre il disordine mi ha dato una sorta di ricompensa psicologica in modo da poter continuare. Ora il trucco ha smesso di funzionare e ho ancora il 60% del mio lavoro da fare.

Ho iniziato a soffrire di mal di testa dopo il lavoro e non ho più la sensazione di soddisfazione che provavo — che di solito mi permetterebbe di programmare per 10 ore di fila e di sentirmi ancora fresco.

Questa non è solo una grande occasione, perché ho davvero una vera domanda:

C'è un modo per rimanere produttivi e non combattere i mulini a vento?

C'è una sorta di trucco psicologico di rimanere concentrati sul compito, invece di pensare “Che stupido è che ?” Ogni volta che vedo un altro trucco intelligente dal programmatore precedente? Il problema con l'aggiunta della registrazione è che devo davvero capire cosa fa il codice, e così facendo mi fa male il cervello in modo spiacevole.

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

Ti viene assegnato un compito importante, anche se è noioso al punto di guardare la vernice asciutta. È importante per due motivi: 1. Aggiunge la registrazione necessaria a un sistema di grandi dimensioni in modo che quando qualcosa va storto avrai uno strumento per aiutarti a trovarlo. e 2. Ti farà familiarizzare con la base di codice in modo che se e quando qualcosa va storto puoi saltare e risolverlo.

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

Detto questo, come dovresti motivarti? Quando ho un compito anestetico al lavoro, mi pongo degli obiettivi. Termina di eseguire l'attività x entro la fine della settimana. Se realizzo il mio obiettivo, mi ricompenso. Nuovo ristorante che voglio provare? Vai venerdì sera se finisco. È appena uscito un nuovo film? Lo vedrò nel fine settimana se finisco.

Trovo che parlare con il mio supervisore e fargli sapere dove sono e come sto andando mi rende responsabile. Se dico loro che avrò finito entro venerdì, mi sento più incline a farlo entro venerdì b / c, ho detto loro che l'avrei fatto.

Tieni fede che una volta completato questo compito e lo hai fatto bene, in tempo e con budget che le persone noteranno e quando arriverà quel nuovo progetto luccicante, il tuo nome potrebbe essere solo suggerito come colui che lo ottiene. :)

Conservare un file di frammenti di codice candidato per l'invio a thedailywtf.com. Anche se non hai intenzione di inviarli, ti dà un aspetto positivo nel trovare del codice che è persino peggio della media.

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

Per mantenere la mia motivazione e la mia sanità mentale, ho scritto uno script chiamato current_scoreche contava il LOC nel progetto (che è diminuito costantemente, mentre eliminavo la duplicazione e passavo a algoritmi migliori) e lo confrontavo con il LOC quando ho iniziato. Ogni volta che mi scoraggiavo o frustravo con la montagna di codice che stavo affrontando, correre current_scoremi dava un senso di progressi tangibili e mi ricordava quanto avevo già realizzato. Ed è stato divertente vedere quanto sia alto il punteggio che potrei accumulare quando affronterò una sezione di codice particolarmente negativa.

Cercherei metriche simili che potresti facilmente scrivere per darti un senso di progresso e trasformarlo in una sorta di gioco. Righe di codice (appena eseguite wc -l), complessità ciclomatica (che dovrebbe andare giù mentre ripulisci quei "ifs" nidificati cattivi), righe di codice che sono state toccate da te anziché dal tuo predecessore (penso che FishEye possa dirti questo per $ 10), ecc. Potresti persino scrivere uno script Perl senza troppi problemi per contare il numero di blocchi di codice che non hanno ancora istruzioni di registrazione.

Ho visto questo libro raccomandato: lavorare in modo efficace con il codice legacy , ma per fortuna non ho avuto bisogno di leggerlo.

Come stai facendo, rifletti ciò di cui hai bisogno in modo da poter capire il codice e ricordare solo che stai rianimando un sistema, che pagherà quando lo mantieni.
Speriamo che questo metta una molla nel tuo passo sulla strada di casa.

Cerca di dividere il progetto in pezzi. Ogni giorno scopri come funziona un pezzo specifico. Cercare di capirlo tutto in una volta è probabilmente ciò che ti sta stressando.

Sii orgoglioso di migliorare il progetto. Ci sono altri programmatori con cui puoi parlare? Aiuta a stare in piedi intorno allo scambiatore di calore per discutere / ridere dell'ultima logica che hai trovato. Cerco di farlo per mantenere un'atmosfera gioviale al lavoro.

Prendi appunti dettagliati per organizzare domande, pensieri e comprensione del sistema. Questo ha fatto miracoli per me quando ho a che fare con 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 un pezzo del codice, prenderò costantemente appunti su di me. Questa è la mia conversazione con me stesso. Il semplice atto di scrittura aiuta a far emergere più pensieri e mi aiuta a capire meglio le cose. Dopo un po 'potrei avere un Eureka e dovrei disegnare un piccolo diagramma con la "foto più grande" su carta per illustrare cosa ho appena pensato o quali pezzi ho appena messo insieme. Lo faccio sempre solo su carta, eliminando tutte le distrazioni del computer. Questo mi permette di essere più metodico e attento a ciò 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 guardando dal punto di vista 'Sto solo aggiungendo il log' quando in realtà stai aggiungendo il log e stai facendo molto refactoring. Il supervisore è probabilmente a conoscenza della situazione del codice. Tutti potrebbero non apprezzarlo ora, ma quando ricevi 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 la registrazione altrove. Quindi ripulisci un po 'di codice. Il codice errato è negativo solo se lo lasci lì.

Gamify il tuo lavoro. 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 rifletti un metodo o aggiungi una nuova funzionalità. Una volta accumulati abbastanza punti ottieni privilegi come pause caffè o biscotti. Una volta completato l'intero progetto, ottieni il privilegio di regalarti qualcosa che davvero desideri.

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

Un altro trucco è avere una buona famiglia da non vedere alla fine della giornata. Fidanzate, amiche, giochi tutto funzionerà, per darti un obiettivo per superare la giornata e far valere la pena arrancare anche se brutto codice.

"Lavorare efficacemente con il codice legacy" di Michael Feathers può essere d'aiuto.

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 determinato codice e ti consentirà di modificarlo con sicurezza.