Beneficios y desafíos de las revisiones entre pares en el desarrollo de software

Una revisión de pares, también conocida como revisión de código o inspección, es una revisión técnica y lógica exhaustiva de un módulo de código (programa, subrutina, objeto, método, etc.). Durante una revisión de pares, se inspecciona el código para identificar posibles mejoras y asegurar que se cumplan los requisitos del negocio. Si es necesario, se realiza una reunión para discutir cualquier problema que surja durante el proceso de revisión.

Cómo funciona una revisión de pares

Preparación
En primer lugar, el código que se va a revisar debe estar completo, probado por el programador y considerado listo para la siguiente etapa del ciclo de vida del desarrollo desde el punto de vista del programador. El código y otros componentes del proyecto afectados, como documentación, casos de prueba, programación de proyectos o cambios de requisitos, también deben estar disponibles para los participantes de la revisión. Los participantes deben revisar el código y otros materiales antes de la reunión y venir preparados para discutir sus problemas sin tener que leer el material nuevamente durante la reunión. Por supuesto, la fecha, hora y ubicación de la reunión deben establecerse con anticipación.

Revisión
Las revisiones se realizan según sea necesario, generalmente en función de la cantidad de código generado. La frecuencia de participación individual en una revisión de pares depende principalmente del tamaño del equipo de programación. Un equipo de tres programadores podría incluir a los tres en cada revisión. Los equipos más grandes podrían rotar la participación en función de la experiencia, el nivel de habilidad, el conocimiento del tema o factores específicos del sitio.

Si es posible, la revisión debería incluir al programador, dos revisores, un registrador y un líder. Sin embargo, incluso si solo otro programador puede revisar el código, debería hacerlo. Otras consideraciones para el tamaño del equipo de revisión podrían ser el alcance del proyecto, la carga de trabajo o las necesidades de capacitación.

Algunas preguntas que los revisores pueden plantear, y a las que el programador debe estar preparado para responder, incluyen:

• ¿Cómo satisface este módulo realmente el requisito comercial establecido?
• ¿No sería más adecuado utilizar una declaración de case en lugar de una estructura if-then-else anidada?
• ¿Cómo afecta la salida a la documentación de interfaz previamente establecida?

Todos los participantes deben tener mente abierta y estar dispuestos a discutir los problemas de manera directa. El programador debe reconocer que los cambios sugeridos no son ataques personales, y los revisores deben reconocer el orgullo del autor por su trabajo. El líder del equipo tiene la autoridad para decidir qué sugerencias se implementarán. El líder también utiliza la reunión para mantenerse involucrado y al tanto de lo que están haciendo los miembros del equipo. Se debe designar a alguien para documentar los procedimientos.

Cómo integrar XML y Active Server Pages (ASP) para crear una lista de contactos telefónicos

La reunión podría desarrollarse de la siguiente manera: el líder comienza con una breve discusión sobre el objetivo de la reunión y establece las reglas básicas. El programador explica su código, lo que se supone que debe lograr, qué requisitos contribuye y qué documentación afecta. Cada participante plantea preguntas, comentarios y sugerencias identificadas en la fase de preparación. El programador aborda esos problemas y explica la lógica, los problemas y las elecciones que llevaron a este código.

Seguimiento
El seguimiento proporciona evidencia del éxito de la reunión y un incentivo para el uso continuo de las revisiones. El valor de las revisiones futuras disminuirá si no se implementan las decisiones y, con el tiempo, los programadores verán el proceso como una pérdida de tiempo. El seguimiento es crítico para todos los participantes, especialmente para el programador. La documentación debe mantenerse en un lugar central donde cualquier persona pueda consultarla.

Los revisores también deben considerar la revisión como una experiencia de aprendizaje. Al ver qué tipo de problemas se plantean, pueden abordar esos problemas en su propio código. El líder del equipo siempre debe estar abierto a los comentarios de los participantes para identificar formas de mejorar las reuniones y la unidad del equipo.

Beneficios de las revisiones de pares

¿Qué beneficios se pueden esperar al utilizar el proceso de revisión de pares con tu código? Algunos de los beneficios incluyen:

