Critique - cómo Google reduce el dolor del code review con una satisfacción del 97% entre desarrolladores

xguru · 2023-12-11T10:32:02+09:00

Muchos ex-Googlers extrañan la herramienta de revisión de código de Google, "Critique" Según una encuesta interna de Google, el 97% de los desarrolladores está satisfecho con Critique Lineamientos de Google para revisión de código Recomendar la mejora continua por encima de la perfección Mantener o mejorar el estado de la base de código Seguir la guía de estilo Compartir conocimiento siempre: se fomenta compartir conocimientos sobre funciones del lenguaje, la base de código y otros artefactos relacionados a través de la revisión de código Hacer cambios pequeños (alrededor de 200 líneas) Criterios estrictos para que sea ágil (revisar los cambios de código dentro de 24 horas, idealmente con una sola persona revisora) Cortesía y profesionalismo: es importante mantener una cultura de confianza y respeto Critique: la herramienta de revisión de código de Google Permite a los ingenieros revisar y enviar cambios de código de forma eficiente Según el artículo reciente - Resolving code review comments with ML, están usando una herramienta integral de revisión de código basada en IA Cuando una persona revisora deja comentarios en el código, Critique muestra sugerencias de edición basadas en ML Quien escribió el code review puede corregir ese comentario de forma global con solo hacer clic en un botón Flujo de revisión de código Paso 1: escribir el cambio El CL (o Pull Request) se crea en Cider, el editor interno de código de Google Está estrechamente integrado con Critique y otras herramientas internas de Google para aumentar la productividad de los desarrolladores Herramienta Prereview: permite pulir los cambios antes de la revisión y muestra diferencias, resultados de build y pruebas, y validaciones de estilo Vista Diff y visualización: resaltado de sintaxis, referencias cruzadas, diff intralínea, ignorar espacios en blanco y detección de movimientos Muestra resultados de analizadores estáticos para resaltar hallazgos importantes y ofrecer sugerencias de corrección. Incluye "presubmits", pruebas automatizadas que se ejecutan dentro de Critique Paso 2: solicitar revisión Cuando el Pull Request está listo para revisión, quien escribió el código agrega revisores y lo envía formalmente para revisión Cuando el PR/CL se envía para revisión, se ejecutan los "Presubmits" si aún no se han ejecutado sobre el snapshot actual del código. Así, todas las personas involucradas en la revisión pueden saber si hay problemas en el código También se puede anonimizar la revisión de código para mantener en anonimato al autor frente a las personas revisoras. Sin embargo, Google no encontró diferencias útiles entre las revisiones anónimas y las revisiones de código "reales" Pasos 3 y 4: entender los cambios y comentar Cualquiera puede comentar los cambios, y hay funciones para seguir el progreso de la revisión y resolver comentarios Los comentarios no resueltos representan tareas que la persona autora del cambio definitivamente debe atender. Estos comentarios pueden marcarse como "resueltos" cuando la persona autora responde directamente al comentario Los comentarios resueltos incluyen observaciones opcionales o informativas que pueden no requerir acción por parte de quien escribió el cambio Hay un dashboard para ver el estado de la revisión y un "Attention Set" para saber quién está esperando actualmente en una revisión de código específica Paso 5: aprobar el cambio Como se mencionó antes, para que la revisión quede registrada, se necesita un LGTM (Looks Good To Me) de al menos una persona revisora Aunque la persona autora puede marcar comentarios como resueltos al responderlos directamente, la cantidad de comentarios no resueltos debe ser 0 Además, se requiere la aprobación de la persona propietaria de la parte de la base de código afectada y una aprobación de legibilidad Todo esto puede hacerlo una sola persona revisora Paso 6: hacer commit del cambio El cambio se envía y se hace commit desde el propio Critique Critique sigue siendo útil incluso después de enviar el cambio "Investigadores de Google encontraron evidencia sólida de que el uso de Critique va más allá de la revisión de código. Quienes escriben cambios usan Critique para revisar Diff y consultar resultados de herramientas de análisis. En algunos casos, la revisión de código forma parte del proceso de desarrollo del cambio, y las personas revisoras pueden enviar cambios incompletos para decidir cómo completar la implementación. Además, los desarrolladores usan Critique incluso después de que un cambio ha sido aprobado para revisar el historial de cambios enviados." Estadísticas más recientes de Google sobre revisión de código Frecuencia de creación de cambios: Mediana: 3 cambios por semana El 80% de las personas autoras hace menos de 7 cambios por semana Frecuencia de revisión: Mediana: revisar 4 cambios por semana El 80% de las personas revisoras procesa menos de 10 cambios por semana Tiempo dedicado a revisiones por semana: Promedio de 3.2 horas por semana Mediana de 2.6 horas por semana Tiempo de espera para la retroalimentación inicial: Cambios pequeños: menos de 1 hora en promedio Cambios muy grandes: alrededor de 5 horas Tiempo total del proceso de revisión: Latencia promedio para todos los tamaños de código: menos de 4 horas Comparación con otras empresas: AMD: 17.5 horas (mediana de tiempo hasta aprobación) Chrome OS: 15.7 horas Proyectos de Microsoft: 14.7 horas, 19.8 horas, 18.9 horas Microsoft (otro estudio): 24 horas ¿Por qué los Googlers aman Critique? Análisis estático: cuenta con un conjunto completo de herramientas de análisis estático que proporcionan automáticamente retroalimentación accionable sobre el código. Esto ahorra tiempo tanto a quien escribe el código como a quien lo revisa, y evita que la persona revisora tenga que señalar una por una las cosas obvias Enfoque solo en los archivos cambiados más recientemente: permite concentrarse únicamente en el último "snapshot" del código. No se muestran snapshots anteriores, commits ni cambios previos, por lo que la interfaz de usuario es más limpia Interfaz familiar de Diff lado a lado: por defecto muestra las "diferencias respecto a la última revisión" Sugerencias basadas en machine learning: la nueva función de sugerencias basadas en ML de Google acelera enormemente la revisión de código Integración estrecha con otras herramientas de Google: Critique está muy bien integrado con otras herramientas internas de Google, como su IDE y bug tracker, lo que mejora la productividad. Esto incluye vinculación sencilla entre código, comentarios y tickets Seguimiento del "conjunto de trabajo": permite saber quién debe hacer la siguiente acción Gamificación satisfactoria: aunque Critique no fue diseñado para ser gamificado, los Googlers comentan que era agradable cuando Critique "se ponía en verde" y el PR quedaba listo para enviarse (todas las pruebas pasando, aprobación LGTM de la persona revisora) Comentarios que se publicaron en Reddit Atajos de teclado increíbles para revisar grandes cantidades de código con muchísima eficiencia Por defecto muestra "lo que cambió desde la última revisión" Tiene una función de "detección de movimiento de código" que permite enfocarse en los cambios reales del código Ofrece una función excelente para indicar quién debe tomar acción, ya sea la persona revisora o la autora Si se usa junto con la extensión de Chrome, es fácil recibir notificaciones y revisar la cola de revisiones Internamente, cualquiera puede ejecutar consultas sobre los datos de revisión de código para recopilar insights Vinculación automática entre código y comentarios (incluyendo tickets y movimiento/enlaces) Permite ver en formato tabular el análisis, el historial y los comentarios del PR para entender mucho más fácilmente el progreso de PRs con varias rondas de código La terminología/etiquetas de los comentarios, como opcional o referencia, es muy consistente Reflexiones e implicaciones Muchas de estas funciones hoy también existen en otras herramientas, pero creo que la razón por la que esta herramienta es tan querida está en su integración estrecha y su grado extremo de "personalización" respecto al flujo de trabajo y la base de código propios de Google Al mismo tiempo, eso también significa que para cualquier empresa es prácticamente imposible replicar exactamente Critique y sus herramientas relacionadas. Por ejemplo, algunas herramientas están especializadas en problemas que surgen por una estructura monorepo Es probable que Critique en sí no se publique como open source, pero Gerrit es una herramienta similar a Critique. También es una herramienta open source de revisión de código creada y mantenida por Google Aun así, creo que Google pone mucho esfuerzo y reflexión en la productividad de los desarrolladores. Ellos publican libremente su propia investigación, y de su trabajo se pueden obtener implicaciones útiles

