Si su equipo realiza la revisión del código, ¿en qué medida verifica que se realicen las revisiones de revisión? [cerrado]

7

En mi equipo, realizamos revisiones de código (sin el uso de herramientas externas). El revisor produce una lista de elementos que el desarrollador debe abordar o considerar y, luego, dejarlos en su lugar (luego de analizar con ellos los puntos relevantes) sin dar seguimiento a sus cambios posteriores. Controles puntuales ocasionales sugieren que, en su mayor parte, se están abordando todos los comentarios.

Sin embargo, en una gran cantidad de literatura sobre el tema de las revisiones de códigos hay un fuerte énfasis en verificar que se aborden los comentarios de revisión de códigos. Me pregunto qué piensan las personas sobre esto. ¿Su equipo tiene (o tuvo) problemas con las personas que no abordan los comentarios? ¿Su equipo se comporta como el mío y no hace el paso de verificación? Si su equipo realiza el paso de verificación, ¿con qué frecuencia es solo un ejercicio de sello de goma?

    
pregunta Chris Knight 21.07.2011 - 11:15

8 respuestas

6

La clave del éxito (si existe) es hacerlo como le gusta al equipo. He estado en equipos donde nada se compromete con la revisión previa del código de VCS, seguido de otra revisión si había algo que arreglar. Esto se adaptó bien al equipo, ya que todos habían acordado hacerlo, se consideraba valioso y no demasiado riguroso.

En algunos otros equipos, esto definitivamente no hubiera funcionado. Por ejemplo, en otro equipo teníamos miembros de diferentes organizaciones, con diferentes habilidades. Incluso con un estilo de revisión mucho más ligero, tuvimos problemas con las personas que tienen miedo de hacer revisiones o de ser "revisadas". Obviamente, hay más de una explicación para este "fracaso", pero en mi opinión, la más importante es la falta de "aceptación": la gente tenía antecedentes y expectativas muy diferentes, tal vez falta de confianza, para poder utilizar de manera efectiva las revisiones de códigos. En estos equipos, las revisiones de código tal vez no fueron beneficiosas en absoluto.

El equipo debe decidir si las revisiones del código se realizan en absoluto, y si es así, cómo. Comience con algo en lo que todos los miembros del equipo puedan ponerse de acuerdo. Con el tiempo, los hábitos y gustos cambiarán. Entonces es hora de adaptarse de nuevo.

    
respondido por el merryprankster 21.07.2011 - 11:27
4

Nuestro proceso de revisión de código requiere una firma del revisor. Si no se realizan los cambios que recomiendan después de la discusión, no se cierran.

    
respondido por el temptar 21.07.2011 - 11:24
3

Es de esperar que su equipo esté formado por profesionales que puedan y harán el trabajo por el que se les paga. Hago un gran esfuerzo para no tratarlos como a niños al controlarlos y asegurarme de que están haciendo lo que se supone que deben hacer.

Las revisiones de código se realizan en nuestro escritorio y todos los involucrados toman notas para llevar a la reunión. La reunión no debería durar más de media hora. Alguien toma minutos y enviará un correo electrónico a todos los elementos de acción para esa reunión. Las sugerencias de revisión de código acordadas ahora son tareas en el plan de sprint.

Si estas tareas no se cumplen a esa velocidad, entonces el desarrollador debe explicar por qué. No es necesario en ese momento "verificarlo dos veces" para asegurarse de que hizo ese trabajo.

En mi humilde opinión, si necesita "verificar dos veces" que sus desarrolladores completaron las tareas, entonces su equipo tiene una deficiencia grave de habilidades, una deficiencia ética o ambas cosas y debería corregirse a un nivel superior.

    
respondido por el maple_shaft 21.07.2011 - 13:22
1

He visto ambas prácticas y, en general, refleja las demandas de calidad de las diferentes organizaciones.

En el entorno donde la calidad era esencial, se asignó una gravedad a los problemas planteados. El desarrollador senior a cargo de la revisión verificará los cambios realizados y aprobará el resultado (o recomendará otra revisión, si los cambios fueran demasiado complejos).

En otro entorno podríamos confiar en los desarrolladores. Los problemas que surgieron durante la revisión del código generalmente se formularon como consejos de todos modos, y con frecuencia era razonable ignorarlos. Cuando los plazos son ajustados, algunas mejoras simplemente no se pagan desde una perspectiva empresarial.

    
respondido por el MSalters 21.07.2011 - 11:50
1

Hacemos revisiones de código para el 100% de nuestro código.

