¿Qué aspecto tiene una revisión de código? [duplicar]

38

Estoy escribiendo un documento de proceso de revisión de código para nuestro equipo; Nunca hemos implementado un proceso formal, aunque sí hacemos una revisión del código.

He encontrado muchos artículos que hablan sobre la importancia de la revisión del código, pero tengo una pregunta en particular a la que no he encontrado la respuesta en la web ... ¿el programador es parte de la revisión del código? En otras palabras, ¿debería ser una revisión de código dos personas sentadas juntas, repasando lo que hay en el código, o debería ser una persona mirando el código de otra persona?

La mayoría de las veces, nuestros proyectos son realizados por un equipo de 2 personas, por lo tanto, antes de enviarlo a QA, ¿deberían esas 2 personas simplemente sentarse juntas y repasar todo el proyecto, incluido lo que cada uno de ellos ha escrito? O, ¿deberían ambos mirar el código del otro? Puedo ver ventajas para cada uno.

Finalmente, ¿qué sucede con los problemas encontrados durante la revisión del código? ¿Son anotados y luego enviados al programador? ¿O debería el revisor anotarlos y luego arreglarlos? ¿O está bien hacer un cambio y ni siquiera decirle al programador específicamente lo que encontró?

    
pregunta GendoIkari 03.01.2012 - 22:37

10 respuestas

40

Una revisión formal del código podría ser así:

  1. El programador envía material al revisor
  2. El revisor revisa el material
  3. El programador y el revisor se sientan y repasan el material. El programador toma notas. La discusión del diseño se pospone.
  4. El programador corrige lo que salió de la revisión.

El programador siempre debe hablar con los revisores, de lo contrario se perderá demasiada información.

Tenga en cuenta que, dado que solo son dos personas en el equipo, es probable que pueda salir adelante con algo muy informal, como el paso del código en la pantalla de los programadores.

También tenga en cuenta que la programación de pares es una excelente alternativa a la revisión.

    
respondido por el Christian Horsdal 03.01.2012 - 22:47
8

De lo que parece estar hablando es de lo que la gente llama "Programación de pares", sentados juntos y discutiendo su código para asegurarse de que esté libre de defectos. Esta es siempre una gran idea, y una que normalmente se recomienda. Sin embargo, no descarta la necesidad de una revisión formal. Las revisiones formales hacen que todos en su equipo se familiaricen con el código, ¡y más ojos siempre son una ventaja!

Una revisión formal siempre debe incluir al autor para que pueda hacer comentarios claros cuando sea necesario. Sin embargo, nunca deben ser el líder en la revisión. Esto les impide tener mucho control sobre el proceso y posiblemente omitir aspectos importantes de su código.

Muchas de las otras respuestas cubren cómo rastrear los defectos que se encuentran durante una revisión del código, por lo que no los volveré a enumerar aquí, pero siempre es importante tomar notas durante estas reuniones e informarlas a la autor. El autor casi siempre debe ser el responsable de implementar los cambios encontrados durante la inspección.

En mi escuela, mis profesores crearon un video de cómo debería ser una inspección de código y cuáles deberían ser las funciones principales. Todos lo encontramos bastante cursi, pero cubre algunos puntos buenos. Puedes verlo aquí: enlace

    
respondido por el Daniel Joseph 03.01.2012 - 23:07
4

En mi experiencia, hacer una revisión de código en una reunión física formal generalmente resulta en muy poca revisión de código, o en que las revisiones están por debajo de la media. Prefiero una herramienta como colaborador de código , gerrit , o las funciones integradas de revisión de algunos servidores de control de versiones como github o horno. Eso le permite informar a todas las personas que necesita o desea, y luego pueden revisarlas en su propio horario (reservo la última hora del día). Luego, el autor original hace, prueba y carga las correcciones, y quien haya encontrado el defecto se despide de la corrección. Esto le permite tener un enfoque más ágil e iterativo para hacer revisiones, en lugar de ser un gran evento al final.

    
respondido por el Karl Bielefeldt 03.01.2012 - 23:02
3

En la empresa para la que trabajo, el proceso es bastante simple: la persona responsable solicita el apoyo de un colega (de manera informal). El colega debe ser alguien que conozca la funcionalidad relevante (pero esto no es obligatorio).

Realizamos "revisiones de soluciones conceptuales" y revisiones de "implementación".

