È normale che non riesca a tenere in mente più di tre bug assegnati a me, né posso capire mille righe di codice spaghetti?

Sto lavorando su una vecchia base di codice che non è ... perfetta , in un ambiente che non lo è neanche. Non è la peggiore base di codice che abbia mai visto in vita mia, ma ci sono ancora molti problemi: zero unit test; metodi con mille + righe di codice; incomprensione dei principi di base orientati agli oggetti; eccetera.

Fa male mantenere il codice.

1. Ogni volta che devo eseguire il debug di mille righe di un metodo mal scritto con variabili riutilizzate dappertutto, sono totalmente perso.
2. Alcune modifiche o refactoring che ho fatto hanno introdotto dei bug in altri punti dell'applicazione.
3. In mancanza di documentazione, test o architettura osservabile e combinato con metodi mal nominati, sento di riempire tutta la mia memoria di lavoro disponibile. Non c'è più spazio per tutte le altre cose che devo ricordare per capire il codice che dovrei modificare.
4. Le continue interruzioni sul posto di lavoro mi disturbano e mi rallentano.
5. Non ricordo più di due o tre compiti alla volta senza un sistema di tracciamento dei bug e li dimentico tutti durante il fine settimana.

I miei colleghi non sembrano avere problemi simili.

1. Riescono a eseguire il debug di metodi scritti male molto più velocemente di me.
2. Introducono meno bug di me quando cambio la base di codice.
3. Sembrano ricordare molto bene tutto ciò di cui hanno bisogno per cambiare il codice, anche quando richiede la lettura di migliaia di righe di codice in venti file diversi.
4. Non sembrano essere disturbati da e-mail, telefoni che squillano, persone che parlano dappertutto e altre persone che fanno loro domande.
5. Non vogliono usare il sistema di tracciamento dei bug che abbiamo già da quando usiamo TFS. Preferiscono solo ricordare ogni compito che dovrebbero svolgere.

Perché succede? È una particolare abilità che gli sviluppatori acquisiscono lavorando a lungo con codice scritto male? La mia relativa mancanza di esperienza con codici errati contribuisce a questi problemi / sentimenti? Ho problemi con la memoria?

Sì, è normale che le persone strutturate siano influenzate da codice / ambienti non strutturati. I tuoi colleghi probabilmente stanno filtrando meglio tutto il rumore di fondo. Come malato di emicrania so che la mia capacità di filtrare il mio ambiente diminuisce notevolmente quando si verifica un'emicrania. Le persone variano.

Lo stesso vale per il codice, i tuoi colleghi hanno probabilmente imparato a filtrare il "rumore del codice" che proviene da più livelli di astrazione in un singolo metodo e sono diventati esperti nel "frammentare" il codice in aree più ampie di funzionalità.

Ci vuole semplicemente tempo per adattarsi a una base di codice come quella che descrivi. Probabilmente i tuoi colleghi hanno avuto molto più tempo per approfondire e probabilmente hanno raccolto convenzioni, schemi e costrutti che non saltano fuori dai "novizi di base di codice". Potrebbe esserci più struttura nel caos di quanto tu possa immaginare. Parla con i tuoi colleghi, chiedi loro di accoppiarsi con te per un po 'di tempo e scegli il loro cervello su come si avvicinano per risolvere uno dei bug assegnati a te. Quando ti chiedono di aprire l'unità X, Y o Z, chiedi loro perché quello, che ne dici che potrebbe essere rilevante, ecc.

Perdersi in un metodo a mille righe è normale. Attaccalo con un buon editor pieghevole e aggiungi commenti per dividere le varie parti in funzioni e / o procedure senza farlo. Anche stampare le cose e usare un evidenziatore vecchio stile può aiutare.

Il refactoring senza la rete di sicurezza dei test unitari ti sta sparando al piede. Non farlo. Non farlo.

Nessuno ti richiede di conservare tutto in memoria. Se i tuoi colleghi non vogliono o non hanno bisogno di un sistema di bug, scrivi semplicemente l'attività assegnata nel tuo elenco di cose da fare e scrivi note quando / dopo aver parlato con qualcuno dei dettagli delle tue attività.

ci sono 3 punti principali che vedo:

i punti 1, 2 e 3 derivano dal fatto che i tuoi colleghi hanno semplicemente più esperienza con la base di codice, il che significa che conoscono le sue stranezze. Ciò significa che usano la loro memoria a lungo termine per il processo di debug e possono ricordare che doXYZ in realtà fa UVW ma non è mai stato rinominato per ragioni storiche. tuttavia, se dovessero mai impiegare qualche mese per codificarlo, inizieranno a sentire il tuo dolore.

