¿Cuál es la forma más efectiva de realizar revisiones de código? [cerrado]

71

Nunca he encontrado la forma ideal de realizar revisiones de código y, sin embargo, a menudo mis clientes las requieren. Cada cliente parece hacerlo de una manera diferente y nunca me he sentido satisfecho con ninguno de ellos.

¿Cuál ha sido la manera más efectiva de realizar revisiones de código?

Por ejemplo:

  • ¿Se considera que una persona es el guardián de la calidad y revisa el código, o el equipo posee el estándar?
  • ¿Revisa el código como un ejercicio de equipo usando un proyector?
  • ¿Se hace en persona, por correo electrónico o utilizando una herramienta?
  • ¿Evita las revisiones y utiliza elementos como la programación en pares y la propiedad colectiva de códigos para garantizar la calidad del código?
pregunta Paddyslacker 07.09.2010 - 19:21

13 respuestas

30

En mi trabajo, tenemos una regla muy simple: los cambios deben ser revisados por al menos otro desarrollador antes de una fusión o un compromiso con el troncal . En nuestro caso, esto significa que la otra persona se sienta físicamente con usted en su computadora y pasa por la lista de cambios. Este no es un sistema perfecto, pero aún así ha mejorado notablemente la calidad del código.

Si sabe que su código será revisado, lo obligará a revisarlo primero. Muchos problemas se hacen evidentes entonces. Bajo nuestro sistema, tiene que explicarle lo que hizo al revisor, lo que nuevamente hace que note los problemas que pudo haber omitido antes. Además, si algo en su código no queda inmediatamente claro para el revisor, eso es una buena indicación de que se requiere un nombre mejor, un comentario o una refactorización. Y, por supuesto, el revisor puede encontrar problemas también. Además, además de observar el cambio, el revisor también puede detectar problemas en el código cercano.

Hay dos inconvenientes principales en este sistema. Cuando el cambio es trivial, tiene poco sentido revisarlo. Sin embargo, debemos respetar las reglas, para evitar la pendiente resbaladiza de declarar que los cambios son "triviales" cuando no lo son. Por otro lado, esta no es una buena manera de revisar cambios significativos en el sistema o la adición de nuevos componentes grandes.

Hemos intentado revisiones más formales antes, cuando un desarrollador enviaba un código de correo electrónico para ser revisado al resto del equipo, y luego todo el equipo se reunía y lo discutía. Esto tomó mucho tiempo de todos, y como resultado estas revisiones fueron pocas y distantes, y solo un pequeño porcentaje de la base del código se revisó. La "otra persona revisa los cambios antes de comprometerse" nos ha funcionado mucho mejor.

    
respondido por el Dima 26.10.2010 - 23:46
13

Me gustan las revisiones de código, aunque pueden ser una molestia. La razón por la que me gustan es que obtienen más información sobre el código y una perspectiva diferente. Creo que incluso con la programación de pares, el código debería ser revisado. Es bastante fácil para dos personas que trabajan en el mismo código cometer colectivamente el mismo error que un conjunto de ojos diferente no se puede perder.

Si se hace en grupo con un proyector, realmente debe revisarse individualmente antes de la reunión. De lo contrario, es solo una molesta pérdida de tiempo.

Solo he hecho revisiones de código por correo electrónico y en grupo. En general, no creo que deban hacerse en persona. Usted siente un poco más de presión para correr a través del código con alguien mirando por encima de su hombro. Creo que una herramienta diseñada para la revisión de código sería un buen activo, ya que puede ayudar con algunos de los aspectos mundanos y debería facilitar la identificación de los bits de código problemáticos que los que se envían por correo electrónico.

El problema de que una persona haga todas las revisiones de código es que puede ser un cuello de botella. Con estándares de codificación bien documentados y diseñados, no debería ser necesario. Dependiendo del entorno / calendario de publicación, puede ser una buena idea tener siempre a alguien como revisor de código en espera.

Creo que la propiedad del código es una buena idea, ya que esta persona puede hacer que su prioridad sea entender ese código y, potencialmente, desempeñar un papel de guardián.

    
respondido por el George Marian 07.09.2010 - 19:51
6

En SmartBear no solo creamos una herramienta de revisión de código , también lo usamos en el día a día. Es una parte esencial de nuestro proceso de desarrollo. Revisamos cada cambio que se registra.

Creo que es una mala idea tener un único revisor de código de gatekeeper por muchas razones. Esa persona se convierte en un cuello de botella y tiene que hacer demasiada revisión del código (solo para mantener el proyecto en movimiento) para que sea realmente efectiva (60-90 minutos a la vez es el límite de la efectividad). Las revisiones de código son una excelente manera de compartir ideas y conocimientos. No importa que tan grande sea tu superestrella, ellos pueden aprender de otros en el equipo. Además, hacer que todos realicen revisiones de códigos también crea un entorno de "propiedad colectiva de códigos", donde las personas sienten que son dueños de la calidad del código (no solo de QA o del controlador de acceso).

