É normal que eu não consiga manter na cabeça mais de três bugs atribuídos a mim, nem consigo entender mil linhas de código de espaguete?

Estou trabalhando em uma antiga base de código que ... não é perfeita , em um ambiente que também não é. Não é a pior base de código que já vi na minha vida, mas ainda há muitos problemas: zero testes de unidade; métodos com mais de mil linhas de código; incompreensão dos princípios básicos orientados a objetos; etc.

Dói manter o código.

1. Toda vez que tenho que depurar mil linhas de um método mal escrito com variáveis ​​reutilizadas por todo o lado, estou totalmente perdido.
2. Algumas modificações ou refatorações que introduzi introduziram erros em outros locais do aplicativo.
3. Na falta de documentação, testes ou arquitetura observável e combinada com métodos com nomes inadequados, sinto que preencha toda a minha memória de trabalho disponível. Não há espaço sobrando para todas as outras coisas que preciso lembrar para entender o código que devo modificar.
4. Interrupções constantes no local de trabalho me perturbam e me atrasam.
5. Não me lembro de mais de duas ou três tarefas por vez sem um sistema de rastreamento de bugs, e esqueço todas elas no fim de semana.

Meus colegas não parecem ter problemas semelhantes.

1. Eles conseguem depurar métodos mal escritos muito mais rápido que eu.
2. Eles introduzem menos erros do que quando altero a base de código.
3. Eles parecem se lembrar muito bem de tudo o que precisam para alterar o código, mesmo quando é necessário ler milhares de linhas de código em vinte arquivos diferentes.
4. Eles não parecem ser incomodados por e-mails, telefones tocando, pessoas conversando ao redor e outras pessoas fazendo perguntas.
5. Eles não querem usar o sistema de rastreamento de bugs que já temos desde que usamos o TFS. Eles preferem apenas lembrar de todas as tarefas que devem fazer.

Por que isso acontece? É uma habilidade específica que os desenvolvedores adquirem ao trabalhar com códigos mal escritos por um longo tempo? Minha relativa falta de experiência com código incorreto contribui para esses problemas / sentimentos? Tenho problemas com minha memória?

Sim, é normal que pessoas estruturadas sejam afetadas por ambientes / códigos não estruturados. Seus colegas provavelmente estão melhor filtrando todo o ruído de fundo. Como sofredor de enxaqueca, sei que minha capacidade de filtrar meu ambiente diminui bastante quando uma enxaqueca está chegando. As pessoas variam.

O mesmo vale para o código. Seus colegas provavelmente aprenderam a filtrar o "ruído do código" proveniente de vários níveis de abstração em um único método e tornaram-se hábeis em "dividir" o código em áreas de funcionalidade maiores.

Simplesmente leva tempo para se adaptar a uma base de código como a que você descreve. Seus colegas provavelmente tiveram muito mais tempo para se aprofundar no assunto e possivelmente aprenderam sobre convenções, padrões e construções que não surgem nos "iniciantes em base de código". Pode haver mais estrutura para o caos do que você pode imaginar. Converse com seus colegas, peça-lhes para emparelharem com você por algum tempo e compreendam como eles abordam a solução de um dos erros atribuídos a você. Quando eles solicitarem que você abra a unidade X, Y ou Z, pergunte a eles por que esse, o que está dizendo a eles que pode ser relevante etc.

Perder-se em um método de mil linhas é normal. Ataque-o com um bom editor de dobragem e adicione comentários para dividir as várias partes em funções e / ou procedimentos sem realmente fazê-lo. Imprimir o material e usar um marca-texto antiquado também pode ajudar.

Refatorar sem a rede de segurança dos testes de unidade é dar um tiro no próprio pé. Não. Apenas não.

Ninguém está exigindo que você mantenha tudo na memória. Se seus colegas não quiserem ou precisarem de um sistema de erros, basta escrever a tarefa atribuída a você em sua própria lista de tarefas e escrever notas quando / depois de conversar com alguém sobre os detalhes de suas tarefas.

existem 3 pontos principais que eu vejo:

os pontos 1, 2 e 3 decorrem do fato de que seus colegas são mais experientes com a base de código, o que significa que eles conhecem suas peculiaridades. Isso significa que eles usam sua memória de longo prazo para o processo de depuração e podem lembrar que o doXYZ realmente faz UVW, mas nunca foi renomeado por razões históricas. no entanto, se eles demorarem alguns meses para codificá-lo, começarão a sentir sua dor.