• Una perspectiva diferente. "Otro par de ojos" agrega objetividad. Al igual que en el caso de separar los equipos de programación y pruebas, las revisiones de pares brindan la distancia necesaria para reconocer problemas.
• Capacidad para evaluar y acelerar el progreso. ¿El equipo está produciendo la salida necesaria a la velocidad necesaria?
• Orgullo/recompensa. El reconocimiento de la habilidad para programar es una recompensa importante para muchos programadores.
• Familiaridad con el proyecto/módulo. Todos los involucrados en la revisión se familiarizan más con el proyecto y el módulo.
• Menos retrabajos. Hacerlo bien desde el principio. Los cambios cuestan más tarde en el ciclo de vida. El proceso de revisión de pares detecta muchos errores antes de que lleguen a producción.
• Menos errores. Es mejor descubrir tus propios problemas que dejar que alguien (como un usuario) te los señale. Por la misma razón, es posible que encuentres que se eliminan muchos errores antes de que el código sea revisado por tus compañeros.
• Mejor comunicación. Más oportunidades de interacción tienden a llevar al equipo a una mejor comunicación.
• Unidad del equipo. Trabajar juntos ayuda a que los miembros del equipo se acerquen. También proporciona un breve respiro al aislamiento que suele traer la programación.

Desafíos de las revisiones de pares

No todo puede ser perfecto. Al implementar revisiones de pares, hay algunos problemas que deberás equilibrar, como:

• Tiempo. Algunas revisiones de pares llevan mucho tiempo. Pero al igual que otros tipos de reuniones, centrarse en el tema, estar familiarizado con el proceso y establecer reglas sólidas pueden ayudar a mantener el tiempo razonable (menos de una hora). Las revisiones de pares invierten tu tiempo; los errores lo desperdician.
• Preparación. Leer código desconocido y correlacionarlo con documentación desconocida distrae a los programadores de la codificación. Sin embargo, es un mal necesario. Con el tiempo, la preparación adecuada para la reunión debería llevar menos tiempo, ya que los revisores aprenden qué buscar y se familiarizan con el proceso.
• Frustración inicial. Si los miembros del equipo no están familiarizados con las revisiones de pares, la experiencia puede ser frustrante para todos los participantes. Los equipos deben idear un proceso para las revisiones de pares, implementarlo y modificarlo solo cuando la situación lo exija. Con el tiempo, los miembros se acostumbrarán al proceso.
• Necesidad de mostrar compromiso. Aunque las revisiones de pares aleatorias ofrecen ciertos beneficios, se cuestiona ese nivel de compromiso. Tu objetivo debería ser realizar una revisión de pares para cada módulo.

Cómo realizar mejores revisiones de pares

Al igual que cualquier habilidad, las buenas revisiones de pares se logran con la práctica. Algunos consejos que te ayudarán a empezar en el camino correcto son los siguientes:

Cómo evitar problemas con caracteres especiales en XML

• No conviertas la revisión en una batalla. El objetivo es crear un mejor software, no determinar quién tiene la razón.
• Establece las reglas básicas. ¿Qué comentarios de revisión deben ser abordados antes de avanzar en el ciclo de vida? ¿Cuáles son las razones válidas para no hacer una revisión? ¿Quién puede cancelar una revisión?
• Mantén profesionalismo. No tomes las críticas de manera personal y ofrece solo consejos técnicos que mejorarán el código. Respeta las opiniones, comentarios y sugerencias de los demás.
• Considera el alcance de la revisión. Determina el rango de tamaño o el alcance del código que se revisará. Si es demasiado grande, el proceso completo llevará demasiado tiempo; si es demasiado pequeño, habrá tantas revisiones que no quedará tiempo para programar. Además, define el tamaño y la composición de tu equipo de revisión normal, como se describe anteriormente.
• Documenta lo que sucede. Escribe todo, especialmente las decisiones y las tareas a realizar.
• Recibe capacitación en inspección de software. Tal vez tengas un experto interno en revisión de código, o quizás un miembro del equipo pueda leer un libro y luego capacitar al resto del equipo. Considera la opción de usar una universidad local o instituciones de capacitación empresarial para traer a un instructor al lugar.
• Comprométete con el proceso. Es posible que hayas intentado realizar una revisión y que no haya funcionado. Inténtalo nuevamente. Y otra vez. Comprométete con el proceso y cosecharás los beneficios.

Siguiendo adelante con las revisiones de pares

Las revisiones de pares pueden ser una parte divertida e interesante del proceso de desarrollo. Puede haber algunas desventajas, pero generalmente el resultado final es un código de mejor calidad, y un código de mejor calidad es bueno para todos. Además, es posible que descubras que como revisor o como el revisado, tus habilidades como desarrollador se mejorarán.

En Newsmatic nos especializamos en tecnología de vanguardia, contamos con los artículos mas novedosos sobre Desarrollo, allí encontraras muchos artículos similares a Beneficios y desafíos de las revisiones entre pares en el desarrollo de software , tenemos lo ultimo en tecnología 2023.