Análisis Estático del Código

1.909 palabras · 9 minutos

28/12/2009

Imaginemos que somos miembros de un equipo de desarrollo. Nos encontramos creando cierto software y en un momento determinado nos planteamos analizar estáticamente el código. ¿A qué nos referimos con esto?, ¿qué vamos a hacer exactamente?, ¿en qué consiste esta tarea?. Es posible que la definición más breve y concisa de la técnica que vamos a utilizar sea la siguiente:

"El análisis estático del código es el proceso de evaluar el software sin ejecutarlo"

Es, por tanto, una técnica que se aplica directamente sobre el código fuente tal cual, sin transformaciones previas ni cambios de ningún tipo. La idea es que, en base a ese código fuente, podamos obtener información que nos permita mejorar la base de código manteniendo la semántica original.

El analizador estático de código, para ello, recibirá el código fuente de nuestro programa, lo procesará intentando averiguar qué es lo que queremos que haga y nos dará sugerencias con las que poder mejorar ese código.

Pero, ¿cómo hace esto?, ¿qué hace para "saber" qué es lo que queremos hacer y qué podemos hacer para mejorarlo?. Estas herramientas incluyen, por un lado, analizadores léxicos y sintácticos que procesan el código fuente y, por otro, un conjunto de reglas que aplicar sobre determinadas estructuras. Si nuestro código fuente posee una estructura concreta que el analizador considere como "mejorable" en base a sus reglas nos lo indicará y nos sugerirá una mejora.

Y todo esto, ¿para qué sirve?, ¿qué salimos ganando realizando estos análisis?. Básicamente ganamos en facilidad de mantenimiento y de desarrollo ya que su objetivo es minimizar la deuda técnica de nuestros proyectos, y es que algunas de las funciones de los analizadores consisten en encontrar partes del código que puedan:

Como podéis ver su misión es la de servirnos de ayuda en nuestros desarrollos, ayudándonos a detectar nuestros propios errores y ofreciéndonos posibles soluciones a los mismos. Nos ofrecen mucho y no nos piden nada a cambio, así que, ¿por qué no utilizarlos?

¿Qué tipos de análisis estático del código existen?

Podríamos decir que existen dos. Por un lado está el análisis automático que realiza un programa de ordenador sobre nuestro código y por otro está el análisis manual que realiza una persona. Cada uno de estos análisis persigue unos objetivos concretos:

Ambos, por tanto, son complementarios. El análisis automático se centra únicamente en facetas de más bajo nivel como la sintaxis y la semántica del código, funcionando este análisis en cualquier tipo de aplicación, mientras que el análisis manual se ocupa de facetas de más alto nivel como, por ejemplo, la estructura de nuestra aplicación o su manera de trabajar con otros elementos externos como las librerías.

La unión de ambos tipos de análisis nos permitirá identificar los potenciales problemas a distintos niveles que generen la deuda técnica de nuestro proyecto. Debemos, por tanto, unificar ambas para poder mejorar la base de nuestro código fuente, lo cual repercutirá en una mejora tanto del desarrollo como del mantenimiento de nuestro software antes incluso de llegar a ejecutarlo.

¿Cuándo debemos hacer estos análisis?

Ahora que conocemos las ventajas del análisis estático del código, que sabemos lo útil que es, que sabemos que existe el análisis manual y el automático y que sabemos que nos va a ayudar a hacer nuestros desarrollos cabe preguntarnos ¿cada cuánto debo realizar este análisis?, ¿cada vez que escriba una nueva línea de código en mi aplicación?, ¿cada vez que termino el desarrollo una nueva funcionalidad?

Debemos tener en mente que el análisis estático del código es un medio con el que conseguir mejorar nuestro código fuente, no un fin en sí mismo. Debemos, por tanto, usarlo únicamente como apoyo.

Una diferencia entre el análisis automático y el análisis manual es el tiempo que éste tarda en realizarse. De este modo un análisis automático se realiza en pocos minutos mientras que uno manual puede tardar varias horas. Esto, como es natural, influye a la hora de establecer una periodicidad.

Deberíamos tratar de realizar el análisis manual cada vez que vayamos a crear una nueva funcionalidad en nuestro software, preguntándonos en este caso si la arquitectura actual nos permite implementarla con facilidad, si disponemos de las librerías adecuadas o si podemos modificar la base de nuestro código para facilitar el desarrollo de esta nueva funcionalidad. Es decir, lo reservaremos para situaciones concretas.

