Algunos desarrolladores prefieren la revisión de código con "interdiff"

Por qué algunas personas prefieren la revisión de código con "interdiff"

Evaluación de la herramienta de revisión de código Gerrit

• Gerrit es una herramienta de revisión de código de código abierto que funciona junto con repositorios Git
• Se pueden escribir parches en el repositorio y enviarlos para revisión
• Otras personas revisan el código escrito y señalan problemas que deben corregirse
• La revisión de código suele ser una buena idea
• En proyectos de código abierto, el código puede fusionarse, lo que incrementa la responsabilidad y la deuda técnica

Diversas herramientas de revisión de código

• Existen varias herramientas, como Gerrit, GitHub, Phabricator, subir archivos .patch a un bug tracker y enviar correos mediante git send-email
• Cada herramienta puede funcionar en distintos grados

Serie de parches ideal

• Una serie de 3 parches representa la evolución de la base de código paso a paso
• Los cambios deben estar separados de forma lógica, y cada parche debe poder leerse como si se hubiera aplicado de manera individual
• La revisión de código permite revisar este tipo de serie ideal

Método de revisión de código de GitHub: "diff soup"

• GitHub originalmente fomenta hacer revisiones agregando nuevos commits encima de los commits originales
• Esto ocurre por el diseño de la UX y por varias otras razones
• Si durante el proceso de revisión se agregan varios commits, la relación implícita entre ellos se vuelve compleja
• Se dificulta el uso de las herramientas git blame y git bisect

Una mejor forma: revisión con "interdiff" (AKA git range-diff)

• En lugar de agregar nuevos commits, se publica una nueva versión de los commits originales
• Se usa git range-diff para comparar las diferencias entre versiones de commits
• El revisor puede hacer una revisión incremental sin tener que releer todo el diff
• Las herramientas git blame y git bisect funcionan de manera más confiable

Explicación intermedia: estrategia de fusión de parches

• El método anterior es independiente de la estrategia de fusión (por ejemplo, git rebase vs commits git merge con múltiples padres)

Explicación intermedia: si git rebase es malo o no

• git rebase está bien. Solo no debería usarse en ramas públicas sobre las que otras personas basarán sus commits

Otras notas

Conclusión

• El sistema de revisión interdiff fomenta parches más pequeños que se fusionan más rápido en la rama principal
• Ofrece una mejor experiencia de revisión de código tanto para revisores como para autores

Resumen de GN⁺

• Este artículo ofrece un análisis profundo sobre herramientas y metodologías de revisión de código
• El enfoque de revisión interdiff puede mejorar significativamente la eficiencia de la revisión de código
• Ayuda a resolver el problema de "diff soup" en GitHub
• Presenta factores importantes a considerar al elegir una herramienta de revisión de código
• Herramientas con funciones similares incluyen GitHub, Gerrit y Phabricator

[GN⁺]

Opiniones en Hacker News

• El flujo de trabajo que se usa principalmente en GitHub implica mucho trabajo y no es claro para los colaboradores

  • Permite que el revisor vea la diferencia que integra el feedback sin romper git blame ni git bisect
  • Al integrar feedback del revisor, se usa git commit --fixup <hash del commit a actualizar>
  • Cuando el PR es aprobado, se usa git rebase --interactive origin/main --autosquash para combinar los commits fixup con el commit original
  • Finalmente, se fusiona usando git push --force-with-lease
  • Se usa autocompletado para escribir comandos largos más fácilmente

• La forma de hacer code review en GitHub es ineficiente, y con Phabricator esto se manejaba manualmente

  • Sería mejor tener una UI explícita

• Quieren un sistema mejor que el code review de GitHub

  • Quieren fusionar rápido parches pequeños de corrección de bugs y acotar el alcance de la revisión
  • Se argumenta que deberían hacerse como revisiones/PR separados, pero eso genera problemas de dependencias entre patch sets

• Siempre es interesante ver nuevos enfoques de code review

  • Se consideró dividir los parches en PR dependientes separados
  • Herramientas como GitContext pueden mantener los PR pequeños sin perder las dependencias
  • Se puede usar IA para resumir PR y revisiones, y generar mensajes de commit precisos
  • El revisor solo puede ver los cambios desde la última revisión

• Review Board fue el primero en introducir interdiffs, y esto es muy útil en code review

  • Los commits fix-it no son una alternativa adecuada
    1. No permiten conocer los cambios ascendentes
    2. Vuelven más complejo el grafo de commits
    3. No todo el mundo usa Git
  • Los interdiffs permiten que el revisor siga todas las actualizaciones desde la primera solicitud de revisión
  • Son útiles al publicar varios commits como una sola solicitud de revisión

• Hay experiencia usando el sistema de code review Gerrit, y el code review de GitHub es ineficiente

  • Gerrit permite apilar varios parches, lo que facilita revisar parches pequeños
  • La interfaz de GitHub se parece a un hilo de foro y no permite seguir los rebase

• Hay experiencia usando varios sistemas de code review, y cada uno tiene ventajas y desventajas

  • Critique está optimizado para el monorepo de Google y su VCS personalizado
  • Gerrit es bueno para los revisores, pero incómodo para los autores
  • GitHub es amigable para los autores, pero ineficiente para revisores y equipos
  • Es importante usar mejores herramientas de code review

• Después de usar el sistema de code review Gerrit, los PR en stack de GitHub resultan incómodos

  • GitHub no muestra bien los cambios en los comentarios de code review
  • Se usan algunos scripts para facilitar el trabajo con PR en stack
  • Herramientas como ejoffe/spr y spacedentist/spr son útiles