¡Descubre GoogleTest, con certificación TÜV y la tecnología Agentic AI para pruebas de C/C++!
Obtenga los detalles »
Blog de Parasoft
Se ha demostrado que una buena técnica de revisión de código por pares aumenta la calidad del software. A continuación se ofrecen algunos consejos para evitar prácticas dañinas que podrían inutilizar las revisiones de su código.
Saltar a la sección
La revisión de código entre pares es una de esas prácticas que todos consideran valiosas, pero que casi nadie domina. No se debe a la falta de buenas intenciones, sino principalmente a malos hábitos acumulados a lo largo de años de ciclos de desarrollo basados en calendarios, políticas vagas y la tendencia humana general a evitar conversaciones incómodas sobre el código ajeno.
La buena noticia es que solucionar los problemas de la revisión por pares consiste principalmente en dejar de hacer las cosas mal.
Pruebas automatizadas—examen de la unidad, Pruebas de API, pruebas de rendimientoEl análisis estático y demás abarca lo medible y repetible.
La revisión por pares es donde el juicio humano entra en acción en lo que las herramientas no pueden: problemas de diseño, mantenibilidad, esa señal de alerta silenciosa que se activa cuando lees código y piensas "esto nos va a perjudicar más adelante". Eso solo ocurre cuando las revisiones son enfocadas, rigurosas y realmente se completan.
Los datos sobre la efectividad de la revisión por pares existen desde hace el tiempo suficiente como para comprar su propio whisky. Steve McConnell publicó estas cifras en Código completo allá por 1993. Nadie los ha contradicho de manera significativa desde entonces, lo que dice mucho sobre lo bien que la industria ha estado escuchando.
La tasa media de detección de defectos es de tan solo:
En contraste, la efectividad promedio de las inspecciones de diseño y código es del 55% y 60%, una estadística ciertamente impresionante. Por supuesto, sólo da resultado si lo que se hace en la revisión por pares es efectivo y eficiente.
A lo largo de los años, he sido testigo de los numerosos obstáculos que conducen a revisiones por pares ineficaces. ¡Evitar estos malos hábitos puede ser tan efectivo como adoptar otros nuevos y buenos! Elimine los malos hábitos a continuación para evitar revisiones de pares ineficaces.
A pesar del papel fundamental que desempeñan las revisiones de código entre pares en el desarrollo de software, solo resultan útiles si se realizan de forma eficaz y eficiente. Una revisión mal ejecutada puede suponer una pérdida de tiempo sin obtener comentarios útiles para mejorar el código. Para garantizar el éxito de tu revisión de código, aquí tienes ocho hábitos que debes evitar.
Para empezar, no debería revisar ni buscar nada que se pueda hacer mediante análisis estático. Esto podría incluir problemas de marca, problemas de estilo como la colocación de rizos {
no me hagas empezar;
},
o utilizando un algoritmo de cifrado específico. Si una herramienta puede encontrarlo por ti, déjala.
En la era de los másteres en derecho, esto cobra más relevancia que nunca. Si dedicas tiempo de revisión a algo que un modelo podría detectar en segundos, estás desperdiciando el recurso más valioso: el juicio humano.
Cómic creado con la ayuda de Claude que muestra el proceso de revisión por pares.
Tómate el tiempo necesario para analizar en profundidad el algoritmo, la seguridad y las características de rendimiento del código. Ese es el trabajo que vale la pena realizar, y además es más interesante participar en él.
Este es un problema clásico que afecta especialmente a las organizaciones centradas en el calendario. Es probable que si publicas según una fecha, también revises según una fecha. La lógica es la siguiente: "Aún no he terminado, pero ya hemos programado una revisión, así que al menos veamos lo que tenemos". Lo sabes tan bien como yo: no es la mejor manera de hacer una revisión efectiva, así que deja de hacerlo. Asegúrate de que el autor del código haya terminado, y si aún no está listo, pospón la revisión hasta que lo esté.
Las largas sesiones de revisión de código pueden resultar contraproducentes. Es importante establecer límites razonables en el alcance y la duración de cada revisión para mantener el enfoque y la productividad. Las revisiones largas y exhaustivas pueden provocar fatiga, menor atención a los detalles y un proceso de desarrollo más lento.
Si la revisión lleva demasiado tiempo, es necesario repensar algo. Demasiado en este caso podrían ser sesiones de revisión que duren más de una hora o sesiones que consuman demasiado del programa de desarrollo general. Si las revisiones tardan más de una hora, probablemente esté intentando revisar demasiadas cosas a la vez. O el autor no estaba listo para la revisión. Después de una hora de revisión, la efectividad potencial disminuye rápidamente, especialmente para los autores del código. Incluso si el comentario no fue inicialmente personal, después de una revisión innecesariamente larga, la crítica puede agravarse y resultar más dolorosa.
Una revisión por pares se centra en el código, no en las personas. Asegúrate de hablar del código y no del desarrollador. Una afirmación como "Este código no escalará tan bien como necesitamos" tiene menos probabilidades de ofender que "Lo escribiste mal". Por el contrario, cuando recibas críticas, sé comprensivo. Reconoce que el código de todos se puede mejorar y que puedes aprender de los datos que obtienes. Independientemente de tu punto de vista en la revisión, probablemente puedas ser más elegante y facilitar una revisión fluida, agradable y rápida. Piensa en la revisión como una excelente manera de conseguir un mentor gratuito. Todos queremos un mentor, pero rara vez consideramos el proceso de revisión como un proceso de mentoría. Valorar la mentoría puede ayudarte a evitar tomártelo como algo personal.
No es sólo una metáfora de los propósitos de Año Nuevo. Realmente creo firmemente que la mayoría de las prácticas de calidad del software deben tratarse como un ejercicio. Si intentas darte un atracón en el último momento, no serán efectivos. No puedes correr en una cinta la noche antes de un maratón, y no puedes hacer tu revisión por pares la noche antes de tu liberación.
Lo que sucede con las revisiones de última hora es que los problemas que se detectan entonces rara vez son los que realmente se pueden solucionar.
¿Errores de estilo simples? Probablemente tu herramienta de análisis estático ya los haya detectado.
¿Inconsistencias en la nomenclatura? Los sistemas LLM las detectan en segundos.
Lo que suele salir a la luz en la revisión por pares a última hora son las cosas que realmente no se pueden solucionar en un sprint: una mala elección del framework, una arquitectura de rendimiento que no es escalable, suposiciones de seguridad inherentes al diseño.
Esos no son errores que se solucionan de la noche a la mañana. Son decisiones que se pueden deshacer a un alto costo, si es que se pueden deshacer. Revisa con suficiente antelación para que puedas hacer algo con lo que encuentres. Encontrar un problema fundamental la noche anterior al lanzamiento no es una revisión exitosa; es solo una forma costosa de confirmar que esperaste demasiado.
La forma en que se realiza el seguimiento de una revisión puede afectar en gran medida el valor de la misma. Si encuentra elementos durante una revisión y no verifica que estén arreglados, probablemente esté perdiendo el tiempo. El mejor beneficio se encuentra en un proceso consistente que incluya la rendición de cuentas. Asegúrese de que todos sepan lo que se espera de ellos y haga un seguimiento para asegurarse de que se estén realizando las correcciones.
Presta atención a los patrones en los resultados de tus revisiones. Si un código fuente, un desarrollador o un momento específico del cronograma generan revisiones sin errores de forma constante, es una señal que merece ser investigada. No se trata de inventar problemas, sino de preguntar por qué.
He visto a desarrolladores revisar el código de sus compañeros en un acuerdo mutuo y ordenado: problemas registrados, problemas resueltos, nada sin terminar, todo finalizado con una eficiencia asombrosa. Increíblemente eficiente. Literalmente increíble.
Las reseñas vacías no son prueba de un código perfecto. A menudo son prueba de un proceso de revisión deficiente.
Si cada revisor no busca lo mismo, no tendrá idea de si sus reseñas son efectivas. El alcance de la revisión por pares debe basarse en una política inequívoca que esté claramente escrita y a la que se pueda hacer referencia. Tener una lista de verificación puede parecer restrictivo al principio, pero ayudará a mantener la revisión en marcha y cumplirá una doble función si se encuentra en una industria de cumplimiento como la automotriz o la médica, donde necesita demostrar que ha realizado una revisión efectiva.
Eliminar la ambigüedad requiere más disciplina que simplemente escribir la política, aunque ese es un gran primer paso. Lo ideal sería desarrollar un par de escenarios basados en su política y preguntar a diferentes personas cómo lo harían. No es raro encontrar empresas que aceptan un status quo en el que diferentes grupos hacen las cosas de manera diferente y ambos piensan que el otro grupo lo está haciendo mal, pero a ambos se les permite bajo una política ambigua. Puedes hacerlo mejor.
Haga que todos estén en la misma página. Mejorará su calidad, le proporcionará la coherencia necesaria para la evaluación y la mejora, y le protegerá si algo sale mal. Si se encuentra en un entorno de cumplimiento como ISO 26262 o FDA, tener criterios consistentes agilizará sus auditorías.
He presenciado evaluaciones entre pares en una amplia variedad de organizaciones y he visto dónde pueden ser increíblemente valiosas, así como una completa pérdida de tiempo. Y eso fue antes de que aparecieran los másteres en Derecho (LLM).
Los másteres jurídicos (LLM) se han incorporado al debate sobre la revisión de código, independientemente de que su organización tenga o no una política formal al respecto. Esto tiene dos caras.
Es importante conocer ambos modos de fallo.
Uno de los usos más prácticos de los LLM en la actualidad es como primera revisión antes de que un revisor humano revise el código. Piénsalo como el equivalente en revisión de código a leer tu propio correo electrónico en voz alta antes de enviarlo.
Pedirle a un experto en derecho lógico que revise tus diferencias (buscando errores lógicos, nombres poco claros, casos límite omitidos o lugares donde la intención no coincide con la implementación) permite detectar los problemas embarazosos antes de que hagan perder el tiempo a un colega.
Esto también ayuda con el hábito n.° 3 mencionado anteriormente. Si vas a una sesión de revisión de 45 minutos y el LLM ya ha señalado tres cosas que corregiste, la sesión con la persona será más corta y estará más enfocada. Eso beneficia a todos los presentes.
Dicho esto, sea específico en lo que pregunta. "Revisar mi código" es una solicitud poco clara.
"Revisa esta función para detectar posibles fallos en el manejo de errores e identifica cualquier elemento que parezca asumir entradas que no se ajustan a los parámetros normales" es mejor. Los modelos LLM responden al ámbito. Si se les permite, pueden divagar.
Los LLM son revisores seguros de sí mismos, lo cual es parte del problema. Producen comentarios que suenan autoritarios sobre código que fundamentalmente no comprenden, especialmente cuando el contexto es limitado, la base de código es extensa o la lógica depende de conocimientos del dominio que nunca se incluyeron en la consigna.
Trata sus comentarios como tratarías los de un becario inteligente en su primer día: útiles para cosas obvias, poco fiables para cualquier cosa sutil.
Algunos modos de fallo específicos a tener en cuenta:
Si se utilizan correctamente, los modelos de aprendizaje automático (MLA) aumentan la eficacia de los revisores humanos al realizar primero el trabajo preliminar más evidente. Si se utilizan de forma descuidada, crean la ilusión de rigor sin la sustancia necesaria. Esto representa un error en cualquier contexto de desarrollo y un riesgo potencialmente grave en trabajos críticos para la seguridad.
En conclusión, las revisiones de código entre pares tienen un enorme potencial para mejorar el proceso de desarrollo de software y garantizar la entrega de software de alta calidad.
Para los desarrolladores, participar en revisiones de código entre pares efectivas ofrece varias ventajas clave, como una valiosa oportunidad de aprendizaje que los expone a diferentes estilos de codificación, mejores prácticas y diversos enfoques para la resolución de problemas dentro de su equipo. Este intercambio de conocimientos fomenta el crecimiento profesional y el desarrollo de habilidades. Además, las revisiones de código entre pares ayudan a los desarrolladores a detectar y corregir defectos tempranamente, así como a contribuir a la coherencia y la mantenibilidad del código base.
Para respaldar los procesos de revisión de código exitosos, el uso de herramientas de análisis estático puede ser invaluable. Estas herramientas analizan automáticamente el código en busca de posibles problemas, como violaciones de estándares de codificación, vulnerabilidades de seguridad y malas prácticas de programación.
Para C, C++, Java, C# y VB.NET, Parasoft ofrece herramientas de análisis de código estático como Prueba C / C ++, jprueba y puntoPRUEBA, todos los cuales tienen capacidades de IA y ML y están diseñados para diversos entornos de desarrollo. Al integrar herramientas de análisis estático en el flujo de trabajo de revisión de código, los equipos pueden mejorar la eficiencia y eficacia de sus revisiones. La combinación de la experiencia humana de los revisores pares con la automatización proporcionada por las herramientas de análisis estático optimiza el valor y el impacto de las revisiones de código por pares en el ciclo de vida del desarrollo de software.
Obtén más información sobre cómo integrar la IA en tus flujos de trabajo de pruebas.
