Herramientas para asegurar la calidad de software

Herramientas para asegurar la calidad de software

Introducción

La calidad de software es un requisito fundamental.

Pero no lo es por el mero hecho en sí…

Porque nos haga quedar como que somos más pro…

Tampoco lo es porque lo haya dicho algún referente…

Lo es, principalmente porque ahorra dinero.

Que el código tenga más calidad, significa que va a ser menos propenso a errores.

Por lo tanto, va a haber que invertir luego menos tiempo (dinero) en solucionarlos.

Y no sólo tiempo de los desarrolladores. Sino tiempo de todo el equipo implicado.

Esto, que ya de por sí sería suficiente motivo, es casi lo de menos.

¿Por qué?

Porque si la calidad de nuestro software es mediocre y tenemos más bugs, nuestros usuarios perderán confianza en nuestro producto. Y ello tiene implicaciones mucho más relevantes.

Por lo tanto, que nuestro código sea de calidad nos ayuda a mejorar la calidad de nuestro producto / proyecto.

val qualityProduct = qualityCode 😉

Ejemplo con Código Fuente

Es un proyecto open source con licencia Apache 2.0. Con lo que puedes copiar y pegar sin miedo para usar directamente en tus desarrollos.

En mi proyecto Base, puedes ver cómo varias de las herramientas que te voy a explicar a continuación puedes ser aplicadas.

Disclaimer

La clasificación que hago es a título personal.

Es posible que encuentres otras fuentes donde se haga de diferente modo.

Tipos de herramientas

Existe gran variedad de herramientas disponibles para ayudar a asegurar la calidad del software.

Estas se pueden usar para realizar:

• Análisis dinámicos
• Análisis estáticos

Los análisis dinámicos se usan para ejecutar una aplicación y monitorear su ejecución y así detectar posibles errores.

Las herramientas de análisis estáticos lo que hacen es examinar el código fuente de un proyecto para identificar posibles fallos.

Herramientas de Análisis Dinámicos

Tests Manuales

• Probar la app
• Pruebas de regresión

Las pruebas de regresión sirven para volver a probar una aplicación después de que se hayan realizado modificaciones y así asegurarse de que esos cambios no hayan introducido nuevos errores.

Tests Automatizados

• Tests Unitarios
• Tests de Integración
• Tests de Screenshot
• Tests de UI
• Tests End 2 End

Herramientas de Análisis Estáticos

Herramientas Manuales

Pull Requests

Las propias PRs son análisis manuales que nos permiten analizar el código de nuestros compañeros y que ellos analicen el nuestro.

Pair Programming

Es una revisión en vivo de lo que está programando el compañer@.

Mob Programming

Lo mismo que el pair programming, pero con más gente. 😊

Herramientas Automáticas

Code Style

El Code Style de Android Studio es una herramienta que cuando la dominas, te puede ahorrar una de horas de trabajo impresionante.

Además, incluso podemos meterla en el control de versiones, ya que nos va a ayudar a que cuando hagamos “Reformat Code”, todos los miembros del equipo sigamos el mismo estilo.

Lo ideal es que puedas hacer “Reformat Code” siempre que puedas en un fichero. Sin tener miedo a que al hacerlo, se vaya a descuajeringar todo. 😅

De este modo, todo quedará bien formateado para que sea más legible.

EditorConfig

El .editorconfig nos sirve para aplicar reglas automáticas que definan el estilo del código del proyecto.

Ejemplo:

root = true  [*] end_of_line = lf insert_final_newline = true  [*.{kt, kts}] indent_size = 4 indent_style = space max_line_length = 100

Linters Vs Analizadores estáticos de código

¿Cuáles son las diferencias entre un linter y un analizador estático de código?

Un linter analiza el código ejecutándolo para encontrar posibles issues, bugs, memory leaks, etc.

Un analizador estático de código, analiza el código fuente sin que haga falta tener que correrlo.

Linters

El nombre de Lint viene porque originalmente había una herramienta para C que verificaba el código y se llamaba así.

Lint

El propio lint de Android Studio es un linter que nos da indicaciones en tiempo de compilación.

• Va de serie con AS
• Sirve para XML
• Puedes crear tus propias reglas

Ktlint

Ktlint es una herramienta anti-bikeshedding.

El bikeshedding es un concepto que significa básicamente gastar tiempo en trivialidades.

Por lo tanto, si ponemos una regla, pues ya no hace falta discutir. 😄

Primero se llega a un acuerdo, por supuesto.

Pero luego, ya no hay malentendidos.

Se sigue y punto. 🎯

• Plugin de Gradle en AS
• No sirve para XML
• Puedes crear tus propias reglas

Aparte de añadir tus propias rules, puedes aplicar un modo de autocorrección del código con ktlintFormat. Lo cual es extremadamente útil, ya que automatizamos el proceso de modo similar al que hacemos con “Reformat Code”.

Puedes visualizar los issues directamente en Android Studio instalando un plugin no oficial.

Analizadores estáticos de código

Detekt

Detekt es una analizador estático de código para Kotlin con el que podemos detectar code smells y multitud de reglas de estilo de código.

Para visualizar los issues directamente en Android Studio, hay que instalar su plugin.

Herramientas de SonarSource

Sonar, SonarSource, SonarLint, SonarQube y SonarCloud son marcas registradas de SonarSource. Por lo que hablamos digamos de una suite de tools.

Resumiendo, SonarQube es una herramienta clásica de análisis estático de código.

Dos de sus puntos fuertes son la integración con diversas plataformas y los reportes.

Y SonarLint es un plugin para diversos IDEs (Android Studio incluido) que sirve como integración para encontrar bugs, code smells y vulnerabilidades.

Se puede integrar con SonarQube y SonarCloud.

Conclusión

En lugar de tener que seguir de manera manual unos agreements en tu equipo de trabajo, lo único que tienes que hacer es añadir un regla.

Por ejemplo: en una reunión se acuerda que no se pueden poner un par de líneas en blanco seguidas.

Y al automatizarlo con una regla, hasta que no se cumple, no se va a poder mergear a la rama principal. ✅

Tips

Pre-push

Alguno de estos analizadores de código, quizá sería interesante meterlo justo antes de hacer push.

Por ejemplo: en un script de pre-push, para que justo antes de hacer push a una rama, se ejecute el ktlint localmente para detectar errores de formato y no haga falta ni correr el CI directamente.

Coherencia

Hay que tener en cuenta que las reglas entre las distintas herramientas que usemos deben de ser coherentes.

Por ejemplo, si habilitamos las Trailing Commas en Android Studio y luego se marcan como algo a evitar en ktlint, pues irían chocando continuamente. 😅

Bola extra

La clave es estar siempre con hambre de aprender y mejorar.

• Ser receptivo frente a los comentarios de los demás en las PRs.
• Tratar de aportar valor con puntos de vista diferentes en las PRs de tus compañer@s.

No es lo mismo decir “esto está mal”, que “esto quizá se podría hacer de otra manera”, y a continuación (importante) explicar esa manera de hacerlo.

No hace falta que lo dejes todo detallado si es muy largo. Pero quizá una simple url al modo de hacerlo, puede ser de mucha ayuda y enriquecer las hard skills de tus compañeros.

Por lo tanto, tu actitud es lo más importante.
La mejor herramienta para asegurar la calidad del código eres tú. 🤗