La revisión de código puede ser mejor

• Muchos desarrolladores sienten una gran insatisfacción con la experiencia de revisión de código en GitHub, y se están probando nuevos enfoques para mejorarla
• Una herramienta experimental llamada git-review fue diseñada para manejar la revisión de código directamente en local junto con el código, en lugar de usar una interfaz web en el navegador
• La revisión se gestiona como un único commit, dejando comentarios de revisión como si fueran anotaciones dentro del código, y tanto el revisor como el autor van editando ese commit en conjunto
• Sin embargo, cuando el código se modifica o se hace rebase durante la revisión, surgen incomodidades con el manejo de conflictos y el uso de --force-with-lease, por lo que no logró un gran éxito
• Al final se volvió a la revisión basada en web, pero la idea de incluir directamente el estado de la revisión dentro del repositorio sigue siendo atractiva, y con futuras mejoras en Git, como la adopción de un Change-Id al estilo Gerrit, podría aparecer una alternativa mejor

---

Reconocimiento de los problemas en los sistemas de revisión de código

• Actualmente muchas personas están inconformes con el proceso de revisión de código de GitHub
• Los problemas principales incluyen la falta de soporte para pull requests apilados y revisión interdiff, además de que
  • el estado de la revisión no se guarda dentro del repositorio
  • la revisión depende obligatoriamente de una interfaz web remota y priorizada
• Los problemas que yo veo son la falta de descentralización de la revisión y la ineficiencia de la interfaz

Comparación del flujo de trabajo de escritura de código y revisión

• Cuando escriben código, las personas usan un editor en local
  • hay poca latencia de memoria y NVMe, y es un entorno optimizado para los flujos de trabajo particulares de cada usuario
• Para revisar código, también se prefiere trabajar haciendo pull local de la rama fuente
  • con herramientas como Magit es posible explorar no solo el diff, sino también todo el contexto del código
  • se puede aprovechar un entorno de desarrollo potente para ejecutar pruebas, saltar a definiciones o intentar refactorizaciones
• En cambio, para dejar feedback en un PR hay que ir al navegador y usar una interfaz web lenta, y en diffs grandes incluso hay bastante retraso al escribir

Interfaz ideal de revisión de código y estructura de almacenamiento

• En la práctica, lo más natural es dejar comentarios inline en el código o incluso modificar directamente el código

  // CR(matklad): Hm, this check seems imprecise to me.  
  // Shouldn't we compare `replica.view` instead of `header.view` here?  
  if (header.view != view) return;  
  

• Como los datos se almacenan en una base de datos remota y no en el repositorio local de git, también aparecen problemas de latencia y vendor lock-in

La idea de git-review y la experiencia real

• La idea de git-review es la siguiente:
  • la revisión de código se realiza en un único commit en la parte superior de la rama del PR
  • a ese commit se le agregan comentarios en el código con marcadores especiales
  • el revisor y el autor van editando ese commit por turnos, colaborando sobre la base de push --force-with-lease
  • cuando todos los comentarios quedan marcados como resueltos (//? resolved), se agrega un commit de revert al cerrar la revisión, para dejar el registro
• La idea es simple y práctica, pero en la realidad aparecieron varios problemas
  • cuando se modifica el código durante la revisión, los conflictos con los comentarios son frecuentes en commits inferiores o en commits nuevos
  • el proceso de force-push genera fricción en la colaboración y aumenta la complejidad del trabajo
  • se vuelve difícil manejar la desalineación entre el historial de cambios del código y el avance de la revisión, así como los conflictos de merge

Nuevos cambios y posibilidades futuras

• A futuro existe la posibilidad de que Git upstream adopte un Change-Id al estilo Gerrit
  • eso facilitaría el seguimiento del historial de cambios por commit y ampliaría el soporte para la revisión interdiff
  • pero se espera cierto choque con el enfoque de git-review
  • con una nueva estructura de Change-Id podrían ser posibles enfoques distintos, como agregar comentarios de revisión directamente al commit

Conclusión y presentación de sistemas de referencia

• Por ahora, al final se volvió de nuevo a la revisión de código basada en interfaz web
• La necesidad de una solución mejor sigue vigente
• Presentación de sistemas y herramientas relacionadas que vale la pena revisar
  • Fossil: sistema SCM que guarda toda la información dentro del repositorio
  • NoteDb: integra en git el historial de almacenamiento del estado de revisión de Gerrit
  • git-bug: guarda la información de issues en git
  • git-appraise: conserva la información de revisión dentro del propio git
  • prr: implementa una interfaz de revisión dentro del editor conectándose con la API de GitHub
  • How Jane Street Does Code Review: presenta un ejemplo de una realidad mejor
  • git-pr: proyecto que reemplaza todo el flujo de trabajo de PR con funciones nativas de git

Cierre

• Todavía no existe una solución perfecta, y continúan los intentos por lograr una mejor experiencia para desarrolladores
• Hay mucha expectativa sobre la dirección futura de esta evolución