En la revisión de "implementación", el responsable explica el problema (si aún no se conoce) y la solución (si aún no se conoce) y luego revisa el código y la documentación interna. Esto sucede en la máquina del desarrollador (antes de que se confirme cualquier código). Durante esta fase, el revisor puede hacer cualquier sugerencia para mejorar el código o la documentación. También es común que el responsable solicite comentarios sobre problemas de implementación específicos (es decir, muestre dos implementaciones de la misma función y discuta cuál es la "mejor").

Idealmente, el responsable debería mostrar algunas pruebas que se realizan con el nuevo código (y el revisor también puede sugerir otros casos de prueba).

Este es un proceso simple, pero a menudo encuentra pequeños problemas.

A veces hay dos solicitudes de revisión / revisores (pero esto se debe a la organización de la compañía: el código está dividido por equipos especializados y, a veces, necesita cambiar el código de otra persona).

    
respondido por el MyNameIsZero 03.01.2012 - 23:02
3

Estoy de acuerdo con casi todo lo que dijo @Karl Bielefeldt, pero agregaré un punto que creo que es importante:

La revisión de código es (o debería ser) una programación de pares asíncrona.

La parte asíncrona obviamente solo es verdadera si el codificador y el revisor no están en la misma sala al mismo tiempo. Para mí, esto se habilita mejor con una herramienta como la solicitud de extracción de github. Ciertamente hay otras formas de automatizar el proceso, y he visto una variedad de ellas que funcionan en dominios desde dispositivos médicos a código abierto; sin embargo, lo que los separa es la gran variación en la eficiencia. No conozco a nadie que no esté preocupado por el tiempo comprometido en estos días; por lo tanto, creo que es mejor automatizar el proceso desde el principio.

La solicitud de extracción de Github obtiene mi voto porque los principiantes lo pueden descubrir y es fácilmente accesible a través de la interfaz web y, sin embargo, también maneja usuarios más avanzados que prefieren la línea de comandos.

La otra cosa que me gusta de este sistema es que hace un buen trabajo al separar los metadatos de revisión (comentarios sobre el código) del código en sí mismo y enfoca al revisor a proporcionar parches que aumentan la tasa de aceptación.

Si lo piensas bien, los aspectos económicos de la revisión del código son algo así como: la calidad derivada de la revisión es una función de la iteración: actitud y aptitud del revisor más la apertura y capacidad de respuesta del codificador. Cualquier cosa que pueda hacer para aumentar la facilidad y la velocidad a la que se realizan estas iteraciones de revisión da como resultado una mejor calidad y una experiencia más coherente para el equipo.

También vería ¿Cómo deben llevarse a cabo las revisiones de código?

    
respondido por el David Watson 04.01.2012 - 05:00
2

El proceso de revisión con el que estoy familiarizado es el siguiente:

  • El código fuente se administra mediante un sistema de control de versiones (por ejemplo, SVN).
  • Cualquier cambio en el software es seguido por un sistema de solicitud de cambio (por ejemplo, Bugzilla).
  • Cuando un desarrollador comprueba algunos cambios, estos se adjuntan a la solicitud de cambio.
  • Antes de que se pueda cerrar la solicitud de cambio, otro desarrollador debe revisar el cambio. Esto puede suceder directamente (un desarrollador explica los cambios al revisor) o a través de una herramienta (por ejemplo, enlace ) después de que se hayan verificado. -en ya En ambos casos, el revisor puede aprobar los cambios o sugerir modificaciones adicionales.

En ambos casos (revisión directa oa través de una herramienta), si el revisor aprueba los cambios, la solicitud de cambio se puede establecer en 'FIXED'. Si el revisor requiere más cambios, el desarrollador los implementa y se necesita una nueva revisión. Es el desarrollador original quien implementa estos cambios adicionales.

Para cambios más grandes (por ejemplo, la implementación de nuevas características), el desarrollador no explica el cambio hasta el más mínimo detalle: las ideas principales y las técnicas de implementación se ilustran en el código. Para cambios más pequeños (por ejemplo, corrección de errores), hay tiempo para tener una discusión más detallada.

    
respondido por el Giorgio 03.01.2012 - 22:48
2

La forma más sencilla de hacer una revisión de código es obtener una herramienta (usé codestriker ). Entonces el proceso es:

  • el programador elige el código para la revisión y los revisores
  • los revisores comentan el código
  • el programador revisa los comentarios y acepta lo que sea apropiado

