Cultura de revisión de código y buenas prácticas para PR

La revisión de código no consiste en poner barreras: es la forma en que los equipos aprenden juntos, transfieren la responsabilidad y mantienen un alto nivel de calidad. Una buena cultura de revisión fortalece a todo el equipo; una mala crea cuellos de botella y resentimiento.

1) Manténgala pequeña (menos de 400 líneas, si es posible). 2) Escriba una descripción clara: motivo, qué cambia y cómo probarlo. 3) Enlace el ticket. 4) Añada capturas de pantalla o vídeos para los cambios de UI. 5) Revise su propio diff antes de solicitar revisores.

Use los mismos prefijos convencionales que en los commits: feat: add user profile page, fix: handle 404 in fetch wrapper, refactor: extract Avatar component. Muchos equipos generan registros de cambios a partir de ellos.

La mayoría de los equipos usa una plantilla de PR; instálela en .github/pull_request_template.md.

Antes de solicitar revisores, recorra su propio diff línea por línea. Añada comentarios que expliquen las decisiones que no sean obvias. A menudo detectará sus propios errores antes de que otra persona tenga que hacerlo.

Una PR de 2000 líneas rara vez recibe una revisión exhaustiva. Divídala en: 1) refactorización (sin cambios de comportamiento), 2) comportamiento nuevo, 3) pulido de la UI. Cada parte será más fácil de revisar y revertir.

Formúlelos como preguntas, no como órdenes: «¿Qué le parece extraer esto a un hook?» es mejor que «extraiga esto». Diferencie lo que debe corregirse de lo que sería conveniente mejorar. Use prefijos: nit:, question:, blocker:.

«Esto es confuso» no le dice nada al autor. «Tuve que leer esto 3 veces para entender el retorno anticipado; ¿podríamos extraer una guard clause?» le da algo concreto sobre lo que actuar.

Comente positivamente las soluciones ingeniosas, los buenos nombres y las pruebas útiles. Esto fomenta esos patrones y suaviza el resto de los comentarios. Las PR que solo reciben críticas resultan hostiles.

Prettier se encarga del formato. ESLint se encarga del estilo. No desperdicie ciclos de revisión debatiendo entre tabuladores y espacios. Si una regla de estilo aparece una y otra vez, codifíquela en el linter.

Las pruebas también son código. Asegúrese de que el código nuevo tenga pruebas. Compruebe que realmente prueban lo correcto: muchas pruebas pasan aunque el código esté roto porque hacen aserciones sobre lo equivocado.

Responda a todos los comentarios, aunque solo sea con un emoji de pulgar arriba. Cuestione las sugerencias con las que no esté de acuerdo (usted escribió el código; puede tener contexto). Marque los hilos resueltos como resueltos. Actualice la descripción de la PR si cambia el alcance.

Revise en el plazo de un día laborable. Las PR obsoletas pierden contexto: el autor ha seguido adelante y la rama necesita un rebase. Las PR grandes que esperan una semana siempre se convierten en fusiones infernales.

La función de sugerencias de GitHub permite al autor aceptar una corrección con un solo clic. Es mucho más rápido que escribir «cambie esta línea por X» en prosa.

Apruebe cuando: el código sea correcto, las pruebas pasen, entienda el cambio y sea seguro fusionarlo. Aprobar significa que comparte la responsabilidad del resultado. No apruebe por inercia: si no lo ha leído, dígalo.

¿Cuál es la actitud recomendada al dar comentarios de revisión de código sobre algo que usted escribiría de otra manera?

Autor: PR pequeñas y bien descritas, con capturas de pantalla y pruebas. Revise primero su propia PR. Revisor: comentarios constructivos formulados como preguntas. Distinga entre blocker y nit. Elogie lo bueno. Omita el estilo: deje que las herramientas se encarguen. Revise en el plazo de un día. Apruebe solo cuando lo entienda. Las plantillas de PR estandarizan el proceso. Las revisiones son colaboración, no poner barreras.