Utilizamos Fisheye, que hemos vinculado a nuestro sistema de seguimiento de tickets, Jira

  • Los revisores se agregan a un ticket para que puedan revisar el código.
  • Ellos revisan y hacen comentarios en Fisheye
  • El desarrollador realiza los cambios manualmente como se indica, a veces después de una discusión en línea o en persona.
  • Se pueden realizar 'rondas' adicionales de revisiones dependiendo de los cambios realizados después de las revisiones.

Finalmente la revisión está cerrada. NO hay un "paso" específico para asegurarse de que se hayan aplicado los cambios. En cambio, confiamos en el hecho de que somos profesionales, somos artesanos, nos importa nuestro código. Prefiero este enfoque 'profesional' a las reglas de procedimiento rígidas que las personas temen romper. Si un revisor hizo una sugerencia y la ignoramos, por lo general saldrá a la luz en otro contexto.

Sin embargo, este enfoque implica:

  • profesionales que se respetan mutuamente
  • muy buena comunicación
  • acuerdo sobre normas

La comunicación realmente buena en realidad incluye muchos factores como:

  • diseño físico. los miembros del grupo que no están en el área principal es un problema frecuente
  • scrum y scrum de scrums (para pasar información con otros equipos)
  • retrospectivas: para asegurarse de que el proceso funcione para todos

Acuerdo sobre estándares significa:

  • ya sea una comprensión formal escrita u oral de las prácticas a utilizar
  • sistemas que se adaptan al cambio
  • los desarrolladores hablan sobre las diferencias y buscan un acuerdo
  • retrospectiva sobre retrospectivas: para observar nuestro propio proceso ágil.
respondido por el Michael Durrant 27.09.2014 - 13:27
0

En mi equipo hacemos revisiones de código de estilo de programación en pareja. Los arreglos a menudo se hacen sobre la marcha mientras se discuten las posibles mejoras que se pueden hacer. Descubrimos que la comunicación directa sucede para crear una especie de contrato entre el revisor y el revisor, de modo que es más probable que se realicen arreglos y que haya muchos menos problemas que si utilizáramos una herramienta o documento como un búfer entre los dos.

La única traza escrita que tenemos es que mencionamos el revisor en el control de origen cuando se realiza la confirmación, lo que facilita el seguimiento de las confirmaciones de código que se revisaron o no.

    
respondido por el guillaume31 21.07.2011 - 16:06
0

Las revisiones de código están integradas en nuestro SDLC.

  1. A un desarrollador se le asigna una Tarea.
  2. El código está marcado en el control de código fuente, asociado a esa tarea.
  3. Una vez que todo el código está listo, la tarea está marcada para revisión.
  4. Si la revisión falla, los desarrolladores corrigen el código en la misma tarea. GOTO 4.
  5. Si la Revisión pasa, el código se promueve al Entorno de Integración (Alpha).

Comprobamos el código en comparación con nuestros estándares de codificación y buscamos cualquier cosa que parezca que podría tener un impacto negativo en el rendimiento.

    
respondido por el Adrian J. Moreno 21.07.2011 - 18:23
0

Mis revisores de código vienen en diferentes sabores, pero en su mayoría me sellan con goma. Ciertos revisores de código parecen querer que el proceso termine lo más rápido posible, hasta el punto en que le pedí uno a mi líder de equipo y su respuesta fue "sí, está bien; simplemente escriba mi nombre", sin mirar el código. .

Hay un contratista que puede revisar mi código (actualmente trabajando en el mismo proyecto), y dará comentarios ocasionales pero nunca generará comentarios. Me da la impresión de que no le preocupa demasiado el código base, siempre y cuando el resultado parezca que funciona. Tuve que empezar a marcar los accesos directos que ha estado tomando, que no es una situación en la que quiero estar.

Los otros dos líderes de equipo son más completos: revisan cada archivo, me dicen que cambie las cosas, dan consejos y buenos comentarios. Todavía no se produce documentación, aparte de que sus nombres van en contra del compromiso.

Los inconvenientes de los revisores decentes son que las sesiones duran más tiempo y siento que el líder de mi equipo podría sentirse menospreciado si dejo de pedirle comentarios. Creo que las revisiones de nuestro código serían mejores sin la revisión del presente y hecho con el lujo del revisor.

El sistema de Adrian parece bueno, pero dudo que la administración lo haga por el tiempo extra que tomaría.

    
respondido por el Vhon Newmahn 27.09.2014 - 04:27

Lea otras preguntas en las etiquetas