De esta manera, los revisores pueden hacerlo cuando encuentran tiempo para ello. Y el programador no necesita tomar notas.

Una alternativa a la revisión de código es la programación en pares. Algunas personas lo llaman revisión de código con esteroides , pero es mucho más que eso.

    
respondido por el BЈовић 04.01.2012 - 07:53
1

El proceso básico debe involucrar al desarrollador sentado con sus compañeros y revisando su código con cierta profundidad. La profundidad depende del tamaño del proyecto, la importancia que tiene, etc. Los revisores deben tener acceso al código antes de la reunión para que puedan concentrarse en analizar los defectos en lugar de leer el código.

Cada reunión no debe ser demasiado larga, aproximadamente una hora, así que si hay mucho código, divídalo en partes más manejables. También es perfectamente aceptable simplemente revisar una parte del código, aunque, de nuevo, esto dependerá de la importancia del código, etc.

Puede ir a través del código en línea o fuera de línea, pero no se deben hacer cambios durante la reunión. Solo tenga en cuenta los defectos, ya sea como anotaciones en la impresión o en un archivo separado.

Luego, el desarrollador regresa y corrige los defectos, vuelve a ejecutar las pruebas, etc., según sea necesario. Dependiendo de la cantidad y la gravedad de los defectos, puede haber otra revisión, aunque esto podría ser solo una muestra del código.

    
respondido por el ChrisF 03.01.2012 - 22:48
1

Básicamente estás haciendo dos preguntas:

  1. ¿El autor del trabajo que se está inspeccionando debe formar parte de la revisión?
  2. ¿Debes hacer un seguimiento de los comentarios?

En mi experiencia, incluir al autor del trabajo es esencial .

  • El autor tendrá la oportunidad de participar en y aprender de Cualquier discusión que suceda.
  • Es probable que el autor sea el más adecuado para tratar cualquier defecto encontrado en el trabajo; si solo reciben una lista de elementos de acción sin estar presentes en la revisión, pierden el contexto de cualquier discusión.
  • Se puede pedir al autor que defienda la forma en que se escribió un artefacto.

En cuanto al seguimiento de los comentarios de la revisión: Sí , se debe realizar un seguimiento.

  • De los elementos encontrados, ¿cuáles son los problemas de capacitación?
  • ¿Cuáles son las mejores prácticas que deben seguirse para todos los trabajos futuros?
  • ¿Qué defectos fueron defectos porque el código es difícil de leer, está mal documentado, etc.?
  • ¿Qué defectos se refieren a problemas más grandes que requieren más trabajo que una respuesta a la inspección? ¿Se debería hacer un seguimiento de ellos, ya que se pueden trabajar los distintos tickets de error según lo permitan los recursos?

¿Tiene planes para lograr el cumplimiento de CMMI de cualquier tipo?

  • Querrá hacer un seguimiento de todos los defectos encontrados y el hecho de que cada uno se haya resuelto.

¿Su cliente o contrato requiere que se revise todo el código?

  • Querrá hacer un seguimiento de los problemas y los materiales de inspección para que pueda responder "SÍ" y demostrarlo si es necesario.
respondido por el jsf 05.01.2012 - 18:10
1

Mi vista en un proceso de revisión de código.

Primero, hay dos reglas básicas:

  1. nadie puede cometer código no revisado
  2. nadie puede revisar un cambio al que contribuyó

yo Cuando un colega está a punto de cometer un cambio, nos sentamos juntos y

  • compruebe que todos los casos de prueba estén en verde en su computadora
  • compruebe que ella escribió / modificó los casos de prueba
  • verifique que su código coincida con la pauta de codificación existente
  • compruebe sus cambios y se centre en los 25 principales de Jeff Atwood lista
  • revisamos sus cambios y lo discutimos

Esta es una revisión rápida, se puede hacer en 5 minutos. Es una buena manera de obtener una retroalimentación rápida, aprender sobre el nuevo cambio y nada se rompe

II. El desarrollador principal / líder del equipo debe elegir entre los compromisos diariamente y revisarlos a fondo y compartir sus pensamientos y conclusiones con el equipo (aquellos que implementarán los resultados que escribieron el código incorrecto)

III. durante la retrospectiva (si tiene alguna) revise el código de cada uno para aprender

Hice un blog sobre el tema aquí y here .

    
respondido por el Zsolt 04.01.2012 - 00:22

Lea otras preguntas en las etiquetas