Tenemos un documento técnico gratuito en " Mejores prácticas para la revisión de código entre pares "que tiene 11 consejos para hacer que las revisiones de código sean efectivas. Gran parte de esto es el mismo contenido del libro que John mencionó de forma más detallada.

    
respondido por el Brandon DuRette 27.10.2010 - 18:08
3

No hay excusa. Practica la programación en parejas. Es la mejor revisión de código posible. Cualquier otro mecanismo resulta en juego de culpa. La programación en pareja induce el espíritu de equipo y la propiedad colectiva. Además, debate sus ideas con su pareja, falla rápidamente, toma medidas correctivas y solo el código codificado y revisado de la pareja se compromete con el Sistema de gestión de la configuración (CMS). ¡Feliz programación de pares!

    
respondido por el karthiks 06.07.2011 - 16:55
2

Si está trabajando en un proyecto en el que varias personas contribuirán a la base del código, es necesario establecer un estándar.

En este punto, en mi experiencia, es mejor designar a una persona como el "rey" de la revisión del código, si así lo desea y lo que él o ella dice que va. En este sentido, si un usuario no se adhiere a las normas, el rey se encargará de ello.

Como desarrollador, reviso mi propio código muchas veces para que sea legible, sensato y todo lo demás. Por lo general, usamos javadoc o similar en los idiomas con los que codificamos y usamos la etiqueta @author para asignar propiedad a funciones, clases, etc.

Si una función no es correcta, hablamos con el propietario, lo mismo con la clase, etc.

    
respondido por el Chris 07.09.2010 - 19:46
2

En mi empresa, a cada tarea se le asigna un probador para probar la tarea, y también un revisor de código para revisar el código.

Si su producto ya se lanzó y quiere asegurarse de que no está haciendo nada incorrecto (como una pérdida de identificador o una pérdida de memoria), las revisiones de códigos son una gran cosa. Creo que durante el desarrollo inicial antes de lanzar su producto, las revisiones de código pueden ser demasiado trabajo.

Si su equipo tiene todos los desarrolladores senior, la revisión por pares sigue siendo útil. Todos cometemos errores a veces. Si su equipo tiene algunos seniors y algunos juniors, entonces deje que los desarrolladores senior hagan las revisiones del código, pero que también tengan revisiones del código para el código del senior.

Una cosa importante acerca de la revisión del código es que puede detectar los errores que cometemos, pero no es un reemplazo para las pruebas.

    
respondido por el Brian R. Bondy 07.09.2010 - 20:18
2

Recomiendo usar revisiones de código si no está haciendo programación en pares.

No discutir los pros y los contras con el emparejamiento, pero es difícil cuestionar los efectos positivos de que su código sea revisado constantemente por (al menos) otra persona. El código incluso está escrito y diseñado por (al menos) dos programadores; difícilmente puede ser mejor que eso. Estoy diciendo "al menos" porque imo, deberías intentar cambiar los pares mucho para que todos tengan la oportunidad de trabajar con el código.

    
respondido por el Martin Wickman 26.10.2010 - 23:59
2

Una de las cosas que trato de hacer en las revisiones de código en las que participo es después de revisar el código yo mismo, hago un análisis estático del código, usando herramientas como Findbugs, PMD, JavaNCCP y otros, y observo cualquier problema en estos Las herramientas se encuentran dentro del código a revisar. En particular, quiero ver todo lo que tenga un nivel de complejidad inusualmente alto, pidiéndoles que expliquen por qué es necesario ese nivel de complejidad o por qué la vulnerabilidad sugerida no es importante.

YMMV

    
respondido por el mezmo 15.02.2011 - 16:34
2

Donde trabajo actualmente, producimos dispositivos de hardware y el software que se interconecta con ellos que se integran en la infraestructura crítica. En consecuencia, tenemos un enfoque muy alto en la calidad de lanzamiento. Utilizamos una variante de Fagan Inspection y tenemos un proceso de revisión formal. Tenemos la certificación ISO 9001, entre otras certificaciones.

La industria de infraestructura crítica está muy interesada en la confiabilidad y repetibilidad de la misma. :-)

    
respondido por el Paul Nathan 15.02.2011 - 18:54
2

En mi empresa tenemos revisiones de código obligatorias para programadores junior y revisiones voluntarias para personas mayores. No hay un revisor de códigos designado, las solicitudes de revisión se envían a todos los desarrolladores.

Este sistema funciona bien: las revisiones se realizan cuando el tiempo lo permite y los cambios pueden ser revisados por varios conjuntos de globos oculares.

