Como era de esperar, hay muchas novedades, todas muy importantes para el ecosistema de SonarQube y habrá que empezar a mirarlas con lupa para sacarles el máximo partido y seguir mejorando la calidad de nuestro código.
Si tuviese que escribir una frase que resuma las novedades, me quedaría con la que he usado para el título del artículo: “El programador es la clave”
Puede sonar absurdo, ¿verdad? Si el código lo escribe el programador cómo no va a ser la clave… Claro, que fácil es decirlo… Pero hay que ir más allá, pensad por un momento que hasta ahora la única forma eficiente de conocer la calidad del código era esperar a que el programador suba los cambios a un control de versiones y se desencadenase un análisis en SonarQube. ¿Pensáis que eso es efectivo? No lo es. La clave está en que el programador suba el código sin los posibles defectos. Los defectos nunca deberían pasar por el control de versiones. Menudo reto, ¿verdad? Pues esto ya es posible, e irá mejorando mucho estos meses.
Os cuento como todo esto va a ser posible con las 4 piezas clave que se presentaron en la conferencia:
El pasado es historia, céntrate en el presente
La cantidad total de nuestra deuda técnica en el pasado puede ser deprimente. Si alguien pretende mejorar la calidad del pasado tendrá que invertir mucho esfuerzo. Puede que alguien diga que sí a esa inversión pero después, ¿cómo podemos asegurar que solucionamos la deuda sin caer en problemas de regresión? Que miedo… Esto no es nada divertido.
Por eso el programador tiene que tener toda la información disponible, en todo momento. SonarQube nos ofrece diferentes alternativas:
- Umbrales de calidad sobre el código nuevo: esta funcionalidad se introdujo en la versión 5 y permite fijar tus requisitos basándonos solo en las métricas sobre el código nuevo. Aquí esta la clave de todo. Si no paso el umbral de calidad sobre el código nuevo que acabo de escribir, mal vamos. Ese código es fácil de cambiar (lo acabas de hacer) así que ya no tienes excusas para no hacerlo. Tampoco tienes excusas para no cubrir con pruebas unitarias ese código nuevo.
- Notificaciones: desde hace algún tiempo, un poco escondidas pero ahí están. Podemos decirle a SonarQube que nos envíe un email cada vez que detecte que hemos introducido nuevas evidencias. Ya no tenemos que ir a la plataforma web a ver si nos hemos despistado y hemos introducido malas prácticas, nos enviará un correo para informarnos con un enlace para ir a los detalles.
|
Configuración de notificaciones |
|
Ejemplo de email recibido al detectar evidencias nuevas |
Analiza el código en un Pull Request con GitHub o BitBucket
Para poder adelantarnos al “commit” y no introducir evidencias que mejor que integrar el análisis en un Pull Request. A estas alturas, las bondades de Git ya son conocidas por todos, y las dos principales plataformas de colaboración son GitHub y BitBucket. ¿Qué mejor forma que integrar en el Pull Request un comentario que nos diga si hemos introducido evidencias? Así, de forma colaborativa los programadores discuten que es lo que ha pasado y aceptan o no la petición antes de que llegue al control de versiones.
|
Pull Request con el análisis de calidad y las evidencias detectadas |
Tal y como decía, el programador es la clave. Anticiparle toda la información posible será la mejor forma de mejorar su código.
Desacoplando la base de datos de los análisis
¡POR FIN! Si, si, tal y como leéis, una de las cuestiones más conflictivas de SonarQube ya ha sido resuelta. Ya no hará falta configurar un usuario de base de datos porque con la aparición del “Compute Engine” ya no se accede a la base de datos en tiempo de análisis. Esto tendrá más consecuencias, por supuesto (¡cuidado con los plugins!), pero significa que se elimina un cuello de botella muy importante y se mejora la seguridad de la plataforma. Esto además permite separar esfuerzos y escalar de forma mucho más fácil (dentro de poco el “Compute Engine” será un proceso Java independiente, como lo es el indexador de ElasticSearch.
SonarLint, resuelve las evidencias antes de que aparezcan
La independencia de la base de datos va a permitir introducir muchas novedades. La primera, el nuevo producto SonarLint. Busca las evidencias en tiempo real a la vez que estás codificando. Tal cual. Como el corrector de Word. Es algo totalmente nuevo con varias herramientas:
- Para los desarrolladores, super rápido, fácil de usar
- No requiere instalar un servidor SonarQube (OMG!)
- Cubre los lenguajes más populares (C#, Java, JS, PHP, …)
- Análisis on-the-fly
- ¡Se puede usar offline!
- Para Eclipse, Intellij, Visual Studio.
Y en el futuro podremos:
- Solucionar evidencias de forma automática (oh yeah!)
- Compatibilidad con más lenguajes (nos enseñaron un ejemplo con código COBOL :-) )
- Filtros en local de las evidencias
Y más aún, aunque esta funcionalidad requerirá de conexión con el servidor de SonarQube:
- Personalización del perfil de calidad, plugins, …
Y más y más:
- Mostrar solo las evidencias nuevas
- Esconder falsos positivos
- Filtrar por asignado (mis evidencias)
Esto último requerirá enlazar con el proyecto y análisis regulares en el servidor.
¿Qué te parece?
Y con esos cuatro temas principales cerramos el artículo... ¿Es suficiente para demostrar que la clave es el programador? Espero que sí. Hay muchas cosas más por supuesto, pero es algo que os iremos descubriendo conforme avance la publicación de la versión 5.2 de SonarQube.
Y tú, ¿qué le pedirías a SonarQube? ¿Te parece que vamos por el buen camino?