Como es natural también podremos hacer este tipo de análisis cuando el proyecto sencillamente va mal, cuando nos cueste mucho esfuerzo desarrollar nuevas funcionalidades o modificar las que ya tenemos o, en definitiva, cuando sintamos que las piezas del software que estamos desarrollando chirrían, aunque este último caso no es el deseable y es precisamente lo que queremos evitar con el análisis estático del código.

El análisis automático, en cambio, puede ser realizado con una mayor periodicidad ya que no requiere de intervención humana y, lo que es mejor, puede ser programado y repetido tantas veces como sea necesario. Además obra con objetividad, siempre nos va a devolver la misma respuesta ante el mismo código fuente de entrada.

Sin embargo no tenemos que creernos literalmente lo que nos diga. Puede que entre sus reglas esté determinada una condición de error concreta que, en nuestro código en particular, no debería ser etiquetada como tal.

El caso ideal sería integrar nuestro analizador automático con alguna opción de integración continua o alguna tecnología que permita generar la aplicación a partir de nuestro código fuente. De este modo cada vez que hagamos algún cambio o que queramos generar nuestra aplicación se ejecutará el analizador automático y este, a su vez, nos hará sugerencias.

Los desarrolladores, por lo general, cuando implementamos por completo alguna funcionalidad en nuestros ordenadores dejamos nuestro código fuente en un repositorio centralizado donde el resto de desarrolladores puedan encontrarlo. Un buen momento para analizar automáticamente el código es el instante en el que ese código pasa de estar únicamente en nuestros ordenadores a formar parte del repositorio, ya que así todo el equipo de desarrollo puede ser consciente de las posibles mejoras que se puedan realizar sobre ese código.

Sin embargo, es posible que queramos que el código ya se encuentre mejorado antes incluso de formar parte del repositorio. Los desarrolladores disponemos, por lo general, de herramientas que transforman nuestro código fuente en aplicaciones. Si utilizamos nuestro analizador automático en nuestro propio ordenador cuando convertimos nuestro código fuente en aplicaciones sólo nosotros recibiremos las sugerencias y podremos seguirlas antes de poner el código a disposición de todo el equipo de desarrollo.

En cualquier caso estas no son reglas de oro ya que el momento en el que se deba realizar el análisis estático del código dependerá del proyecto concreto y de sus circunstancias.

Actividades complementarias al análisis estático del código

Las posibilidades de mejorar nuestra base de código no quedan aquí. Hay otras técnicas que podemos utilizar para conseguir mejorar el código fuente de nuestra aplicación y, con ello, el software que utilizan los usuarios como producto final.

Estas técnicas, al contrario que la que nos ocupa, se centran en analizar el código mientras este se encuentre en ejecución. Explicarlas excede el alcance del presente documento pero, sin embargo, se van a resumir brevemente para poder situar aún mejor el análisis estático del código dentro de su ámbito:

Estas técnicas permiten encontrar errores en el software que no es posible detectar cuando se analiza estáticamente el código aunque, sin embargo, es posible que el análisis estático del código nos permita corregir algunos errores antes incluso de detectarlos durante la realización de tests o de profiling.

Limitaciones del análisis estático del código

Sin embargo, a pesar de sus ventajas, los analizadores estáticos del código tienen sus limitaciones:

Conclusiones

A lo largo de este documento hemos introducido la técnica del análisis estático del código, explicando para ello sus objetivos y sus metas y dividiéndolo entre análisis manual y análisis automático, lo cual nos ha permitido determinar las diferencias de uno con respecto al otro en distintos ámbitos.

También lo hemos englobado con otras técnicas que permiten mejorar la base del código como son los tests y el profiling, los cuales tienen su origen en la ejecución de dicho código.

¿Es realmente importante hacer este tipo de análisis?, ¿deberíamos realizarlo o podríamos seguir como estamos?. Esta técnica es muy sencilla de utilizar, si la automatizamos incluso podemos limitarnos a esperar sus resultados, y como podéis ver nos ayuda sin pedirnos nada a cambio.

En mi opinión es un tipo de análisis que deberíamos hacer. No cuesta trabajo y sólo puede darnos beneficios, tanto a corto plazo mirando en el desarrollo más inmediato como a largo plazo en vistas a un futuro mantenimiento.

Pero, ¿deberíamos quedarnos únicamente ahí?, ¿o podemos hacer algo más para mejorar nuestro código y, con ello, nuestros desarrollos?. Si queremos mejorar la calidad de nuestros productos hacer este tipo de análisis es un buen primer paso, pero quizá deberíamos dar algún paso más completándolo con tests e incluso con profiling.

En cualquier caso, ¿qué podemos perder con probarlo?. El coste es cero y los beneficios palpables, ¿existe una relación calidad/precio mejor?