Portanto, com base nos detalhes fornecidos pelo OP, parece que a pergunta é: "como aprendo meu próprio código para que, quando solicitado a encontrar X ou explicar Y, eu possa responder rapidamente".
Ao codificar, você precisa reservar um tempo para aprender e entender seu próprio código. Isso pode ser o que seu TL está tentando transmitir para você em poucas palavras. Sendo um TL no projeto atual, fiz várias revisões de código nos últimos 11 meses e noto a prática de alguns desenvolvedores de procurar por "código de exemplo" em nossa própria base de código ou em outro local (google , etc ...) e copie / cole. Pessoalmente, não aguento mais porque, enquanto o código deles passa nos testes simples de unidade, eles não entendem o que está realmente fazendo, por isso nunca garantimos que não exista ' • algum caso limite ou uma condição de falha esperada que poderia ocorrer.
Como corolário da declaração anterior, se você precisar copiar / colar, tente copiar / colar apenas o código que você escreveu anteriormente e que você entende. Certamente não há problema em "emprestar" a idéia de outras pessoas, mas, nesse caso, reescreva sua linha de código por linha porque, enquanto você a escreve, você terá uma melhor compreensão do que ela faz. Se você estiver usando APIs externas, mesmo se tiver um exemplo que use essa API, reserve alguns minutos para encontrar uma referência e aprender como ela funciona. Não pense apenas que, se funcionou antes, também funcionará na sua situação.
Leia e aprenda a amar o princípio DRY . Muitas vezes o que você é tentado a copiar / colar pode ser colocado em um local comum (função separada, classe separada, biblioteca separada ...)
Leia e aprenda a amar os princípios do SOLID e, enquanto faz isso, revise o KISS, que já foi mencionado pelo mouviciel. Esses princípios são todos orientados para a produção de código muito conciso, limpo e modular. Se você tiver grandes classes e grandes funções, será muito mais difícil encontrar coisas e, além disso, tentar explicar o que o código faz. Por outro lado, se você seguir (ou pelo menos tentar seguir) o SRP e tornar cada classe / função responsável por apenas uma coisa, seu código será pequeno e muito legível.
Pegue uma cópia do Clean Code . Livro muito bom. Ele fala sobre escrever códigos que são auto-explicativos e fáceis de ler, manter e estender. Se você pratica a escrita de código fácil de ler, não deve ter problemas ao ler seu próprio código nas revisões de código. E essa é a parte engraçada: eu pedi às pessoas que leiam seu próprio código ou simplesmente me digam o que as variáveis estavam representando e elas não puderam responder, mesmo que tenham escrito esse código (novas classes, não herdadas) há apenas uma semana. . Uma boa nomeação é um longo caminho.
Se, após toda a simplificação e refatoração, você ainda tiver uma função que precisa executar algum tipo de algoritmo que não é muito aparente, reserve um tempo e escreva um bloco de comentários nessa função que explica o algoritmo. Não só será útil quando você precisar modificar essa função daqui a dois meses, mas se você for emboscado em uma revisão de código, poderá ler simplesmente o que escreveu.
Se depois de todos os itens acima, você ainda estiver com problemas? você é novo na equipe e pediu para trabalhar com muito código herdado? Nesse caso, pode ser que o seu TL esteja sendo um A $$ e você possa ser proativo, solicitando a ele antes da reunião que seja fácil e não perca o tempo de todos os envolvidos. Quando novas pessoas ingressam em uma equipe, a TL precisa ter paciência suficiente, porque trabalhar em uma nova plataforma, novo produto, novas pessoas, novo ambiente exige muita concentração de uma nova pessoa, e essa pessoa estará perdendo alguns detalhes no começo. Funciona como projetado e seu TL deve aceitar isso.
Se, após todos os itens acima, você ainda sentir que tem análises de código horríveis. Fale com o seu TL. Às vezes, as pessoas se sentem mal por causa da natureza das reuniões de revisão de código, quando, na verdade, a TL está perfeitamente feliz com você. Quando faço revisões de código, meu objetivo é destacar o que precisa ser alterado, entender as mudanças e seguir em frente. Muitas vezes não tenho tempo para ser educado e algumas pessoas ficam na defensiva e tentam responder a cada um dos meus comentários. Nessas situações, a reunião de revisão de código é interrompida, por isso tento interrompê-los e seguir em frente. Geralmente, depois da reunião, eu conversava com os novos caras para garantir que eles entendessem o processo e que não fosse nada pessoal. Após poucas revisões de código, as pessoas geralmente ficam muito mais confortáveis.