Si aún no has leído los cinco primeros errores más comunes puedes hacerlo ahora y así ponerte en contexto.
A continuación te dejo con el resto de la recopilación:
Aunque en los últimos años ha mejorado mucho hay cosas que el análisis estático no puede detectar: problemas de configuración, errores que solo se dan en tiempo de ejecución, …
Por eso no basta solo con el análisis estático. Siempre tienes que proporcionar un buen conjunto de tests que aseguren otros aspectos de calidad (unitarios, integración, rendimiento, …). Estos tests pueden asegurar que el código cumple con ciertos requisitos de forma diferente a como lo hace el análisis estático.
Es un error muy común pensar que solo usando análisis estático vas a poder solucionar todos tus problemas. Nada más lejos de la realidad. El análisis estático es potente, pero no tanto.
No puedes dejar que cada desarrollador trabaje con un IDE con configuraciones que no estén alineadas con las herramientas de análisis estático.
Hay que proporcionar las configuraciones adecuadas para cada IDE de forma que las inspecciones de código que se hagan en el IDE sean las mismas (o lo más parecidas posible) a las normativas definidas y al análisis estático. De nada sirve que la configuración del IDE indente con cuatro espacios y que luego la regla de análisis estático valide que sea con dos espacios. Tienes que revisar con mucho detalle todas las reglas existentes en el IDE y activar/desactivar las reglas que sean necesarias para alinearlas con los estándares definidos.
Cada vez que se añada una regla nueva en el análisis estático habrá que revisar que los IDEs también la incluyen. En el caso de SonarQube esto es bastante sencillo al poder utilizar el plugin “SonarLint” que incluso permite sincronizarse con el servidor de SonarQube de forma automática.
Ya tienes todo montado y funcionando. Los desarrolladores están motivados y el ciclo de desarrollo incluye el análisis estático como un paso más. ¿Y ahora qué?
Si poco a poco vas abandonando el proceso y no difundes las mejoras, no haces seguimiento, no pides feedback a los equipos, no actualizas las herramientas, no incluyes reglas nuevas, … el análisis estático acabará siendo ineficiente y no se producirá un ciclo de mejora continua. Dejará de aportar valor en poco tiempo.
Es fundamental comunicar los cambios, revisar el proceso frecuentemente, revisar y proponer reglas, hablar con los equipos para ver si hay más cosas que se puedan incluir en el análisis estático, comprobar y comunicar los resultados (¿hay menos errores en producción o todo sigue igual?).
Muy común. Una vez alguien detecta un falso positivo el análisis estático pierde todo su prestigio y “ya no vale”. Hay desarrolladores que están deseando que eso ocurra para quitarle valor.
Y es que las herramientas no son perfectas (ni los humanos tampoco, a pesar de que algunos desarrolladores tengan el ego muy alto), eso es evidente, por tanto habrá casos en los que la herramienta no será lo suficientemente inteligente como para saber si ese trozo de código va a producir un error o no. Ante la duda, se marca como posible defecto y ya el desarrollador deberá tomar la decisión final.
Por ejemplo, en SonarQube es muy fácil marcar falsos positivos, así que no debería haber quejas sino todo lo contrario. Incluso si alguna regla produce demasiados falsos positivos entonces habrá que revisarla en profundidad porque es probable que haya que desactivarla o activar otras alternativas.
Es preferible tener pocas reglas que puedas entender e ir corrigiendo a tener muchas reglas que no sabes ni porque están ahí y que no puedas corregir.
Si no tienes tiempo suficiente para hacer un primer estudio de lo que quieres incorporar y las reglas que necesitas activar, prueba con un conjunto muy básico (aquellas que sean más graves) y empieza a sacar métricas del análisis estático. No te preocupes. Divide y vencerás. Empieza con lo mínimo y poco a poco trabaja en mejorarlo. Ese es el objetivo y ese ciclo de mejora continua es lo que más te va a ayudar.
Añade reglas poco a poco evitando las más controvertidas e inconvenientes y será la mejor forma de asegurar la calidad de tu código.
Puedes empezar incluso sin reglas. Te sorprendería ver cuanta información valiosa pueden aportar métricas como la complejidad ciclomática o el código duplicado (o repetido). Pero eso lo dejo para otro artículo.
Efectivamente. No pensarías que es todo tan fácil, ¿verdad? Recuerda que aunque los gestores deberían programar no lo hacen, así que no saben nada de esto ni le van a dar importancia. Tienes que conseguir ganarte a los gestores para estar de tu parte o no vas a tener una forma de poder dedicar suficiente tiempo a preocuparte por el análisis estático.
Esto es así porque no es algo a corto plazo sino más a medio o largo plazo y hay que invertir tiempo. Tienes que hacer entender a los gestores que el análisis estático tiene un gran retorno de inversión (o aliarte con alguno que piense así). Tienen que entender los requisitos, los objetivos y permitir que se dedique tiempo suficiente.
Lo que pasará si no consigues alinearte con ellos es que dedicarás mucho esfuerzo que no servirá de nada.
Con esto completamos el segundo “pack” de errores comunes que deberías evitar en el uso de análisis estático.
El análisis estático no es simplemente instalar una herramienta y ya está. Requiere dedicación, colaboración, difusión y una serie de tareas adicionales que si no se tienen en cuenta te llevarán al fracaso. Así que ya sabes, como con todo en esta vida, cuando te embarques en esa difícil misión de implantar análisis estático, reflexiona y planifica bien todo lo que vas a hacer, porque de eso dependerá que el análisis estático sume todas sus ventajas a tu proceso de desarrollo.
En resumen:
Esas son algunas de las cosas que tienes que tener en cuenta pero seguro que tú conoces más, así que deja un comentario y seguimos debatiendo.