Revisiones de código, ¿cuáles son las ventajas? [cerrado]

12

En mi equipo, no hacemos revisiones de códigos formales. Tendemos a pensar que es suficiente con la programación de pares y los pares rotativos a menudo.

¿Debemos considerar hacer revisiones de código formales? ¿Cuáles serían las ventajas?

    
pregunta Edgar Gonzalez 27.04.2011 - 08:02

9 respuestas

8

Hacemos revisiones de código un poco diferentes (tal vez).

Reunimos a todos los programadores (todos los viernes) y observamos lo que hemos hecho en un período de semanas. Luego, elegimos qué proyectos queremos revisar para que cada proyecto hecho / en progreso tenga al menos una o pocas personas. Luego, aproximadamente en una hora, observamos los cambios que se hicieron, buscamos errores, cómo funcionan otros proyectos, etc. Luego, discutimos, decimos los errores, cómo se debe hacer (no solucionamos errores, solo los señalamos) y spam el código con FIXME). En general, para nosotros (10 programadores) toma alrededor de 2 horas.

Los pros:

  • Todos los miembros saben lo que sucede en la empresa
  • Los errores se encuentran más rápido
  • Nos obliga a escribir código legible (código que se puede leer sin explicación o introducción)
  • Los métodos de optimización / trucos / programas productivos se difunden más rápido
  • El programador como especialista "evoluciona" más rápido
  • es divertido

Lo que tengo en contra de la programación de pares como se mencionó (seguro que es solo mi opinión personal) es que cuanto más trabajen juntos el equipo, más rápido se volverá.

Espero que traiga algo de reflexión. Buena suerte.

    
respondido por el JackLeo 27.04.2011 - 08:35
4

Es posible que desee leer este libro gratuito:

enlace

Claro, tienen un producto que promocionar, pero todavía hay mucha información útil.

También discuten cómo la programación de pares ofrece algunas de las mismas ventajas, por lo que si eres una programación de pares, es posible que no necesites revisar el código en absoluto.

    
respondido por el Joeri Sebrechts 27.04.2011 - 10:45
2

No tengo mucha experiencia en la revisión de su entorno. No hacemos mucha programación de pares aquí. Hacemos revisiones de código para difundir el conocimiento del software en el equipo, tenemos otro par de ojos para detectar errores y tenemos un punto formal para verificar si el software cumple con nuestras pautas de codificación. .

Los primeros 2 puntos están bastante bien cubiertos por la programación del par, el tercero depende mucho del par y podría mejorar con una revisión formal del código.

    
respondido por el refro 27.04.2011 - 08:13
1

Nunca he hecho programación de pares en la práctica (solo lo esperaba), así que no puedo comparar directamente las dos prácticas. Sin embargo, puedo contar mis experiencias con revisiones de códigos formales.

Solía dirigir revisiones de código formales en un proyecto anterior, en código heredado. El proyecto estaba en un completo desastre y la dirección acogió con agrado cualquier iniciativa con la esperanza de poner orden en el caos. En ese momento pensé que la revisión formal del código era una buena idea. Encontramos errores y vimos que la calidad del código recién escrito era significativamente mejor que la del código antiguo. Recopilé estadísticas, cuentas de errores, etc. para demostrar esto.

Hicimos una sesión por semana en promedio, con 3-5 personas. Cada sesión tomó aproximadamente 3-4 horas de tiempo por persona (incluida la preparación) y revisó 200-300 líneas de código (LOC) *. En este ritmo, durante un período de más de 6 meses, logramos revisar aproximadamente 5K LOC, de aproximadamente 50K.

En retrospectiva, creo que fue muy costoso. Con este ritmo, nos habría llevado 5 años revisar todo el código base legado. OTOH tener más de una sesión a la semana habría quitado recursos al desarrollo. Por supuesto, ese es el dilema típico con el código heredado. Pero incluso revisar formalmente todo el código recién escrito llevaría mucho tiempo, lo que ralentizaría significativamente el desarrollo.

Mi conclusión es que las revisiones de código formales se realizan mejor en el código recién escrito, centrado en las partes más críticas del código. El resto se maneja mejor de una manera más informal, posiblemente a través de la programación en pares. Sin embargo, esta es solo mi opinión actual, que puede cambiar. No pretendo ser un gurú de revisión de código ni nada.

* Este es el ritmo normal de las revisiones de códigos formales.

  

Las tasas de revisión de códigos típicas son aproximadamente 150 líneas de código por hora. La inspección y revisión de más de unos pocos cientos de líneas de código por hora para el software crítico (como el software incrustado crítico para la seguridad) también puede ser Rápido para encontrar errores.

Citado de Wikipedia (énfasis por mí).

    
respondido por el Péter Török 27.04.2011 - 09:43
1

La revisión subyacente del código de motivo existe porque los programadores aislados deben reunirse y analizar su código y verificar que cumple con su estándar.

No menciona ningún problema de calidad, por lo que parece que su equipo ya está haciendo suficientes revisiones de código a través de la programación en pares. Impresionante!

La programación de pares realizada correctamente hace que las revisiones de código formales sean superfluas. Pero inténtelo durante unas semanas y vea cómo funciona, pero sospecho que no notará ninguna mejora.

