Análisis estático: por qué se usa (tan poco)

19 octubre, 2015

Después de leer sobre qué es el análisis estático, seguro que se os ha quedado cara de «¿dónde está el truco?». Por que si hay una forma automática de encontrar todos esos bugs tan molestos, ¿cómo es que no se usa siempre? Resumiendo, podríamos decir que hay dos tipos de razones. Por un lado, están  las técnicas: es difícil construir una buena herramienta de análisis estático. Por otro lado, también está el factor humano: deben ser sencillas de usar e integrarse fácilmente al flujo de desarrollo de una empresa concreta.

Empecemos por las cuestiones técnicas. Un artículo muy interesante sobre el tema es «A Few Billion Lines of Code Later: Using Static Analysis to Find Bugs in the Real World«, publicado en 2010 en la revista Communications of the ACM. El artículo explica, en primera persona, la experiencia de la empresa Coverity al aplicar sus herramientas de análisis estático en un contexto real.

El primer problema que se encontraban al aplicar su herramienta en un nuevo cliente era de lo más gracioso: cómo encontrar el código fuente. Un ingeniero suele saber qué instrucciones  (o botones, si se usa una GUI) usar para compilar el código pero… ¿cómo decirle a una herramienta dónde encontrarlo? ¿En el disco duro? ¿En un sistema de control de versiones? ¿En un servidor de integración continua? En aplicaciones sencillas es muy fácil, pero en productos complejos el proceso de compilación puede llegar a ser muy complejo. Por ejemplo, parte del código puede ser generado a partir de un fichero de configuración. En esta situación, no basta con decirle a la herramienta «el código está en este directorio». Ojalá.

El código fuente... qué bonito es cuando funciona. Fuente: nyuhuhuu @ Flickr - Licencia: CC BY 2.0
Código fuente: qué bonito es…. cuando funciona. Fuente: nyuhuhuu @ Flickr – Licencia: CC BY 2.0

Otro problema divertido es que, como dicen los autores con ironía, en el mundo real los lenguajes de programación no existen. Cada compilador tiene sus peculiaridades y sus comportamientos no estándar, de forma que C++ no existe: tenemos el C++ de GCC, el C++ de Borland, … Esto quiere decir que, sin darnos cuenta, es sencillo desarrollar un programa que sólo compila en tu ordenador. Como ejemplo, mencionan a un cliente que les echó a patadas porque «el analizador es tan malo que ni siquiera sabe compilar código C». El motivo: el fichero de cabeceras «.h» usado en todo el proyecto contenía una declaración C ilegal  que su compilador se «tragaba» sin queja alguna. Adiós, sr. Cliente.

De las cuestiones humanas trata el artículo  «Why Don’t Software Developers Use Static Analysis Tools to Find Bugs«, publicado en 2013 en el International Conference on Software Engineering. Aquí la perspectiva no es la del creador de herramientas de análisis, sino la del usuario que la va utilizar.

A partir de un conjunto de entrevistas a desarrolladores de una gran empresa no identificada (*ehem* Google *ehem*), los autores analizan por qué motivos se usan (o no) las herramientas de análisis estático. Algunos motivos a favor de usarlos eran:

– Automatizar la búsqueda de errores.

Comprobar convenciones de programación y estilo de forma automática.

-Facilitar el trabajo en equipo (al detectar y evitar errores triviales al modificar código de terceros).

Respecto a los puntos débiles, los más destacados eran:

– La dificultad en la comprensión de los mensajes de error (¿Cuál es el problema? ¿Qué tengo que arreglar?).

– El exceso de falsos negativos.

– La dificultad en configurar un analizador para ocultar falsos positivos (p.ej. no mostrar los posibles errores en este fichero).

– El problema de encajar el analizador en el flujo de herramientas y de trabajo de la empresa (¿Cuando se hace el análisis? ¿En cada nueva versión? ¿Cada cierto tiempo? ¿Lo hace el propio programador?).

El último punto tiene muchas ramificaciones. Por ejemplo, cuando desarrollamos tenemos en la cabeza el comportamiento deseado y cómo funciona el código. Si en ese momento nos muestran un posible mensaje de error, es sencillo que podamos retomar el hilo y corregir los defectos. Sin embargo, si esta información la recibimos al cabo de muchos días, seguramente ya no recordaremos los detalles del código en que trabajábamos. Para ver si realmente es un error o corregirlo tendremos que dejar lo que estamos haciendo y «cambiar de contexto», perdiendo un tiempo precioso. Enviar el informe en un mal momento del ciclo de desarrollo puede hacer que sea ignorado.

Precisamente este aspecto se trataba en la charla Moving Fast with Formal Verification de Peter O’Hearn, donde explicaba su experiencia aplicando herramientas de análisis de código en Facebook (concretamente Infer, un analizador estático para aplicaciones móviles). En Facebook, cada desarrollador trabaja en su código y cuando lo ha completado lo envía para su revisión e inclusión en el build oficial. Este código debe ser revisado y validado/firmado por un cierto número de personas. En esta investigación, comprobaron que presentar el informe de errores cada vez que se envía el código a revisión conseguía que los desarrolladores corrigieran un 80% de los bugs notificados. En comparación, cuando los informes de errores se hacían llegar diariamente (en un proceso batch nocturno, el nightly build), nadie les hacía caso.

Resumiendo, las ventajas de usar el análisis estático son muchas, pero son herramientas complejas y hay que saber aplicarlas en un proyecto u organización concreta para sacarles todo su provecho.

(Visited 146 times, 1 visits today)
Autor / Autora
Robert Clarisó Viladrosa
Comentarios
Deja un comentario