Los ingenieros pasan más tiempo leyendo código que escribiéndolo. La mayoría de los planes de estudio invierten esa proporción — las habilidades del lado de salida dominan, las del lado de entrada se presumen. El resultado: ingenieros que pueden escribir código limpio greenfield pero se atascan en el momento en que se encuentran con un repo de 50.000 líneas que no escribieron. Este tema es el lado de entrada.

Por qué leer es más difícil

Escribir código que ya has pensado es mecánico. Leer código te obliga a reconstruir la intención de alguien bajo tres capas de ruido: comentarios desactualizados, capas defensivas para casos que terminaron siendo imposibles y formas elegidas por razones obsoletas hace tiempo. La habilidad es triaje bajo incertidumbre — decidir rápido qué es load-bearing y qué es escombro.

El método de las tres pasadas

Leer un único entry point de arriba a abajo es la forma lenta de entrar. En su lugar:

1. Pasada de mapa — lista cada entry point público (handlers HTTP, funciones exportadas, comandos CLI). Una línea cada uno. Ahora conoces la superficie.
2. Pasada de traza — elige un entry point importante para tu tarea. Recorre su call tree dos niveles hacia abajo, ignorando el resto. Escribe un párrafo sobre lo que hace.
3. Pasada de detalle — solo resuelve la pregunta con la que realmente viniste. Salta el resto; puedes volver cuando lo necesites.

El método escala desde una librería de 100 archivos hasta un monorepo de un millón de líneas porque cada pasada está acotada por la siguiente pregunta, no por el tamaño del codebase.

Git como herramienta de comprensión

git blame te dice la última línea tocada. git log -L 'function foo:' muestra cada commit que tocó una función. Usados juntos responden la pregunta que el código no puede responder por sí mismo: por qué se ve así esta línea.

• git log -S "string" — encuentra el commit que introdujo o eliminó un string. Oro para “¿cuándo apareció este mensaje de error?”.
• git log --follow path — historial a través de renombrados. Útil antes de que una función se moviera.
• git bisect — búsqueda binaria de la regresión. Hasta una herramienta de historiador se convierte en una herramienta forense en el momento en que aparece un bug.

El mensaje de commit suele ser la única nota de diseño sobreviviente. Lee historiales generosamente; la spec es el codebase, pero la rationale de diseño es el log.

Tests de caracterización como ayudas para leer

Un test de caracterización clava el comportamiento actual — afirma no “esto es correcto” sino “esto es lo que hace hoy”. Escribir uno te obliga a observar en lugar de teorizar: el test falla en el momento en que tu modelo mental discrepa con la máquina. Tres o cuatro tests de caracterización alrededor de una función peluda te enseñan más sobre ella en una hora que releerla un día.

Clavar → refactorizar → verificar que los pines siguen pasando: ese es el camino seguro a través de cualquier función en la que aún no confías.

Code review como oficio

Una review cumple dos propósitos — atrapar defectos y enseñar — y una buena review balancea ambos. La mecánica:

• Lee el diff dos veces, luego el código circundante, luego pregunta una sola cosa. La crítica prematura señala síntomas; la crítica considerada señala causas.
• Agrupa los comentarios por severidad: bloqueante (P0), debería-arreglarse (P1), sugerencia (P2), nit (nit). El autor lee la severidad antes del código; los comentarios sin etiqueta desperdician su tiempo.
• Combina elogio con crítica: una review que es solo negativa quema al autor. Decir “esta es una abstracción limpia” es señal, no halago — le dice al autor qué hacer más.

La checklist del revisor

Una checklist corta y repetible gana a una ad-hoc:

Modos de fallo comunes en reviews

• La review “LGTM”: una aprobación rápida sin leer. No atrapa nada, no señala nada. Peor que ninguna review — pretende ser un guardarraíl.
• La review bikeshed: 200 palabras sobre naming, cero sobre la nueva llamada de I/O que bloquea el event loop. Ruidosa en trivialidades, silenciosa en riesgo.
• La review architecture-from-the-trenches: while you're here, let's also redesign this module. El scope creep bajo la cobertura de la review bloquea al autor más de lo que ayuda.
• El comment drive-by: un “esto está mal” seco sin acción sugerida. El autor no puede arreglar ni rebatir; solo adivinar.

Cada modo de fallo se corrige con un hábito: propón, no solo describas. “Este bucle podría salir temprano en la línea 23 si x es null” gana a “este bucle es ineficiente”.

Trayectoria de práctica

1. Elige una función en un repo real, escribe un test de caracterización para ella y commitéalo. Vuelve a leer la función después de escribir el test; observa qué cambió en tu modelo.
2. Corre git blame sobre una línea confusa. Encuentra el commit. Lee el mensaje. Reevalúa si la línea aún tiene sentido hoy.
3. Audita tus últimas diez reviews de código: ¿cuántos comentarios fueron P0-P1 vs P2 o nit? Si la proporción es nit-pesada, estás quemando la atención del autor.
4. Revisa un pull request con el único objetivo de encontrar un defecto y un elogio genuino. Ambos deben ser específicos para contar.
5. Para una función de tu propio código, escribe el párrafo de la forma en que lo harías para código ajeno. Si no puedes, tu función no tiene una sola responsabilidad.

Cuándo es la herramienta correcta