Lección 50 — Revisión de código

Dar y recibir el feedback. Sin solutions.md hasta entregar.

Ejercicio 1 — El review con orden

1. Toma UN PR real del curso (o del histórico de git: el diff de una feature) y revísalo con el orden del §1: el QUÉ → contrato → seguridad → corrección → tests → estilo. Escribe los comentarios en orden y clasifícalos (bloqueante/debería/nit/pregunta).
2. El review invertido: revisa el MISMO PR empezando por el estilo: ¿cuántos comentarios de estilo salieron y cuántos hallazgos de impacto se te escaparon? Documenta la comparación (el ejercicio del espejo).
3. Los 5 ADNs: crea el checklist del revisor con las 5 preguntas del ADN de TicketFlow (capas, outbox, lock, handler, config) y aplícalo al PR: ¿alguna falló? ¿La había cazado el review "normal"?

Ejercicio 2 — Los comentarios que enseñan

1. Reescribe 5 comentarios tóxicos (o típicos) al formato adulto (hecho+impacto+camino):

"Esto es un N+1 horrible."                    → ...
"Nadie hace esto así."                        → ...
"¿Por qué no usaste X?"                       → ...
"Este test no prueba nada."                   → ...
"El código legacy era mejor."                 → ...

1. La pregunta como comentario: caza UN riesgo real en tu código (¿el lock? ¿el outbox? ¿la PII?) y escríbelo como PREGUNTA que el autor (tú en el futuro) descubriría solo: "¿qué pasa si dos requests tocan esto a la vez?" — y responde la pregunta tú mismo con el fix.
2. El nit marcado: en tu próximo PR (o en el histórico), clasifica tus observaciones ANTES de escribirlas: ¿cuántas eran nits disfrazadas de bloqueantes? La honestidad del marcado.

Ejercicio 3 — El desacuerdo con datos

1. El desacuerdo simulado: inventa el review "usa un repositorio para todos los modelos" (la 25 dice: no) y responde con datos/ADR: la respuesta del autor que mantiene la decisión con el contexto. Pégala.
2. La escalada sana: el revisor insiste. ¿Qué produce el desacuerdo (¿el ADR nuevo? ¿el benchmark del 36? ¿el prototype de 30 min?)? Escribe el plan de resolución del desacuerdo en 4 pasos.
3. El review del PR pequeño: parte UN PR grande tuyo (o simulado: 2000 líneas) en 3 PRs pequeños con sus descripciones: ¿qué cambia en la calidad de la revisión que recibirías?

Ejercicio 4 — El self-review

1. Ejecuta el self-review completo (checklist del §5) sobre tu último PR del curso: ¿cuántos ítems fallaron? Arregla los fallos y anota qué ítem fue el más frecuentemente roto (¿el self-review nunca hecho? ¿el alcance sin inside/outside?).
2. El diff con ojos de extraño: lee tu diff como el on-call del 47 lo leería en un incidente: ¿el QUÉ se entiende sin preguntar? ¿el nombre de los tests documenta el comportamiento? Reescribe lo que falló.
3. El equipo de 1: define tu "review virtual": la checklist del §5 + el linter del 41 + el ADR previo al merge. ¿Qué te falta para simular un segundo par de ojos (¿el review programado del 31: 24 h de espera antes del merge propio?)

Ejercicio 5 — La cultura del review

1. Escribe el docs/review.md del proyecto: la escala de comentarios, las checklist del §5, el orden del §1, y la regla de tiempos (review en <4 h laborables, re-review en <2 h). Una página.
2. El caso difícil: el revisor que pide reescribir TODO ("a mi manera") vs el PR que funciona. Escribe la respuesta del autor Y la del revisor ideal (¿cuál es la línea entre estándar del repo y gusto personal? — la respuesta: ¿está en el ADR o en el estilo del review?).
3. El cierre: tu regla personal de review en 3 líneas (la que sobrevive al enfado y al apuro) — la pegas en tu onboarding (48).

Entrega

Pega el review con orden y clasificación, los 5 comentarios reescritos, la respuesta al desacuerdo con datos y el docs/review.md. Después: Lección 51 — Entender el negocio.