(engineercodex.substack.com)

52 puntos por xguru 2023-12-11 | 5 comentarios | Compartir por WhatsApp

Muchos ex-Googlers extrañan la herramienta de revisión de código de Google, "Critique"
Según una encuesta interna de Google, el 97% de los desarrolladores está satisfecho con Critique

Lineamientos de Google para revisión de código

Recomendar la mejora continua por encima de la perfección
Mantener o mejorar el estado de la base de código
Seguir la guía de estilo
Compartir conocimiento siempre: se fomenta compartir conocimientos sobre funciones del lenguaje, la base de código y otros artefactos relacionados a través de la revisión de código
Hacer cambios pequeños (alrededor de 200 líneas)
Criterios estrictos para que sea ágil (revisar los cambios de código dentro de 24 horas, idealmente con una sola persona revisora)
Cortesía y profesionalismo: es importante mantener una cultura de confianza y respeto

Critique: la herramienta de revisión de código de Google

Permite a los ingenieros revisar y enviar cambios de código de forma eficiente
Según el artículo reciente - Resolving code review comments with ML, están usando una herramienta integral de revisión de código basada en IA
- Cuando una persona revisora deja comentarios en el código, Critique muestra sugerencias de edición basadas en ML
- Quien escribió el code review puede corregir ese comentario de forma global con solo hacer clic en un botón

