Revisiones de código programado?

Question

En nuestro equipo, nos gusta hacer revisiones de código, pero debido a que la revisión de un código puede ocurrir en cualquier momento, es discordante cuando se está en la "zona" de programación y se aprovecha para realizar una revisión. Usted hace la revisión, que es genial, pero luego le toma diez minutos antes de entrar nuevamente en la "zona".

Estaba debatiendo sobre la mejor manera de manejar las necesidades de hacer revisiones de código, pero minimizando los efectos sobre la producción. Así que estaba entreteniendo la idea de tener algún tipo de horario: un tiempo donde los programadores se emparejan y hablan sobre el código del día, pero eso significa que tienes que esperar hasta el momento de la revisión para hacerlo. Así que todavía no estoy seguro al respecto.

Entonces, ¿cuál es la mejor manera de administrar las revisiones de código mientras se reducen las interrupciones?

Gracias!

Answer 1

Creo que la idea es involucrar a las personas temprano y con frecuencia. Las revisiones de códigos deben considerarse como una oportunidad de colaboración que, en última instancia, mejorará el diseño y la calidad del código. Si las revisiones de códigos son solo un elemento para marcar en una lista, o se ven como una interrupción para el progreso, entonces creo que el espíritu de la revisión se pierde.

Las mejores revisiones de código ocurren cuando la persona que escribe el código realmente las busca. Dicho esto, tendemos a tener una regla de que no se registra ningún código hasta que se haya revisado. De esa manera, es una especie de revisión programada. Sin embargo, si espera hasta el final, no obtiene el beneficio de una revisión del código que ayuda a influir en el diseño.

También podría ahorrarse el problema y programar algunos pares. Se obtiene la productividad y revisar todo al mismo tiempo;)

Answer 2

Puede hacerlo como una lista de verificación y dejar que los desarrolladores elijan su mejor momento. Pero debe haber una fecha límite real con consecuencias reales de lo contrario no se hará. También podría hacer que un día sea "día de revisión", como una "revisión del viernes" o algo en lo que alentará a que se realicen las revisiones ese día en particular.

Answer 3

Recomendaría hacerlas cuando el Programador haya terminado de agregar una unidad de funcionalidad, siempre que la estimación del tiempo para esa funcionalidad sea inferior a un día, esto funciona.

O mejor aún, realice el par de programación (que le proporciona una revisión del código prácticamente continua), pero aún tiene revisiones formales de código, con una frecuencia mucho menor.

Answer 4

día G,

Creo que este tipo de una revisión e improvisado sólo se debe utilizar cuando usted está teniendo problemas para entender algo de código.

Para aprovechar al máximo las revisiones de los códigos, se deben programar con anticipación para que las personas puedan ver independientemente el fragmento de código que se está revisando.

Es increíble lo fácil que se puede convencer a un revisor de que faltan errores cuando el autor está junto a ellos. Dado un poco de tiempo por sí mismos, la mayoría de los revisores son más propensos a detectar errores dentro del código.

Por lo tanto, en pocas palabras, programe las revisiones con anticipación y asegúrese de que los revisores tengan tiempo suficiente para revisar el código en su propio tiempo.

HTH

aplausos,

Answer 5

El equilibrio entre dar a las personas tiempo para prepararse para su revisión y minimizar las interrupciones es una pregunta difícil. La otra vez el intercambio, hacer la revisión mientras el código aún está "actualizado", complica eso más.

He visto un grupo de grupos comenzar en el futuro con las mejores intenciones, solo para que la práctica se marchite y muera porque, en la red, es demasiado perturbador.

Lo mejor que he visto para conseguir comentarios frescas con mínimas interrupciones al flujo es a su vez el tiempo de arranque hasta el final a la izquierda, y revisar el código, ya que está siendo escrita, mediante la programación en parejas, y por escribir pruebas como otra forma de revisión. (Con las pruebas, los revisores tienen que preocuparse menos por "¿funciona esto en absoluto?") Un par de ojos adicionales en el código mientras se escribe es una excelente manera de atrapar cosas que de otra manera tomarían más tiempo en revisión, y difunde el conocimiento mucho más rápido.

Aún puede optar por hacer revisiones grupales de código crítico, pero con menos revisiones, la posibilidad de tener personas preparadas para una especial va en aumento.

Esta es una práctica que demostrablemente no es para todos, pero los equipos con los que he trabajado que han hecho TDD y la programación de pares tienden a tener un código mucho más limpio con menos conteos de defectos.

Answer 6

Divulgación: Trabajo para Atlassian, que vende Crucible, una aplicación de revisión de código basada en la web.

Estoy de acuerdo que la programación en parejas es una práctica valiosa, y que ofrece algunos de los beneficios de la revisión de código (y por supuesto otros beneficios no relacionados con el código de revisar!)

se puede reducir la perturbación causada a los colaboradores mediante el uso de una herramienta de revisión de código, para que cada revisor realice la revisión en el momento que les resulte más conveniente. Esto también elimina el problema de que el autor hable con el revisor para que acepte el código.

Answer 7

Una forma en que podría verlo es "revisar los registros". En otras palabras, todos los días, alguien revisa todos los registros y luego, si hay algo marcable, va inmediatamente y habla y/o envía un correo electrónico al desarrollador en cuestión.

Hay comentarios inmediatos, la calidad se mejora porque el código se cambia y está fresco en la mente del desarrollador, por lo que aprende de él.

He encontrado que funciona muy bien. Una cosa que este enfoque no resuelve, sin embargo, es cuando un desarrollador verifica todo un cuerpo de código. Es difícil, con este enfoque, revisar múltiples archivos completos a la vez. Eso requiere otro enfoque, una versión eficiente de la cual, aún estoy buscando.