Herramientas de análisis estático: cuando menos es más

El análisis de código estático (o análisis estático) es una actividad de prueba de software en el desarrollo de software, en la que el código fuente se analiza en busca de construcciones que se sabe que están asociadas con errores de software o vulnerabilidades de seguridad. Cuando se detecta una construcción de alto riesgo, la herramienta de análisis estático informa una infracción para que el desarrollador la vea y corrija.

La ejecución de análisis estáticos en el escritorio proporcionará algunos beneficios y puede funcionar para equipos o proyectos pequeños; sin embargo, en organizaciones grandes, el análisis estático también debe automatizarse como parte de las compilaciones nocturnas y la integración continua. Cuando se implementa como parte integral del proceso de desarrollo, analizar su código con análisis estático proporciona una serie de beneficios. La ejecución constante de análisis estáticos desde las primeras etapas del proyecto le permite encontrar y corregir defectos sistémicos cuando el costo de reparación es el más bajo. Análisis de código estático le ayuda a encontrar y corregir defectos de forma temprana, lo que puede prevenir la recurrencia de defectos sistémicos en el futuro. Con una política de detección temprana, puede implementar más fácilmente una política de prevención de defectos, que reduce la tasa de defectos durante el ciclo de vida del desarrollo.

Sin embargo, durante la adopción del análisis estático en un proyecto, a veces puede resultar abrumador. Si tiene una base de código grande, las herramientas de análisis estático pueden informar una gran cantidad de infracciones. Esta publicación analizó dos consejos para reducir los informes de infracciones de análisis estático.

Consejo 1: utilice supresiones de herramientas de análisis estático para exenciones en situaciones específicas

En algunos casos, es posible que esté comprometido a seguir una regla de análisis estático, pero desee permitir exenciones en determinadas circunstancias. Por ejemplo, tal vez tenga una regla que requiera que se realice algún nivel adicional de validación en el código. Suponga que tiene un determinado método con código de rendimiento crítico que se llama cientos de veces por minuto, y que ya ha verificado que se realiza un nivel adecuado de validación antes de llamar a este método en particular. O bien, suponga que el análisis basado en flujo le advierte sobre un problema grave en una ruta que está 100% seguro de que no se puede seguir en la aplicación integrada. Aquí es donde las supresiones de análisis estático resultan útiles.

Las supresiones son ideales para situaciones en las que desea verificar algo, pero no le importan los problemas reportados en situaciones excepcionales. Con las supresiones, puede continuar verificando un problema crítico sin recibir mensajes repetidos sobre sus infracciones intencionales de las reglas de análisis estático. Si no desea recibir mensajes de error por cualquier infracción de una regla específica, le recomendamos que desactive la regla por completo (consulte nuestra anterior blog sobre cómo limpiar su conjunto de reglas de análisis estático).

Por lo general, puede definir supresiones desde la GUI de la herramienta de análisis estático, un archivo de configuración o el código fuente en sí. Cuando las supresiones se definen en el código fuente:

• Se asegura de que se apliquen las mismas supresiones siempre que usted o un miembro del equipo analicen ese código.
• Puede agregar comentarios de código que expliquen cada supresión para que el motivo de cada supresión sea siempre claro cuando usted o los miembros del equipo estén revisando o modificando el código.
• Obtiene un control detallado sobre qué reglas se aplican a nivel de archivo, clase o línea.

Por lo general, puede suprimir las infracciones de una regla específica, varias reglas o todas las infracciones de una categoría específica. También puede eximir ciertas secciones de código de todo análisis estático (más sobre esto en el siguiente consejo).

Consejo 2: Evite que su herramienta de análisis estático compruebe archivos problemáticos o fragmentos de código

A veces simplemente no tiene sentido ejecutar herramientas de análisis estático en ciertos archivos, por ejemplo, archivos generados automáticamente o archivos heredados que no planea tocar. En estos casos, debe evitar que se analicen estos archivos. Esta es otra forma de asegurarse de que sus resultados no estén abarrotados de infracciones que no planea corregir.

Hay varias formas de hacer esto. Puede configurar filtros de ruta para excluir los archivos que no desea verificar o incluir solo los que sí desea verificar. O bien, puede configurar su herramienta para omitir archivos que contengan un comentario determinado, como un comentario que indique un código generado automáticamente.

Otras formas de enfocar la verificación de su herramienta de análisis estático incluyen:

• Agregar marcadores para indicar bloques específicos de código que desea verificar dentro de archivos que de otro modo estarían exentos.
• Excluir ciertos métodos dentro de archivos que de otro modo se analizarían.
• Comprobando solo los archivos que no se agregaron o modificaron desde una fecha límite determinada.
• Comprobando solo los archivos que se agregaron o modificaron después de una "fecha límite" o dentro de un cierto número de días.