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

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

Lo stesso vale per il codice, probabilmente i tuoi colleghi hanno imparato a filtrare il "codice rumore" 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 un codice base come quello che descrivi. Probabilmente i tuoi colleghi hanno avuto molto più tempo per svilupparsi e possibilmente hanno raccolto convenzioni, schemi e costrutti che non saltano fuori "principianti di codice base". Potrebbe esserci più struttura nel caos di quanto tu possa immaginare. Parla con i tuoi colleghi, chiedi loro di accoppiare con te un po 'di tempo e scegli il loro cervello su come affrontano la risoluzione di uno dei bug assegnati a te. Quando ti chiedono di aprire l'unità X, Y o Z, chiedi loro perché quello, che dire è che potrebbe essere pertinente, ecc.

Essere perso in un metodo di migliaia di linee è normale. Attaccalo con un buon editor di piegatura e aggiungendo commenti per dividere le varie parti in funzioni e / o procedure senza farlo effettivamente. Anche la stampa di materiale e l'utilizzo di un evidenziatore vecchio stile possono aiutare.

Refactoring senza la rete di sicurezza dei test unitari si sta sparando ai piedi. Non farlo. Non farlo.

Nessuno ti chiede di tenere tutto in memoria. Se i tuoi colleghi non vogliono o hanno bisogno di un sistema di bug, scrivi l'attività assegnata a te nella tua lista di cose da fare e scrivi le note quando / dopo parlerai 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 sono semplicemente più esperti con il codice base, 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 fa effettivamente UVW ma non è mai stato rinominato per ragioni storiche. tuttavia, se mai dovessero prendersi qualche mese di codice, inizieranno a sentire il tuo dolore.

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

per il punto 5 secondo crea un foglio Excel con i bug che stai attualmente lavorando come elenco di cose da fare 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 sembra un problema di memoria. Sembra che le tue abitudini / tendenze di lavoro non siano adatte a quello che stai incontrando, e stai facendo troppo pensare ai tuoi colleghi e non a te stesso.

1. Mille linee di metodo - tutti se ne andranno persi a meno che non lo facciano ci ho appena lavorato. Potrebbero essere più veloci nel riprenderlo o recuperarlo. Non puoi cambiarlo se non attraverso l'esperienza, e forse neanche in quel momento.

2. Rifattorizzare l'introduzione di bug, beh, questo è sempre un rischio. Puoi provare a sviluppare test unitario per coprire ciò che si sta cambiando prima di farlo, ma ciò potrebbe accadere non essere consentito dalla direzione (probabilmente no, o sarebbe già stato fatto). E i test unitari non sono magici a cui possono ancora mancare le cose, è ancora possibile introdurre bug. È probabile che non stiano procedendo al refactoring. Questo risale a (1), loro probabilmente cercherò di concentrarti solo su ciò che deve essere corretto, nel senso che ottengono il punta più velocemente, ma manca l'immagine più grande e impiegherà più tempo per sistemare il prossimo cosa in quel casino di mille righe.

3. Crea ciò che ti serve per portare a termine il lavoro. Se ciò significa creare un flusso grafico o altra documentazione, quindi fallo. Se ne hanno bisogno o no, e se lo usano o meno dopo averlo creato, è irrilevante.

4. Le interruzioni rallentano tutti. Concentrandoti su questo ti rallenterai Di Più. Accettalo e prova a tornare al ritmo il più velocemente possibile.

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

La programmazione non è una memoria perfetta, e non si tratta di essere in grado di ignorare le distrazioni - concentrandosi su questo sono solo le distrazioni che stai creando.

CAVEAT / UPDATE: dopo aver letto la risposta di sotto, ho sentito che potrebbe essere un po 'troppo duro. Non è mia intenzione, l'ambiente che descrivi è terribile e interesserebbe la maggior parte delle persone (probabilmente anche i programmatori migliori ne soffrono, ma sono "migliori" per il confronto con gli altri nello stesso ambiente). La mia risposta è solo una riflessione punto per punto nelle domande, supponendo che l'ambiente non cambierà (anche se dovrebbe).

Risposta totalmente opinabile:

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

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

3) blocco note e penna. O un documento word / excel. Non così difficile da risolvere.

4) questo è un problema personale di concentrazione. Non sono sicuro che sia fattibile per migliorarlo da solo, però.

5) utilizzando un sistema di ticket o non dovrebbe essere deciso dai programmatori ma dal project manager. Chiedi la sua opinione / presenta i tuoi punti. Se è contro di esso, appunta di nuovo il blocco note e la penna.

Ho già vissuto una situazione del genere prima e basandomi su quell'esperienza posso dire che il tuo problema non è legato alla memoria e che c'è qualcosa nella tua mente (sicuramente non correlato al lavoro) che ti sta rendendo stressante e ti mantiene dalla messa a fuoco del 100% sull'attività in corso.

Quindi il primo passo è liberare la mente da quella roba quando sei sulla 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 suggerimenti sul loro approccio al refactoring.

Infine non sentirti imbarazzato se devi scrivere i problemi che hai risolto e / o stanno funzionando in questo momento (non dovrebbe essere un sofisticato sistema di tracciamento dei bug) è meglio essere certi di qualcosa perché tu leggilo dai tuoi appunti piuttosto che affermarlo dalla cima della tua testa senza essere sicuro al 100% di esso