per il punto 4 resistere alle interruzioni, non lasciare che gli affari non urgenti ti portino fuori dalla zona , ci vuole molto tempo per rientrarvi dopo un'interruzione; imposta l'IM della società su occupato, prova a programmare in blocchi lunghi (interi pomeriggi) di solo codifica

per il punto 5 secondi crea un foglio Excel con i bug su cui stai attualmente lavorando come todo list personale (o usa le funzionalità di gestione delle attività nel tuo IDE), sono disposto a scommettere che alcuni dei tuoi colleghi stanno facendo lo stesso

Non mi sembrano problemi di memoria. Sembra che le tue abitudini / tendenze lavorative non siano adatte a ciò che stai incontrando e stai pensando troppo ai tuoi colleghi e non a te stesso.

1. Mille metodi di linea - tutti si perderanno su questo a meno che non ci abbiano appena lavorato. Potrebbero essere più veloci a prenderlo o recuperarlo. Non puoi cambiarlo se non attraverso l'esperienza, e forse nemmeno allora.

2. Il refactoring che introduce bug, beh, è ​​sempre un rischio. Puoi provare a sviluppare unit test per coprire ciò che stai cambiando prima di farlo, ma ciò potrebbe non essere consentito dalla direzione (probabilmente no, o sarebbe già stato fatto). E i test unitari non sono magici, possono ancora mancare delle cose, puoi comunque introdurre dei bug. È probabile che non stiano effettuando il refactoring. Questo risale al (1), probabilmente provano a concentrarsi solo su ciò che deve essere risolto, il che significa che arrivano al punto più velocemente, ma perdono il quadro più grande e impiegheranno più tempo a riparare la cosa successiva in quel pasticcio di mille righe.

3. Crea ciò di cui hai bisogno per completare il lavoro. Se ciò significa creare un diagramma di flusso o altra documentazione, allora fallo. Se ne hanno bisogno o meno e se lo usano o no dopo averlo creato, è irrilevante.

4. Le interruzioni rallentano tutti. Concentrarsi su questo ti rallenterà di più. Accettalo e prova a tornare nel solco il più velocemente possibile.

5. Tenendo a mente due o tre bug non è male, tre o quattro sarebbe meglio, ma invece di cercare di migliorarlo, rinunciare e scriverlo. Pezzo di carta, lavagna, tfs, Excel, parola o blocco note: basta scriverlo. Scommetto che è quello che stanno facendo i tuoi colleghi. O quello o sistemare le cose a caso.

La programmazione non riguarda un ricordo perfetto e non si tratta di essere in grado di ignorare le distrazioni - concentrarsi su questo sono solo le distrazioni che si stanno creando.

CAVEAT / AGGIORNAMENTO: Dopo aver letto la risposta di seguito, ho sentito che potrebbe sembrare un po 'troppo duro. Non è mia intenzione, l'ambiente che descrivi è terribile e influenzerebbe la maggior parte delle persone (probabilmente anche i programmatori migliori lo soffrono, ma sono "migliori" rispetto ad altri nello stesso ambiente). La mia risposta è solo una riflessione punto per punto nelle tue domande, supponendo che l'ambiente non cambierà (anche se dovrebbe).

Risposta assolutamente discutibile:

1) Dipende dall'esperienza nella tecnologia, nel mantenimento dell'applicazione (più se è progettato male) e anche in parti specifiche dell'applicazione. Dipende anche dai tuoi problemi di concentrazione (numero 4)

2) È uguale al numero 1, ma utilizza una metrica diversa. Stessa risposta

3) blocco note e penna. O un documento Word / Excel. Non è così difficile da risolvere.

4) questa è una questione personale di concentrazione. Non sono sicuro se sia possibile migliorarlo da soli, comunque.

5) l'utilizzo o meno di un sistema di ticket non deve essere deciso dai programmatori ma dal project manager. Chiedi la sua opinione / presentare i tuoi punti. Se è contro di esso, blocca note e penna di nuovo.

Ho vissuto una situazione del genere prima e sulla base di quell'esperienza posso dire che il tuo problema non è legato alla memoria e che c'è qualcosa nella tua mente (sicuramente non legato al lavoro) che ti rende stressante e ti impedisce di concentrarti 100 % sull'attività da svolgere.

Quindi il primo passo è liberare la tua mente da quella roba quando sei nella tua scrivania.

Questo stress potrebbe anche essere aumentato perché ritieni di essere indietro in termini di produttività, quindi prova a parlare con i tuoi colleghi e chiedi loro consigli sui loro approcci al refactoring.

Infine, non sentirti in imbarazzo se devi scrivere i problemi che hai risolto e / o stai lavorando in questo momento (non dovrebbe essere un sofisticato sistema di tracciamento dei bug) è meglio essere certi di qualcosa perché l'hai letto da le tue note piuttosto che dichiararlo dalla parte superiore della testa senza esserne certi al 100%