En nuestro lugar de trabajo, utilizamos el método Agile Scrum. Sin embargo, en realidad no lo seguimos religiosamente.
Pero, hacemos revisiones de código muy exhaustivas. El problema con las revisiones de código es que toma un tiempo documentar los problemas con el código y enviarlo de vuelta al desarrollador. Supongo que quieren que las revisiones de código estén documentadas porque podría ser bueno para fines de auditoría y también prueba que los revisores de código realmente están haciendo su trabajo correctamente.
Pero parece tomar mucho tiempo del día en que analizamos el código de alguien y documentamos los errores. Hubiera sido mejor pasar el tiempo haciendo nuevos desarrollos/investigación/soporte/mantenimiento.
¿Cómo podemos acelerar las revisiones de código sin sacrificar la minuciosidad de las revisiones de código?
Un par de sugerencias:
Vale la pena pensar en usar herramientas de calidad de código automatizadas como Findbugs , PMD y Checkstyle .
Idealmente, haga que el equipo acuerde un conjunto de estándares de codificación e impleméntelos como plantillas en las diversas herramientas de calidad de código. Luego, ejecute las herramientas desde la integración continua y posiblemente incluso falle en las compilaciones cuando no se cumplan los estándares de calidad.
Esto no reemplazará las revisiones de código, pero se espera que reduzca las discusiones en las revisiones de código relacionadas con el estilo de codificación, el formato, etc.
El simple hecho de tener estándares claros ayudará a reducir el tiempo dedicado a las revisiones de código.
Existen algunas buenas herramientas de revisión de código.
Un ejemplo es Crisol .
Este tipo de herramientas son excelentes para ayudar con la facilitación de las revisiones de código y también ayudan mucho con las revisiones de código que se ejecutan de forma remota (por ejemplo, cuando un miembro del equipo trabaja desde casa).
¿Son los objetivos que la revisión puede ser auditada? o para probar que el auditor está haciendo su trabajo? Los documentamos como nuevas tareas/descubrimientos en nuestro Scrum-board y algunos simplemente los recogen.
Creo que el objetivo principal de las revisiones de código es compartir conocimientos y encontrar errores de código recurrentes, no la documentación, a menos que lo necesite por ley :)
Revisiones de código basadas en listas de verificación : este libro electrónico tiene una excelente estrategia práctica y liviana para las revisiones de código entre pares. Para obtener un resumen de esta estrategia, lea mi respuesta a otra pregunta sobre SE.
Programación en pareja : algunos equipos piensan que la programación en pareja es una buena alternativa a las revisiones de código, ya que otra persona revisa el código durante el acto.
Hace unos años, mi equipo se encontraba en una gran crisis de tiempo/recursos. Resolvimos esta pregunta asignando a un senior (yo) para hacer las revisiones del código.
Utilicé Findbugs para limitar mi búsqueda e identificar errores obvios, pero no confiaba plenamente en él porque era propenso a informar falsos positivos. Por ejemplo, con frecuencia afirmaba que el registrador era una variable no utilizada cuando podía ver que el código registraba mucho.
Una vez que usé findbugs hasta este punto, revisé el código en cuestión manualmente en contexto para descartar falsos positivos y encontrar problemas que findbugs no puede encontrar (errores ortográficos y gramaticales).
Pasaría de 30 a 60 minutos preparándome para la revisión del código, luego 10 minutos en la reunión real. Los recursos totales gastados promediaron menos de 1 hora de programador. Nunca fallamos en encontrar y eliminar al menos tres errores en cualquier reunión.
Podría considerar el uso de elementos de Test Driven Development.
Es posible que las revisiones del código sean más rápidas y no menos exhaustivas al crear las pruebas antes del desarrollo, de modo que el desarrollador pueda analizar continuamente su progreso hasta que cumpla con los requisitos de la prueba preaprobada.
Esto ciertamente podría reducir la naturaleza de ida y vuelta de la revisión.
Deje de hacer revisiones de código y comience a programar en pareja. Si el propósito de las revisiones de código es mejorar la calidad del código y, al mismo tiempo, ayudar a los miembros del equipo a aumentar su conocimiento del dominio, entonces la programación en pares es una forma mucho más proactiva de revisión de código. También genera calidad antes en su proceso de desarrollo.
Acelerar = mejorar la eficiencia. Entonces, se pregunta cómo aumentamos la eficiencia sin sacrificar la eficacia. Una gran desventaja de las revisiones de código es que los miembros del equipo que realizan la revisión de código primero deben comprender el problema comercial y el código que están tratando de revisar. A menudo, esto se hace revisando de forma reactiva la historia del usuario y el código después de que todo esté "hecho".
Una forma práctica de obtener el mismo conocimiento es a través de la programación en pareja. Estás matando dos pájaros de un tiro; implementando la historia de usuario y haciendo un CR completo en paralelo. Está su aumento de eficiencia (y generalmente también es más efectivo ya que la mayoría de los adultos aprenden mejor a través de actividades prácticas en lugar de estudiar pasivamente por su cuenta).
HorusKol
Cort Amón
yegor256