Tenga en cuenta que las revisiones de códigos son un proceso agotador y costoso y no algo que deba tomarse a la ligera. Básicamente, introduce un traspaso en su proyecto que es costoso y ralentiza todo . Es mucho mejor asegurarse de que el código sea correcto en primer lugar, en lugar de tratar de encontrar problemas más adelante.

    
respondido por el Martin Wickman 27.04.2011 - 10:10
1

¿Debes hacer revisiones de código formales?

Absolutamente

Solo como una rápida nota al margen, tengo muy poca experiencia con la programación emparejada, pero no creo que las revisiones entren en conflicto con estos métodos.

Yo introduciría dos formas de revisión de código:

Revisiones de código de pares

Incluso si la programación emparejada funciona para ti, nunca duele tener otro par de ojos en el código. Los beneficios de esto son:

  1. Obtiene un conjunto de nuevos ojos en el código, alguien que puede tener un conocimiento más íntimo de las áreas de la base de código que usted (y / o su pareja) pueden no estar tan familiarizados con. Esto puede exponer problemas que se produzcan.
  2. Hace que (el par) vuelva a validar su solución antes de enviarla. Como el revisor no sabe nada de lo que has escrito, debes explicarlo en su totalidad. Esto puede exponer casos perimetrales que no había pensado o una lógica no válida.

Las revisiones de código de pares (en mi mundo) se llevan a cabo antes de cada envío. Cómo esto se traslada en el mundo de la programación pareada, no estoy seguro.

Revisiones de código de grupo

Esto sucede con menos frecuencia que las revisiones de código de pares. Por lo general, retiraría a mi grupo (o una subsección de mi grupo) a una sala de reuniones para una revisión informal del código. Por lo general, elijo un código que fue escrito por una persona al azar en el equipo, preferiblemente un código escrito desde cero. El código refactorizado no expone problemas como el código nuevo.

Asegúrese de que todos sepan que estas revisiones no están destinadas a recordar y no se utilizan para reflejar el rendimiento. Son simplemente para garantizar que se sigan los estándares de codificación de su equipo y para ayudar a todos a ser mejores ingenieros y, por lo tanto, a ser más útiles para el equipo (y a un mayor crecimiento de la carrera, etc.) y asegurarse de que esto Es la verdadera intención de las críticas. Si alguien sospecha algo diferente, estos serán temidos y menos productivos.

Iría a través del código de manera un tanto informal, dejando que cualquier persona en la sala señale las diferentes soluciones que pueden tener o las fallas lógicas que encuentran. Se supone que esto es más una discusión grupal que un líder sentado allí que les dice a todos cómo deben codificar.

Descubrí que el empleo de estos dos métodos aumenta la velocidad a la que los ingenieros progresan y reduce considerablemente el número de errores :)

    
respondido por el Demian Brecht 27.04.2011 - 08:27
0

Tal vez. Revisiones de código toman tiempo. Solo valen la pena si el tiempo tomado por la revisión se guarda en otro punto del proceso. ¿Qué ahorro esperas de las revisiones de código? ¿Está experimentando dificultades que podrían evitarse con las revisiones de código?

    
respondido por el kevin cline 27.04.2011 - 09:32
0

Si está realizando la programación de pares, la necesidad de una revisión del código disminuye sustancialmente, pero sin duda se beneficiaría de una revisión por pares. Para que esto sea beneficioso, debe ser realizado por una persona mayor y más experimentada que los miembros de la pareja.

¿Cuáles son los beneficios? Bueno, sería mejor si consideras los riesgos de no hacerlo.

  • El par podría estar haciendo algo mal o tal vez hacerlo de una manera subóptima
  • Quizás no esté siguiendo los estándares de codificación o no esté documentando el código correctamente. Una revisión por pares es realmente buena para encontrar estos
  • Nadie más que el par entiende un fragmento de código en particular. Entonces, ¿qué sucede si ambos miembros de la pareja se han ido y el código está mal documentado? Otros perderán tiempo tratando de resolver las cosas. Tener una tercera persona que sepa lo que has hecho reduce el riesgo.

Me divierte que las personas hayan dicho que la revisión del código es una pérdida de tiempo. Sí, lleva tiempo. Tal vez no produzca ningún cambio en el código, pero eso no significa que se desperdicie. Es como decir que no necesita revisar su sistema de incendios regularmente porque es una pérdida de tiempo.

    
respondido por el DPD 27.04.2011 - 15:34
0

Para mí, la principal ventaja de las revisiones de código es que hace que las personas escriban mejor el código.

Saber que su código será leído y revisado lo hace más consciente de la legibilidad y la "corrección" de su código. Cuando sepa que el código va directamente al repositorio y nadie más lo leerá, a menos que lo solucione por defecto, lo que hace que las cosas se deslicen y no se vuelvan a factorizar los nombres de los campos cuando cambia su uso, dejando los métodos no utilizados por si acaso. ser factorizado de nuevo en etc. etc.

    
respondido por el James Anderson 18.02.2013 - 03:05

Lea otras preguntas en las etiquetas