Sería el año 2006 más o menos cuando leí Pragmatic Programmer, el libro que más me ha influido como desarrollador. Por su culpa decidí montar un servidor de integración continua que a día de hoy sigue siéndome de extrema utilidad lanzando vetustos scripts de msbuild que conviven con los mil sistemas de compilación de Javascript.
Lo que se ha caído de ese servidor, o mejor dicho, de los scripts varios que ejecuta, es el cálculo de métricas varias sobre el código.
Al principio me molestaba en calcular métricas sobre el código fuente (utilizaba cosas como Source Monitor para ello), que me indicaran número de líneas de código, complejidad ciclomática, nivel máximo de anidamiento, profundidad de jerarquías…., en fin todo tipo de datos para disfrutar con un poco de porno de estadísticas. Además, analizaba la cobertura de código que alcanzaban mis tests (con NCover, si no recuerdo mal), y tenía configurados mis avisos si no llegaban a determinados niveles.
Nunca les hice excesivo caso, pero era bonito tenerlas y consultar de vez en cuando, e incluso a veces me servían para ver áreas que podía mejorar refactorizando el código o añadiendo más tests.
Hoy en día no uso este tipo de indicadores y no los hecho en absoluto de menos, pero antes de ver por qué yo no consigo sacarles mucho partido, vamos a ver qué razonamientos hay detrás del uso de métricas y por qué, a lo mejor a ti, sí que te resultan útiles.
Si no lo mides, no lo puedes mejorar
Es algo aceptado generalmente. Para poder mejorar algo, necesitas poder medirlo, porque es la única manera de saber si estás mejorando o no.
La idea de las métricas es crear una serie de valores que actúen como proxies de lo que realmente se quiere medir. Normalmente, lo que se quiere medir son cosas como la facilidad para mantener el código, la propensión a contener errores o la fiabilidad.
Para ello, se parte de características del código fácilmente medibles y se asume cierta relación entre ellas y la cualidad que realmente queremos medir. Por ejemplo, en general el código que tiene más complejidad ciclomática es más difícil de mantener. El código con un ratio de comentarios adecuado es más fácil de mantener. Las clases con más líneas de código son más propensas a contener errores. El código cubierto por tests suele tener menos fallos.
Desde un punto de vista puramente estadístico, las métricas pueden llegar a ser muy fiables. Sobre todo si tenemos una muestra lo suficientemente grande y representativa de código que nos permita afinar los valores a partir de los cuales debemos preocuparnos.
Ayuda bastante en ese sentido aplicar técnicas de análisis forense del código que nos ayuden a identificar áreas especialmente problemáticas. Lo bueno de estas técnicas es que trabajan sobre hechos reales, porque están analizando la historia del código, y no se limitan a establecer hipótesis en base al aspecto actual del mismo.
Cuando estamos trabajando con bases de código muy grandes, o con equipos con gente con poco conocimiento desigual, o con mucha rotación de personal, las métricas son una buena forma de mantener un cierto control sobre lo que se está haciendo. Por una parte podemos marcar límites a las barbaridades que hacemos (“no puede haber contructores con más de 10 parámetros”), y por otra nos permiten señalizar potenciales problemas y nos dan una pista de dónde podemos empezar a dedicar esfuerzos para mejorar la salud de nuestro proyecto, como explica Jorge Sánchez.
Lo que mides, es lo que consigues
Es el mayor peligro de empezar a medir cosas y tratar de optimizarlas. Si lo haces bien, te arriesgas a conseguir mejorar esas métricas. Y sólo eso. Por eso es fundamental no olvidar que lo que quieres mejorar no son las métricas sino lo que ellas representan.
En un mundo ideal, estas métricas que hemos elegido como proxy reflejarían perfectamente las cualidades que buscamos en el software, pero en el mundo real, no siempre es así. Puede que ese método con 4 ifs sea más fácil de entender así. O que lleve funcionando 8 años y no haya dado ni un sólo problema. A lo mejor es código autogenerado. ¿El ratio de comentarios? Otro factor muy relativo que depende mucho del tipo de comentario.
En realidad, esto no debería ser un problema. No deberían tomarse las métricas como reglas rígidas, sino como indicadores de cosas que tal vez estén mal. Se supone que deberían servirnos para llamar la atención sobre ellas y decidir si necesitamos solucionarlas o no.
Cuando sí que se puede convertir en un problema es cuando empezamos a evaluar o valorar a los desarrolladores en base a esas métricas.
Entonces es probable que se preocupen más de conseguir un 100% de cobertura de código en los tests, que de escribir tests que realmente sean útiles. Incluso aunque sólo usemos las métricas a título informativo, es fácil que si las estás viendo continuamente te acaben condicionando a la hora de organizarte el trabajo para intentar mejorarlas. Nos gusta jugar y mejorar nuestra puntuación.
No consigo sacarles partido
Con lo que hemos estado viendo hasta ahora, parece razonable pensar que calcular métricas sobre el código, si se hace con sentido común, es una herramienta práctica para desarrollar software.
Pese a ello, no soy capaz de sacarles suficiente partido como para que me compense ralentizar la compilación obteniendo métricas y asumir el riesgo de acabar jugando contra ellas en lugar de centrado en conseguir lo que realmente considero importante.
En mi caso, trabajo en un equipo pequeño, donde todos somos muy conscientes de lo que queremos conseguir y de los valores que queremos reflejar en nuestro código, por lo que el componente de control no me resulta útil.
Trabajo con una base de código relativamente grande, en la que el número de falsos positivos es importante.
Esos casos que mencionaba antes, de clases muy grandes pero que tienen su justificación, o de código feo pero que funciona y nunca hay que modificarlo, aunque son infrecuentes, existen, y si tienes un volumen de código suficiente, son los que acaban copando todos los listados de “métodos más inmatenibles”.
Ello implica que si no quieres estar revisando una y otra vez lo mismo, necesitas mantener algún tipo de configuración en las herramientas de análisis estático para ignorar esos bloques de código, lo que complica el mantenimiento y te acaba llevando al otro extremo, el de los falsos negativos por culpa de haber marcado como “ignorables” partes de la aplicación que no deberían serlo.
Al final le acababa haciendo caso a las métricas para manteneras bonitas, pero no porque realmente me aportaran demasiado. Ya sabíamos de sobra las partes de la aplicación que eran difíciles de tocar y mantener, o dónde se solían concentrar los bugs.
De hecho, había ocasiones en que la solución que más nos gustaba podía ir en contra de las métricas de calidad que habíamos establecido, por ejemplo aumentando acoplamiento para conseguir una mayor cohesión, pero tener las métricas encima nos condicionaba, aunque fuera inconscientemente, a usar soluciones menos atractivas pero con mejor puntuación.
El problema para mi, en definitiva, es que las métricas analizan el código, y el código importa, pero el contexto más.
Cuanto menos contexto tienes, más valiosas se vuelven las métricas, porque al menos te aportan alguna información. Si puedes permitirte estar encima de las cosas y confiar en el sentido común de los que trabajan contigo, la utilidad de las métricas disminuye bastante porque puedes observar directamente la realidad sin necesidad de proxy.
No hay posts relacionados.