El propósito principal de la revisión de código es encontrar código que será difícil de mantener

Artículo original ↗ Discusión en Hacker News ↗

Propósito de la revisión de código: objetivos únicos vs múltiples

  • Muchos discrepan con plantear “encontrar código difícil de mantener” como el objetivo principal.
  • Se proponen como objetivos principales alternativos: transferencia de conocimiento, corrección/reducción de errores, comprobaciones de sanidad del diseño, seguridad, o simplemente “tener una conversación sobre el cambio”.
  • Varios argumentan que no existe un único propósito; la revisión de código es inherentemente multifuncional y depende del contexto (tamaño del equipo, nivel de confianza, dominio, regulación).

Mantenibilidad vs detección de errores

  • Algunos apoyan el encuadre de priorizar la mantenibilidad: si el código es claro y simple, los errores son más fáciles de detectar y las correcciones son más seguras.
  • Otros enfatizan que rutinariamente encuentran errores reales en la revisión (fallos de lógica, casos borde, problemas de seguridad y rendimiento) y ven esto como algo central, no incidental.
  • Varios comentarios rechazan la idea de que examinar código “no puede” encontrar errores, calificándolo como incorrecto en la práctica o como una afirmación teórica mal comunicada.

Intercambio de conocimiento y propiedad

  • Tema recurrente fuerte: la revisión de código como transferencia de conocimiento y propiedad compartida.
  • Leer PRs mantiene al equipo al tanto de los cambios del sistema, evita sorpresas y eleva el “bus factor”.
  • Algunos equipos incluso crean PRs puramente como artefacto de comunicación, aun cuando fusionan de inmediato.

Proceso, flujo de trabajo y cultura

  • Las opiniones divergen marcadamente según el flujo de trabajo:
    • Procesos estructurados centrados primero en el diseño vs “diseñar en el PR”.
    • Equipos pequeños y de alta confianza vs equipos grandes, de baja confianza o regulados.
    • Revisiones asíncronas estilo GitHub vs revisiones síncronas estilo reunión.
  • La revisión de código puede ser saludable (enseñanza, colaboración) o tóxica (control de acceso, batallas de estatus, aprobaciones performativas). Se considera crucial la cultura del equipo y la guía que se dé.

Pruebas vs revisión

  • Muchos subrayan que las pruebas, no la revisión, deben proporcionar las principales garantías de corrección.
  • Las buenas revisiones también comprueban la existencia y calidad de las pruebas o del plan de pruebas.
  • Algunos señalan que la revisión a veces detecta problemas de integración que las pruebas podrían no captar, especialmente donde la documentación y los límites del sistema son débiles.

IA y el panorama cambiante

  • Varios señalan que el código generado por IA y las revisiones asistidas por IA aumentan el volumen y el “slop”, haciendo más difícil una revisión humana cuidadosa.
  • Algunos prevén que las revisiones de PR se volverán insostenibles o se transformarán; otros insisten en que los humanos aún deben asegurar la comprensión y la mantenibilidad del código escrito por IA.