para o ponto 4, resistir a interrupções, não deixe que negócios não urgentes o tirem da zona ; leva muito tempo para voltar após uma interrupção; configure o IM da empresa como ocupado, tente agendar em longos blocos (tardes inteiras) apenas de codificação

por 5 segundos, crie uma planilha de excel com os erros nos quais você está trabalhando atualmente como sua lista de tarefas pessoal (ou use os recursos de gerenciamento de tarefas no seu IDE), estou disposto a apostar que alguns de seus colegas estão fazendo o mesmo

Não parece problemas de memória para mim. Parece que seus hábitos / tendências de trabalho não são adequados para o que você está encontrando, e você está pensando demais em seus colegas e não em si mesmo.

1. Método de mil linhas - todo mundo vai se perder nisso, a menos que apenas trabalhe nele. Eles podem ser mais rápidos em buscá-lo ou recuperá-lo. Você não pode mudar isso, exceto através da experiência, e talvez nem mesmo então.

2. Refatorar a introdução de bugs, bem, isso é sempre um risco. Você pode tentar desenvolver um teste de unidade para cobrir o que está mudando antes de fazer isso, mas isso pode não ser permitido pela gerência (provavelmente não, ou isso já seria feito). E o teste de unidade não é mágico, eles ainda podem perder as coisas, você ainda pode introduzir bugs. Provavelmente, eles simplesmente não estão refatorando. Isso remonta a (1), eles provavelmente tentam se concentrar apenas no que precisa ser corrigido, o que significa que eles chegam ao ponto mais rapidamente, mas perdem o quadro geral e levam mais tempo para consertar a próxima coisa nessa bagunça de mil linhas.

3. Crie o que você precisa para fazer o trabalho. Se isso significa criar um fluxograma ou alguma outra documentação, faça-o. Se eles precisam ou não, e se eles o usam ou não depois que você o criou, é irrelevante.

4. As interrupções atrasam a todos. Focar nisso apenas o deixará mais lento. Aceite-o e tente voltar ao ritmo o mais rápido possível.

5. Manter dois ou três erros em mente não é ruim, três ou quatro seriam melhores, mas em vez de tentar melhorar isso, desista e anote. Pedaço de papel, quadro branco, tfs, excel, word ou bloco de notas - basta anotá-lo. Aposto que é isso que seus colegas estão fazendo. Ou isso ou consertar as coisas aleatoriamente.

Programar não é sobre uma memória perfeita e não pode ser capaz de ignorar distrações - focar nisso são apenas distrações que você está criando.

CAVEAT / UPDATE: Depois de ler a resposta abaixo, senti que poderia ser um pouco dura demais. Não é minha intenção, o ambiente que você descreve é ​​terrível e afetaria a maioria das pessoas (provavelmente até os melhores programadores sofrem, mas são "melhores" quando comparados com outros no mesmo ambiente). Minha resposta é apenas uma reflexão ponto a ponto em suas perguntas, supondo que o ambiente não mude (mesmo que deva).

Resposta totalmente opinável:

1) Isso depende da experiência na tecnologia, na manutenção do aplicativo (mais se for mal projetado) e até em partes específicas do aplicativo. Também depende dos seus problemas de concentração (número 4)

2) É o mesmo que o número 1, mas usando uma métrica diferente. A mesma resposta.

3) bloco de notas e caneta. Ou um documento word / excel. Não é tão difícil de resolver.

4) essa é uma questão pessoal de concentração. Porém, não tenho certeza se é viável melhorá-lo.

5) usar um sistema de ticket ou não, não deve ser decidido pelos programadores, mas pelo gerente de projeto. Peça a opinião dele / apresente seus pontos. Se ele é contra, bloqueie e escreva novamente.

Eu já passei por uma situação assim antes e, com base nessa experiência, posso dizer que seu problema não está relacionado à memória e que há algo em sua mente (certamente não relacionado ao trabalho) que está deixando você estressado e impedindo que você se concentre. % na tarefa em questão.

Portanto, o primeiro passo é limpar sua mente quando estiver em sua mesa.

Esse estresse também pode aumentar porque você sente que está ficando para trás em termos de produtividade. Portanto, tente conversar com seus colegas de trabalho e peça dicas sobre como abordar a refatoração.

Finalmente, não se sinta envergonhado se você tiver que anotar os problemas que resolveu e / ou está trabalhando agora (não precisa ser um sofisticado sistema de rastreamento de bugs), é melhor ter certeza de algo, porque você o leu suas notas do que declará-lo em cima de sua cabeça, sem estar 100% certo disso