Flujo de revisión de código

Paso 1: escribir el cambio
- El CL (o Pull Request) se crea en Cider, el editor interno de código de Google
- Está estrechamente integrado con Critique y otras herramientas internas de Google para aumentar la productividad de los desarrolladores
- Herramienta Prereview: permite pulir los cambios antes de la revisión y muestra diferencias, resultados de build y pruebas, y validaciones de estilo
- Vista Diff y visualización: resaltado de sintaxis, referencias cruzadas, diff intralínea, ignorar espacios en blanco y detección de movimientos
- Muestra resultados de analizadores estáticos para resaltar hallazgos importantes y ofrecer sugerencias de corrección. Incluye "presubmits", pruebas automatizadas que se ejecutan dentro de Critique
Paso 2: solicitar revisión
- Cuando el Pull Request está listo para revisión, quien escribió el código agrega revisores y lo envía formalmente para revisión
- Cuando el PR/CL se envía para revisión, se ejecutan los "Presubmits" si aún no se han ejecutado sobre el snapshot actual del código. Así, todas las personas involucradas en la revisión pueden saber si hay problemas en el código
- También se puede anonimizar la revisión de código para mantener en anonimato al autor frente a las personas revisoras. Sin embargo, Google no encontró diferencias útiles entre las revisiones anónimas y las revisiones de código "reales"
Pasos 3 y 4: entender los cambios y comentar
- Cualquiera puede comentar los cambios, y hay funciones para seguir el progreso de la revisión y resolver comentarios
- Los comentarios no resueltos representan tareas que la persona autora del cambio definitivamente debe atender. Estos comentarios pueden marcarse como "resueltos" cuando la persona autora responde directamente al comentario
- Los comentarios resueltos incluyen observaciones opcionales o informativas que pueden no requerir acción por parte de quien escribió el cambio
- Hay un dashboard para ver el estado de la revisión y un "Attention Set" para saber quién está esperando actualmente en una revisión de código específica
Paso 5: aprobar el cambio
- Como se mencionó antes, para que la revisión quede registrada, se necesita un LGTM (Looks Good To Me) de al menos una persona revisora
- Aunque la persona autora puede marcar comentarios como resueltos al responderlos directamente, la cantidad de comentarios no resueltos debe ser 0
- Además, se requiere la aprobación de la persona propietaria de la parte de la base de código afectada y una aprobación de legibilidad
- Todo esto puede hacerlo una sola persona revisora
Paso 6: hacer commit del cambio
- El cambio se envía y se hace commit desde el propio Critique
- Critique sigue siendo útil incluso después de enviar el cambio
- "Investigadores de Google encontraron evidencia sólida de que el uso de Critique va más allá de la revisión de código. Quienes escriben cambios usan Critique para revisar Diff y consultar resultados de herramientas de análisis. En algunos casos, la revisión de código forma parte del proceso de desarrollo del cambio, y las personas revisoras pueden enviar cambios incompletos para decidir cómo completar la implementación. Además, los desarrolladores usan Critique incluso después de que un cambio ha sido aprobado para revisar el historial de cambios enviados."

Estadísticas más recientes de Google sobre revisión de código

Frecuencia de creación de cambios:
- Mediana: 3 cambios por semana
- El 80% de las personas autoras hace menos de 7 cambios por semana
Frecuencia de revisión:
- Mediana: revisar 4 cambios por semana
- El 80% de las personas revisoras procesa menos de 10 cambios por semana
Tiempo dedicado a revisiones por semana:
- Promedio de 3.2 horas por semana
- Mediana de 2.6 horas por semana
Tiempo de espera para la retroalimentación inicial:
- Cambios pequeños: menos de 1 hora en promedio
- Cambios muy grandes: alrededor de 5 horas
Tiempo total del proceso de revisión:
- Latencia promedio para todos los tamaños de código: menos de 4 horas
- Comparación con otras empresas:
  - AMD: 17.5 horas (mediana de tiempo hasta aprobación)
  - Chrome OS: 15.7 horas
  - Proyectos de Microsoft: 14.7 horas, 19.8 horas, 18.9 horas
  - Microsoft (otro estudio): 24 horas

