Entonces, según los detalles que OP proporcionó, parece que la pregunta es "¿cómo aprendo mi propio código para que cuando se me pida encontrar X o explicar Y, pueda responder rápidamente?".
Al codificar, debe tomarse el tiempo para aprender y comprender su propio código. Esto podría ser lo que su TL intenta comunicarle en pocas palabras. Al ser un TL en el proyecto actual, he realizado muchas revisiones de código en los últimos 11 meses y noto la práctica de algunos desarrolladores de buscar "código de ejemplo" en nuestra propia base de código o en otro lugar (google , etc ...) y copiarlo / pegarlo. Personalmente, no lo soporto porque si bien su código pasa las pruebas unitarias simples, no entienden lo que realmente está haciendo, por lo que nunca se garantiza que no haya t algún caso límite o una condición de falla esperada que podría ocurrir.
Como corolario de la declaración anterior, si tiene que copiar / pegar, intente copiar / pegar solo el código que ha escrito previamente y que comprende. Ciertamente está bien "tomar prestada" la idea de otras personas, pero en ese caso, reescriba su código línea por línea porque a medida que lo escriba, obtendrá una mejor comprensión de lo que hace. Si está utilizando API externas, incluso si tiene un ejemplo que usa esa API, tómese unos minutos de todos modos para encontrar una referencia y aprender cómo funciona esa API. No asuma que si funcionó antes, también funcionará en su situación.
Lea y aprenda a amar el principio SECO . Muchas veces, lo que está tentado a copiar / pegar podría colocarse en una ubicación común (función separada, clase separada, biblioteca separada ...)
Lea y aprenda a amar los principios SÓLIDOS y, mientras lo hace, revise KISS, que ya mencionó Mouviciel. Todos estos principios están orientados a producir código muy conciso, limpio y modular. Si tiene clases grandes y funciones grandes dentro de ellas, claramente será mucho más difícil encontrar cosas y además tratar de explicar qué hace el código. Por otro lado, si sigue (o al menos intenta seguir) SRP y hace que cada clase / función sea responsable de una sola cosa, su código será pequeño y muy legible.
Recoge una copia de Clean Code . Muy buen libro. Habla de escribir código que se explica por sí mismo y es fácil de leer, mantener y ampliar. Si practica escribir código que sea fácil de leer, no debería tener problemas para leer su propio código en las revisiones de código. Y esta es la parte divertida, les pedí a las personas que leyeran su propio código o simplemente me dijeran qué representaban las variables y no pudieron responder a pesar de que escribieron ese código (clases nuevas, no heredadas) hace solo una semana . Los buenos nombres son muy útiles.
Si después de toda la simplificación y refactorización, todavía tiene una función que debe realizar algún tipo de algoritmo que no es muy aparente, tómese el tiempo y escriba un bloque de comentarios en esa función que explique el algoritmo. No solo será útil cuando tengas que modificar esa función dentro de 2 meses, sino que si te emboscan en una revisión de código, simplemente podrás volver a leer lo que escribiste.
Si después de todos los elementos anteriores, ¿todavía se encuentra en problemas? ¿Eres nuevo en el equipo y te pidieron que trabajes con mucho código heredado? En ese caso, podría ser que su TL sea un A $$ y usted podría ser proactivo preguntándole antes de la reunión que sea fácil y no pierda el tiempo de todos los involucrados. Cuando nuevas personas se unen a un equipo, TL debe tener suficiente paciencia porque trabajar en una nueva plataforma, un nuevo producto, nuevas personas, un nuevo entorno requiere mucha concentración de una nueva persona, y esa persona se perderá algunos detalles al principio. Funciona según lo diseñado y su TL debería aceptar eso.
Si después de todos los elementos anteriores, todavía siente que tiene revisiones horribles de códigos. Hable con su TL. A veces las personas se sienten mal por la naturaleza de las reuniones de revisión de código cuando, de hecho, TL está perfectamente feliz con usted. Cuando hago revisiones de código, mi objetivo es resaltar lo que se debe cambiar, asegurarme de que entiendes los cambios y seguir adelante. Muchas veces no tengo tiempo para ser cortés y algunas personas se ponen a la defensiva e intentan responder a cada uno de mis comentarios. En esas situaciones, la reunión de revisión de códigos se detiene por completo, por lo que tiendo a interrumpirlos y seguir adelante. En general, después de la reunión, hablaría con los nuevos muchachos para asegurarme de que entiendan el proceso y que no sea nada personal. Después de algunas revisiones de código, la gente generalmente se siente mucho más cómoda.