La excelente y gratuita herramienta Review Board funciona realmente bien para nosotros, y ha demostrado ser una excelente manera de comunicar reseñas.

    
respondido por el GavinH 15.02.2011 - 23:53
1

En mi empresa, nunca realizamos revisiones de código formales antes de los registros, a menos que estemos modificando una producción altamente crítica y no tengamos el tiempo para realizar nuestro proceso de control de calidad estándar.

Lo que hacemos es que cada vez que creamos que una revisión de código sería útil, agregamos un comentario "// todo: revisión de código por Joe" al código modificado. Por lo general, seleccionamos Joe porque posee el código modificado, pero si este criterio de selección no se aplica (por lo general, sí lo hace), simplemente elegimos a alguien más al azar. Y, por supuesto, si Joe está disponible en ese momento, utilizamos el método antiguo de revisión por encima del hombro.

Como revisor, lo único que tienes que hacer es buscar periódicamente el código completo para "// todo: revisión del código por mí" , revisar los cambios y verificar el código nuevamente en sin el comentario "todo ..."

Si hay un problema, volvemos a los métodos de comunicación tradicionales (correo / chat / etc).

Este método nos proporciona las dos cualidades principales que estamos buscando en un sistema de revisión:

  • sobrecarga muy ligera
  • trazabilidad
respondido por el Brann 15.02.2011 - 11:57
1

Encontramos que la forma más efectiva de hacer revisiones de código es 1 a 1 utilizando github para mostrar las diferencias en la rama.

  • ¿Se considera que una persona es el guardián de la calidad y revisa el código, o el equipo posee el estándar?

    • Depende del tamaño del equipo: el equipo de 3 tendrá 1 senior que tenga el mejor conocimiento de buenas prácticas, mientras que un equipo de 12 puede tener 3 o 4 personas que cumplirán ese rol.
  • ¿Revisa el código como un ejercicio de equipo usando un proyector?

    • en persona. 1 en 1 para ser menos amenazante. A veces se realiza en la zona comunitaria aunque para difundir el conocimiento. Depende de la situación exacta, personas, horarios, etc.
  • ¿Se hace en persona, por correo electrónico o utilizando una herramienta?

    • en persona. Usamos git y github y tiene excelentes herramientas de revisión de códigos y comparación de diferencias para facilitar la revisión del código.
  • ¿Evita las revisiones y utiliza elementos como la programación en pares y la propiedad colectiva de códigos para garantizar la calidad del código?

    • Intentamos hacer ambas cosas según corresponda. Eso significa que cuando se encuentra atrapado en un problema particularmente espinoso, o cuando trabaja en una infraestructura central o cuando se prepara para irse de vacaciones o para abandonar la empresa, se puede hacer una asociación para compartir y transferir el conocimiento. La mayoría del código o código que tiene algo más que cambios estéticos también debe revisarse al final.

Al igual que con todos los elementos de codificación, la respuesta correcta debe tener en cuenta:

  • Tipo de empresa (por ejemplo, inicio vs. gran corporación)
  • Tamaño de la empresa
  • Número de desarrolladores
  • presupuesto
  • Marco de tiempo
  • carga de trabajo
  • Complejidad del código
  • Capacidad de los críticos
  • Disponibilidad de revisor (es)
respondido por el Michael Durrant 21.02.2013 - 03:33
0

He trabajado en muchas empresas y he visto muchos procesos. Mi equipo actual maneja esto de la mejor manera que he visto hasta ahora.

Usamos un proceso de desarrollo ágil y, como parte de eso, tenemos puertas que cada historia debe atravesar. Una de esas puertas es la revisión del código. La historia no se mueve hasta que se realiza la revisión del código.

Además, almacenamos nuestro código en github.com. Así que después de que un desarrollador termina su cambio, publican el enlace a los comités en la historia.

Luego etiquetamos a un desarrollador para que lo revise Github tiene un sistema de comentarios que permite que alguien comente directamente en la línea de código en cuestión. Github luego envía un correo electrónico a la distro, por lo que a veces tenemos más ojos de algunos de nuestros otros equipos.

Este proceso ha funcionado muy bien para nosotros. Utilizamos una herramienta de proceso ágil que facilita la publicación de los compromisos y facilita la comunicación.

Si un problema es particularmente pegajoso, nos sentaremos y lo discutiremos. Esto funciona porque es parte integral de nuestro proceso y todos tienen que ver cómo funciona el proceso. Podemos volver a mover los boletos en curso si la revisión del código da como resultado la necesidad de retrabajo y luego se puede revisar nuevamente después de que se realicen los cambios, o si el revisor puede observar en la historia que corregir los elementos es suficiente y no es necesario revisarlos nuevamente.

Si la prueba da una patada hacia atrás, se remonta hasta el progreso y también se revisan los cambios adicionales.

    
respondido por el Bill Leeper 21.02.2013 - 06:22

Lea otras preguntas en las etiquetas