¿Por qué los Googlers aman Critique?

Análisis estático: cuenta con un conjunto completo de herramientas de análisis estático que proporcionan automáticamente retroalimentación accionable sobre el código. Esto ahorra tiempo tanto a quien escribe el código como a quien lo revisa, y evita que la persona revisora tenga que señalar una por una las cosas obvias
Enfoque solo en los archivos cambiados más recientemente: permite concentrarse únicamente en el último "snapshot" del código. No se muestran snapshots anteriores, commits ni cambios previos, por lo que la interfaz de usuario es más limpia
Interfaz familiar de Diff lado a lado: por defecto muestra las "diferencias respecto a la última revisión"
Sugerencias basadas en machine learning: la nueva función de sugerencias basadas en ML de Google acelera enormemente la revisión de código
Integración estrecha con otras herramientas de Google: Critique está muy bien integrado con otras herramientas internas de Google, como su IDE y bug tracker, lo que mejora la productividad. Esto incluye vinculación sencilla entre código, comentarios y tickets
Seguimiento del "conjunto de trabajo": permite saber quién debe hacer la siguiente acción
Gamificación satisfactoria: aunque Critique no fue diseñado para ser gamificado, los Googlers comentan que era agradable cuando Critique "se ponía en verde" y el PR quedaba listo para enviarse (todas las pruebas pasando, aprobación LGTM de la persona revisora)
Comentarios que se publicaron en Reddit
- Atajos de teclado increíbles para revisar grandes cantidades de código con muchísima eficiencia
- Por defecto muestra "lo que cambió desde la última revisión"
- Tiene una función de "detección de movimiento de código" que permite enfocarse en los cambios reales del código
- Ofrece una función excelente para indicar quién debe tomar acción, ya sea la persona revisora o la autora
- Si se usa junto con la extensión de Chrome, es fácil recibir notificaciones y revisar la cola de revisiones
- Internamente, cualquiera puede ejecutar consultas sobre los datos de revisión de código para recopilar insights
- Vinculación automática entre código y comentarios (incluyendo tickets y movimiento/enlaces)
- Permite ver en formato tabular el análisis, el historial y los comentarios del PR para entender mucho más fácilmente el progreso de PRs con varias rondas de código
- La terminología/etiquetas de los comentarios, como opcional o referencia, es muy consistente

Reflexiones e implicaciones

Muchas de estas funciones hoy también existen en otras herramientas, pero creo que la razón por la que esta herramienta es tan querida está en su integración estrecha y su grado extremo de "personalización" respecto al flujo de trabajo y la base de código propios de Google
Al mismo tiempo, eso también significa que para cualquier empresa es prácticamente imposible replicar exactamente Critique y sus herramientas relacionadas. Por ejemplo, algunas herramientas están especializadas en problemas que surgen por una estructura monorepo
Es probable que Critique en sí no se publique como open source, pero Gerrit es una herramienta similar a Critique. También es una herramienta open source de revisión de código creada y mantenida por Google
Aun así, creo que Google pone mucho esfuerzo y reflexión en la productividad de los desarrolladores. Ellos publican libremente su propia investigación, y de su trabajo se pueden obtener implicaciones útiles

5 comentarios

xguru 2023-12-17

Parece que sí hay intentos de integrar ChatGPT en Gerrit
https://github.com/xielong/chatgpt-code-review-gerrit-plugin

kkweon 2023-12-12

Lo que más se siente es que en Critique se puede revisar una serie de CL consecutivos. En GitHub es incómodo que no haya soporte directo para encadenar PR. Por eso termina siendo un PR grande, o hay que esperar hasta que se haga merge del PR anterior.

tested 2023-12-11

GitHub también tiene algo parecido; queda ver cuándo lo abrirán.
> https://githubnext.com/projects/copilot-for-pull-requests

winterjung 2023-12-11

No hay análisis estático ni sugerencias basadas en ML, pero al leer el artículo se parece bastante a la función de revisión de GitHub. Como alguien que usa mucho las revisiones de GitHub, ojalá también incorporen más de las otras funciones que ofrece Critique.

xguru 2023-12-11

Guía de revisión de código de Google [traducción al coreano]