Antonio Calero

Más allá de la deuda técnica. La deuda de la gestión

2016-09-04T06:00:00+00:00

La deuda técnica

El concepto de deuda técnica fue introducido por Ward Cunningham en el año 1992 y viene a significar que las malas prácticas en el desarrollo de software provocan una situación de deuda que repercute en un sobrecoste no sólo en el proceso de mantenimiento del software de un sistema de información sino también en su propio funcionamiento.

La deuda técnica se calcula detectando un conjunto de malas prácticas sobre diferentes características del software (estructura, complejidad, código duplicado, defectos potenciales, malas prácticas, …) y en función del coste que tiene solucionarlas. Esto permite obtener un ratio de deuda técnica viene a decirnos la calidad general de nuestro código y como de “sostenible” es a lo largo del tiempo. Algo así como los “intereses” que estamos pagando si hacemos las cosas mal.

Herramientas como SonarQube han popularizado este concepto al permitir automatizar mediante análisis estático y de forma más o menos “objetiva” el cálculo de los valores asociados a la deuda. Sin embargo esto ha hecho que siempre hablemos de deuda referida a la calidad del código. ¿Qué pasa con todo lo que rodea al software que no sea código? Es evidente que también puede repercutir en la deuda general del proyecto… pero, ¿alguien alguna vez se ha parado a medirlo, o al menos lo ha intentado?

Si es que mira que los técnicos somos raros (por no decir insultos), resulta que construimos modelos para evaluar nuestra propia deuda “técnica” pero nadie evalua la deuda de los que no saben programar, la deuda que no es técnica, la deuda de la gestión. ¿Acaso es menos importante?

Un pequeño paso: un modelo de deuda para JIRA

Como todos los años por estas fechas, Atlassian celebra un concurso de desarrollo de plugins para motivar la creación y la innovación de productos en todo su ecosistema (el concurso se llama Codegeist, y cualquiera puede participar). Personalmente me encanta el concurso porque se presentan muchas ideas muy interesantes (algunas un poco locas) que de otra manera seguro que no se llegarían a desarrollar.

El año pasado en excentia ya participamos con una de esas ideas locas: representando los issues de JIRA en forma de ciudad en 3D (3D Issues Map for JIRA) y la verdad es que aunque de momento se haya quedado en algo experimental todos los comentarios fueron interesantes, y aprendimos mucho con la experiencia.

Una vez más no podíamos faltar a la cita, así que siendo Atlassian Expert y evangelista de SonarQube, no se me ocurría mejor forma de participar que juntando ambas pasiones. El resultado ha sido construir un plugin para introducir el concepto de deuda en JIRA de forma similar a la deuda técnica de SonarQube. Y lo he presentado al concurso así que podéis ver todos los detalles en la página de producto del Codegeist (y si queréis votar pues adelante). Ha sido bautizado como:

Debt Tracker and Assessment for JIRA

La base del modelo

Si en SonarQube el núcleo es el análisis estático del código fuente, en JIRA el núcleo es el análisis estático de los issues. La idea es que de la misma forma que se buscan patrones de malas prácticas en las líneas de código se busquen patrones de malas prácticas en los issues de JIRA. Se trata de un motor de reglas.

La evaluación del modelo

Siguiendo el modelo de SQALE y adaptándolo para nuestro contexto tendremos para cada mala práctica un coste de remedio asociado, que será al fin y al cabo la deuda que introduce esa mala práctica. La suma de todos los costes de las malas prácticas detectadas nos dará el valor de la deuda total de un proyecto (o de una issue en particular).

A partir del valor de deuda total y haciendo una estimación de la máxima deuda posible para el proyecto calculamos el ratio de deuda. Este valor del ratio es el que nos permite conocer los intereses que estamos pagando por estar haciendo las cosas mal.

La calificación de deuda

Por último, con este ratio, podemos clasificar el proyecto, y de esa forma otorgarle una calificación de deuda (rating) que nos va a permitir compararlo frente a otros proyectos y conocer de forma sencilla como de sostenible es.

Todo esto es lo que se ha implementado en el plugin, y lo que nos va a permitir introducir un modelo de calidad para evaluar los proyectos de JIRA.

Como en todos los modelos de este estilo, lo más importante son las reglas. Por eso el modelo debe ser configurable (y así se ha desarrollado) para que se puedan activar y desactivar las reglas según el contexto de cada organización y el nivel de exigencia que requiera.

En la primera versión ya se incluyen más de 10 reglas que espero que podamos ir aumentando. Si se te ocurre alguna regla no dudes en decírnoslo, y la incorporamos en la siguiente versión.

En resumen…

El modelo de deuda técnica casi siempre se ha aplicado al código fuente
La deuda puede estar en otras actividades que no sean código (por ejemplo, en la gestión de issues de JIRA)
Aprovechando el concurso Codegeist de Atlassian tenemos un plugin que introduce un nuevo modelo de deuda para JIRA
Podéis probarlo gratis descargándolo del Marketplace
Más información sobre el modelo y el plugin en excentia

¿Qué os parece? ¿Conocíais algo parecido? ¡Espero vuestros comentarios!

Más allá de la deuda técnica. La deuda de la gestión fue publicado inicialmente por Antonio Calero at Antonio Calero el September 04, 2016.

Errores comunes del análisis estático (parte II)

2016-08-01T06:00:00+00:00

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:

Error #6. Las herramientas no se complementan con otros tipos de tests

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.

Error #7. La configuración del IDE es la de por defecto

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.

Error #8. No hay difusión, no hay seguimiento, así que no hay mejora continua

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?).

Error #9. Las quejas sobre los falsos positivos

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.

Error #10. Empezar el análisis estático con demasiadas reglas

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.

Bola extra. Los malvados gestores

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.

En conclusión…

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:

No permitas que las versiones liberadas se salten los umbrales de calidad
Ten en cuenta la opinión de los desarrolladores a la hora de definir las reglas
Intenta utilizar el análisis estático desde el principio, y no solo cuando ya estas a punto de poner en producción el proyecto
Alinea tus normativas de desarrollo con el análisis estático
Utiliza reglas personalizadas para intentar cubrir los casos especiales de tu arquitectura
No te olvides de los tests (unitarios, integración, …), el análisis estático solo ve una parte de los posibles problemas potenciales
Sincroniza la configuración del IDE con el análisis estático, que en todos sitios se mida lo mismo
Difunde, difunde y difunde. Obten feedback y lleva el análisis estático a un ciclo de mejora continua (como todo lo demás)
Los falsos positivos se pueden (y deben) gestionar, que no te frenen con ellos
Keep It Small and Simple (KISS), hay muchas reglas que se pueden activar pero lo mejor es simplificar y empezar con pocas, que puedan resolverse
Busca el apoyo de la gestión/dirección, sin ellos no podrás tener éxito y harás un sobreesfuerzo que no servirá de nada

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.

__________________________________________________

Adaptación del artículo original de Michael Davidek

Errores comunes del análisis estático (parte II) fue publicado inicialmente por Antonio Calero at Antonio Calero el August 01, 2016.

Los gestores (o jefes) deberían programar

2016-07-27T06:00:00+00:00

Que en España no se valoren las habilidades técnicas es algo que todos sabemos, no nos vamos a engañar. Todo el mundo termina la carrera y su primer trabajo suele ser de programador. A partir de ahí la carrera profesional premia el ir abandonando esa habilidad y avanzar en otras para cambiar de puesto: analista, jefe de equipo, arquitecto, … así hasta llegar a ser el director de “algo”. Y claro, pues pasa lo que pasa y nos encontramos con la mayoría de proyectos de software suelen fracasar (en tiempo, en presupuesto, …) y a veces el mercado nos dice que el problema es la falta de buenos programadores.

¿Y no sería mejor que los “jefes” continuarán programando? ¿No sería mejor que al menos una parte de su tiempo siguiese siendo “técnica”?

No paro de verlo en otros sectores donde lo normal es que la gente trabaje en lo que mejor preparado esté (y más experiencia tenga), y no al contrario.

Por ejemplo, el jefe de urgencias de un hospital no está sentando en un despacho viendo como vienen y van los pacientes mientras que otros los atienden. Si bien es cierto que un porcentaje del trabajo es de coordinación y gestión, hay una parte que todavía le obliga a remangarse y atender a pacientes como médico que es. ¿A qué a nadie se le ocurre poner a coordinar un servicio de urgencias a un médico que nunca haya estado en urgencias?

Y cuando vas a un restaurante… ¿a qué a nadie se le ocurre que un jefe de cocina (el chef) no sepa cocinar? Desde luego yo no iría a ese restaurante si fuese así… ¿Y quién tiene el prestigio del restaurante? Prácticamente siempre el chef.

Esto es así en cualquier trabajo que requiera un mínimo de creatividad y de capacidad intelectual para solucionar problemas. Y el software tienen una complejidad que es muy alta, y no es diferente al resto.

¿Pero por qué los gestores deberían dedicar un porcentaje de su tiempo a programar?

Si pierdes el contacto con el código pierdes la conexión con el equipo y en consecuencia con el proyecto. Pero lo peor de todo es que perderás la habilidad que te ha llevado hasta tu puesto. Eso nunca puede ser bueno.

Esta claro que los gestores deben concentrarse en las estrategias, la coordinación, la supervisión, etc. y tiene sentido que dediquen gran parte de tiempo a todo eso. ¿Pero acaso nuestra industria no es tecnológica? Si abandonas la tecnología (el desarrollo de software) la consecuencia en el resto de aspectos puede ser devastadora: malas decisiones, mala planificación o pérdida de liderazgo, entre otras.

Aquí van algunas razones de por qué deberías seguir dedicando algo de tiempo a programar:

Si no programas te equivocarás planificando

Por la propia naturaleza del software todos somos muy malos planificando así que imagina si además te alejas mucho de la codificación y las tareas técnicas.

¿De verdad crees que puedes saber la complejidad de las cosas como para estimar el tiempo de resolverlas? Olvidate. Te vas a equivocar siempre. Estimar no es timar.

Si no programas no sabrás gestionar la deuda técnica

Si no programas, dime cómo vas a saber el impacto que tiene el hacer las cosas de una u otra manera. ¿Cómo vas a ser capaz de priorizar una nueva funcionalidad frente a refactorizar? ¿Cómo vas a debatir con tu equipo si algo que haces hoy puede ser peor o mejor a largo plazo?

Al final, solo te centrarás en estar pendiente de que la planificación se cumpla, algo que por cierto ya sabes que nunca se cumple. Menudo problemón. Acabarás acumulando mucha deuda técnica.

El resultado del código es tu responsabilidad

Cuando eres gestor debes liderar. No se trata de estar tomando todas las decisiones de tu equipo, o aprobándolas todas, se trata de tener el conocimiento y estar en contexto para poder facilitar esas decisiones.

Tu eres el responsable del resultado, y tu habilidad para poder elegir entre las diferentes opciones debe ser acorde a esa responsabilidad.

El equipo te respeta si eres apasionado con el código

Si tu equipo tiene pasión por el desarrollar código entonces tu tienes que dar ejemplo y ser el primero en hacerlo.

Ten en cuenta que los miembros de tu equipo te respetan, y lo harán mucho más si demuestras que lo que ellos hacen (programar) es algo que tú también haces.

Un buen líder no se queda en un pedestal, se baja de él y empuja para sacar el proyecto adelante como cualquier otro miembro del equipo.

Todo va muy rápido y el futuro es importante

Deja de mantener tus habilidades técnicas y te quedarás fuera de juego en menos que canta un gallo. Nunca sabes lo que ocurrirá mañana, así que debes seguir “entrenándote” continuamente para lo que pueda pasar. Y esto es como hablar un idioma, si no se practica, se pierde.

En definitiva…

Es curioso como muchos gestores/jefes/managers hablan constantemente de la mejora continua, de lo necesaria que es, de como ayuda a innovar, a crecer y a tantas cosas, pero siempre olvidándose de la mejora en habilidades técnicas. Es curioso como algunos incluso lo venden como un servicio para tu organización.

Pero cuando rascas un poco, te das cuenta de que siguen usando el mismo Excel que hace 20 años para gestionar, que nadie los saca de su metodología X para planificar, que no adoptan nuevas técnicas de gestión, que siguen con sus diagramas de Gantt que nadie cumple, y tantas y tantas otras cosas.

Y es curiosos como todos ellos les piden (o más bien exigen) a sus equipos que sepan todos los lenguajes de programación actuales, que sepan de las últimas tecnologías disponibles, que de un día para otro hagan magia con su código, que hagan demos de plataformas que no han probado, que cambien de tecnología cada año, y tantas y tantas otras barbaridades.

Así que desde aquí, si me lees, te pido por favor que no permitamos que esto ocurra, que no nos convirtamos en simplemente gestores y nos olvidemos de la tecnología y demos esa parte por “hecha”, porque es la más importante de nuestros proyectos.

Basta ya de gestores trogloditas. Está en nuestras manos cambiarlo.

Los gestores (o jefes) deberían programar fue publicado inicialmente por Antonio Calero at Antonio Calero el July 27, 2016.

Errores comunes del análisis estático (parte I)

2016-07-20T06:00:00+00:00

Error #1. Que los defectos potenciales no paren el build (o saltarse el umbral de calidad)

El análisis estático tiene que ayudarnos a prevenir defectos de forma temprana antes de que ese código llegue a los usuarios. Hay que ser capaz de sacar “tarjeta roja” cuando se detecten los problemas más graves.

Limitar lo que detectan las herramientas a simples “advertencias” es uno de los mayores errores. Hacer eso provoca que los resultados acaben siendo ignorados por los desarrolladores. Si la versión sigue su ciclo independientemente de lo que el análisis estático detecta no hay de que preocuparse y finalmente se ignora.

Así que si sigues una estrategia de publicar el código independientemente de los resultados del análisis estático estás cometiendo un grave error.

Error #2. Las reglas las definen los arquitectos y no se tiene en cuenta a los desarrolladores

Cuando digo arquitectos me refiero a ese perfil que se supone experto pero que ya lleva unos años sin programar, llámalo arquitecto, analista, o de la forma que prefieras.

Para que el análisis estático sea efectivo es esencial que los desarrolladores formen parte del equipo que define las reglas a aplicar. Que los desarrolladores no colaboren y no afecten a las herramientas hará que las rechacen.

Ellos son los que se tienen que preocupar de la calidad de su código todos los días así que tendrás que dejarles que forman parte del juego, o será imposible que sirva de algo.

Error #3. No aplicar los estándares desde el inicio

Una de las peores cosas que pueden ocurrir es de repente tener que resolver problemas que fueron introducidos hace mucho tiempo.

Simple y llanamente porque no se habían configurado las herramientas y el ciclo de desarrollo no seguía los estándares.

Para evitar esto puedes seguir una estrategia “fix the leak” y centrarte solo en el código nuevo o el que modificas, pero también es verdad que si usas el análisis estático desde el principio todo será más fácil.

Error #4. Normativas de desarrollo no alineadas con el análisis estático

¿Tienes normativas de desarrollo? Seguro que sí. ¿Y están mapeadas en tu herramienta de análisis estático? Seguro que no. Este error es también muy grave.

En algún momento alguien dentro de la organización estableció una normativa de desarrollo y la escribió en un documento o wiki. Esa normativa se viene usando durante mucho tiempo y define como trabajar en los proyectos, que nomenclatura usar, la arquitectura de las aplicaciones, buenas prácticas, etc. Si después todo eso no se usa en el análisis estático entonces se estarán usando diferentes varas de medir.

Para evitarlo debes configurar reglas que cubran esa normativa, pero no puedes olvidarte tampoco de actualizar la normativa para incluir toda la información necesaria sobre el análisis estático: herramientas utilizadas, como ejecutarlas, que reglas se usan, que prioridades, como solucionar algunas evidencias comunes, como abordar los proyectos ‘legacy’, …

La relación entre las normativas y el análisis estático debe ser bidireccional y estar siempre actualizada.

Error #5. Las herramientas no usan reglas personalizadas

¿Estás seguro que no hay nada especial en la forma de desarrollar de tu organización? ¿No tienes una arquitectura personalizada que te gustaría supervisar que se cumple?

Aunque muchas reglas son comunes para todos siempre hay algo que es específico y que debes controlar desde el principio. Crea tus propias reglas y personaliza aquellas que te lo permitan.

Y hasta aquí este primer “pack” de errores comunes que deberías evitar en el uso de análisis estático. En la siguiente entrega continuaremos con el resto. ¿Has cometido o estás cometiendo esos errores? ¿Estás de acuerdo con esta primera lista?

__________________________________________________

Adaptación del artículo original de Michael Davidek

Errores comunes del análisis estático (parte I) fue publicado inicialmente por Antonio Calero at Antonio Calero el July 20, 2016.

Nuevo modelo de calidad en SonarQube 5.5

2016-05-10T06:00:00+00:00

¿Y ahora qué? ¿Qué hacemos? ¿Preocupado? En realidad no es para tanto, la misma “filosofía” de SQALE sigue ahí, con la deuda técnica y la calificación de deuda, pero ahora con un enfoque diferente.

Todos los cambios que han venido implementandose desde la versión 5.2 de SonarQube tenían como objetivo llegar a este punto. Las mejoras en los analizadores han permitido empezar a detectar con mayor precisión los defectos potenciales y las vulnerabilidades, así que es el momento de que tengan la importancia que se merecen.

Los tres pilares del nuevo modelo de calidad

¿Por qué un nuevo modelo?

Cuando se analiza la calidad del código con SonarQube uno de los problemas que más me encuentro en las organizaciones es “¿por dónde empezamos? ¿cuáles son las evidencias que hay que resolver primero?”.

Hasta ahora la respuesta siempre iba orientada a resolver las evidencias según su severidad: debes definir el perfil de calidad que quieres aplicar (conjunto de reglas y sus severidades), y después si una evidencia es bloqueante pues está claro que habrá que resolverla primero, ¿verdad?

Esto que parece tan sencillo provoca que se den situaciones un poco más complicadas:

¿Todas las evidencias bloqueantes detectan defectos reales?

La respuesta es no. Según quién crea el perfil de calidad puede darle más importancia a unas cosas que a otras. Por ejemplo, la falta de cobertura en una clase puede ser tratada como una evidencia bloqueante, pero eso no quiere decir que el código de esa clase tenga defectos. Lo mismo para el código duplicado o la complejidad.

¿Y al contrario? ¿Puede haber evidencias de poca severidad que detecten “bugs” o “vulnerabilidades” en producción?

Si, podría haberlas. Conozco muchos casos en los que la regla de inyección de código en las consultas de base de datos no es ni bloqueante ni crítica, por ejemplo. Incluso las reglas que detectan problemas de Null Pointer a veces se configuran sin las severidades máximas.

¿Tener una calificación A de deuda garantiza un código libre de bugs?

La respuesta es no. Y este es quizás el argumento más razonable a la hora de cambiar el modelo. Podíamos encontrarnos proyectos con una deuda muy baja, con la que obtienen una calificación de A, pero con un bug que provocase un ClassCastException en el código más crítico. Esto no tenía ningún sentido y tiene que reflejarse de algún modo.

Así que en mi opinión esto es precisamente lo que estaba ocurriendo y lo que debe aclarar el nuevo modelo:

Era muy difícil diferenciar cuando una evidencia estaba causando un problema de verdad de cuando se trataba simplemente de una normativa por política de desarrollo, o de una buena práctica.

Por eso el nuevo enfoque y separar en tres elementos diferentes las evidencias: bugs, vulnerabilidades y todo lo demás (code smells, hediondez del código o código que huele mal).

Los tres ejes del nuevo modelo

Efectivamente, dado que las evidencias se clasifican ahora en tres grupos, pues el nuevo modelo incluye tres características a las que deben asociarse:

Fiabilidad

Incluye las evidencias de tipo bug. Un bug representa algo que está mal en el código. Si el software aún no se ha roto, se romperá, y probablemente en el peor momento. Todos los bugs tienen que solucionarse sí o sí. ¿Cuando? Ayer.

Seguridad

Incluye las evidencias de tipo vulnerabilidad, que representan una potencial puerta trasera para atacantes. El caso de las evidencias de seguridad es un poco más especial que el resto, porque la casuística es mucho mayor y los matices también. Por ejemplo, no podemos saber si una evidencia está afectando a datos sensibles o no. Por eso aquí se van a encontrar todas las evidencias que tengan una mínima sospecha de afectar a la seguridad. Es responsabilidad de una persona eliminar los falsos positivos y centrarse en resolver los casos reales.

Mantenibilidad

Incluye las evidencias de tipo code smells, que al final son todas esas malas prácticas que a la larga van a provocar que cada vez sea más difícil hacer cambios en el código. En el peor de los casos, todos estos malos olores van a hacer que los desarrolladores se confundan, lo que terminará introduciendo nuevos bugs.

¿Y las nuevas calificaciones?

Pues resulta que para cada una de las características se calcula la calificación de una forma diferente. Si, como lo lees. A mí esto es lo que menos me ha gustado, y pienso que será un problema de cara a transmitirlo a los equipos. Pero es verdad que una vez te mentalizas y sabes que son diferentes pues ya no es tanto problema:

Para la mantenibilidad se mantiene el mismo cálculo que existía en versiones anteriores usando el modelo SQALE y el ratio de deuda técnica. La calificación SQALE ahora es la calificación de mantenibilidad.
Para la fiabilidad y la seguridad se ha introducido una nueva fórmula: la calificación dependerá de la severidad más alta de los bugs o vulnerabilidades detectadas.
- si existe al menos una bloqueante, la calificación será E
- si existe al menos una crítica, la calificación será D
- si existe al menos una mayor, la calificación será C
- si existe al menos una menor, la calificación será B
- si no existe ningún bug o vulnerabilidad, la calificación es A

Se sigue manteniendo el esfuerzo de resolución de la evidencia en todos los casos, sean bugs, vulnerabilidades o code smells, lo que permite conocer una estimación (que puede ser más o menos precisa) de lo que costaría resolver los problemas.

Tiene todo el sentido del mundo y como decía al principio, los bugs y vulnerabilidades ahora tienen más importancia. Ahora tu proyecto puede estar muy bien y tener una calificación de A en mantenibilidad, pero si se han detectado bugs en el código, esto se verá reflejado.

En resumen…

Las evidencias (issues) se categorizan ahora en tres tipos: bugs, vulnerabilidades y code smells.
Desaparecen las características de calidad del modelo SQALE, que se sustituyen por fiabilidad, seguridad y mantenibilidad, que se corresponden con el tipo de evidencia que incluyen.
La calificación de mantenibilidad es ahora lo que antes era la calificación de deuda, calculado en base al ratio de deuda.
La calificación de fiabilidad y seguridad se calculan teniendo en cuenta la severidad más alta de las evidencias detectadas

¿Qué te parece? ¿Conocías el nuevo modelo o te has llevado una sorpresa? ¿Crees que este nuevo enfoque ayudará a mejorar aún más tu código?

Nuevo modelo de calidad en SonarQube 5.5 fue publicado inicialmente por Antonio Calero at Antonio Calero el May 10, 2016.

Aprovecha las herramientas de análisis estático

2016-03-07T06:00:00+00:00

El libro de Kevlin Henney tiene la suerte de contar con contribuciones de grandes expertos, incluyendo a Uncle Bob, por ejemplo. Aunque el libro es de 2010 sigue siendo una de las mejores referencias para las buenas prácticas en el desarrollo de software

Hoy quería centrarme en la número 79 y recordar que las herramientas están ahí para ayudarte, no estas solo y no puedes saberlo todo.

Remontándonos a la época donde el lenguaje C era el nuevo lenguaje de moda, los recursos de cpu y de almacenamiento eran algo de lujo. Los primeros compiladores estaban diseñados con esto en mente, para que se redujese el número de veces que se parseaba el código. Esto hacía que el compilador solo comprobase un subconjunto de todos los bugs posibles que se podían detectar en tiempo de compilación.

Para compensar esta situación, Stephen Johnson escribió una herramienta que se llamaba lint (esto ya si que os sonará de algo, verdad… ¿de dónde pensabáis que venía pylint, jslint, sonarlint, …?). Esta herramienta implementaba parte del análisis estático que había sido eliminada de su hermano mayor -el compilador de C-. Sin embargo, en aquella época, las herramientas de análisis estático se ganaron la reputación de detectar demasiados falsos positivos y de únicamente centrarse en convenciones de nombres que no siempre eran necesarias.

Pero hoy en día el abanico actual de lenguajes, compiladores y analizadores estáticos es muy diferente. La memoria y la CPU no son el factor determinante, por lo que los compiladores deberían poder incluir muchas más comprobaciones. Casi todos los lenguajes disponen de una herramienta que comprueba evidencias de estilo, buenas prácticas y a veces hasta errores que son muy difícil de detectar, como por ejemplo referencias a nulo. La mayoría de herramientas, como splint para C o pylint para Python, son configurables, lo que significa que puedes elegir que errores o advertencias quieres detectar a través de ficheros de configuración, desde la línea de comandos, o en tu entorno de desarrollo favorito.

Y si todo lo demás no es suficiente, y al final te encuentras solo en la búsqueda de errores o tienes una normativa de desarrollo que tu compilador o tu herramienta favorita no controla, pues siempre puedes pensar en construir tu propio analizador estático. No es tan difícil. La mayoría de lenguajes ya exponen su arbol sintáctico (AST) y sus herramientas de compilación como librerías estándar. Puede parecer una locura pero no lo es. Utilizando reglas XPath o kits de desarrollo como SSLR de SonarQube puedes construir tu propio conjunto de buenas prácticas y utilizarlos en diferentes herramientas para ayudarte.

Así que no seas insconciente, benefíciate de todas las ventajas de las herramientas de análisis estático porque no estas solo ahí fuera.

__________________________________________________

Contribución original de Sarah Mount para el libro 97 cosas que todo programador debería saber

Aprovecha las herramientas de análisis estático fue publicado inicialmente por Antonio Calero at Antonio Calero el March 07, 2016.

Los principios de la inspección continua

2016-03-03T06:00:00+00:00

Aprovechemos para recordar uno a uno los diez principios de la inspección continua:

1 Todas las partes interesadas en el proceso de desarrollo -y no sólo los desarrolladores o administradores- deben tener acceso inmediato a datos significativos sobre la calidad del software.

2 La gestión de la calidad del software debe ser preocupación de todos, desde el inicio del desarrollo, pero finalmente es responsabilidad de todo el equipo de desarrollo.

3 La calidad de software debe ser parte del proceso de desarrollo, lo que significa que las normas de calidad son uno de los requisitos imprescindibles para poder declarar que un software está completo.

4 Los requisitos de calidad de software deben ser objetivos y no permitir una aprobación/desaprobación de pase subjetivo (decisión errónea).

5 En la medida de lo posible, los requisitos de calidad de software deben ser comunes a todos los productos de software, independientemente de sus características específicas.

6Los datos de calidad de software deben estar al día, es decir, medidos en la última versión del código.

7Los productos de software deben ser inspeccionados de forma continua, para que se encuentren errores rápidamente, cuando son fáciles de corregir. Los desarrolladores deben ser capaces de detectar nuevos defectos de calidad tan pronto como se introducen, es decir, dentro de su herramienta de desarrollo mientras escriben código, similar a los correctores ortográficos.

8 Ya sea de manera proactiva o reactiva, los interesados deberán recibir una alerta cuando se introducen nuevos defectos de calidad, ya sea mediante el envío de correo electrónico, rompiendo la compilación o por otros métodos. La inyección de nuevas evidencias debe ser continua, permitiendo a los equipos la tomar decisiones rápidas sobre la calidad.

9 Los datos de calidad de software deben estar disponibles tanto en valores absolutos (en todo el código) y diferencial (nuevo código solamente) para que el equipo de desarrollo pueda estar en control total del flujo de entrada de evidencias.

10 Todas las nuevas evidencias y las evidencias más críticas existentes deben tener asignadas un camino claro con un calendario para su resolución.

El paradigma de inspección continua es muy eficaz, y se ha demostrado que funciona en el mundo real gracias a herramientas como SonarQube, que se han convertido en estándar de facto para implementar el paradigma.

Por mi experiencia puedo asegurar que el modelo de inspección continua se utiliza con éxito para gestionar la calidad del software interno en proyectos de todos los tamaños. En todos los casos, la inspección continua ha ayudado a mejorar significativamente la calidad y la estabilidad del software, que por lo general, suponen un ahorro muy importante que de otro modo se gastaría en el análisis de causa raíz y la gestión de crisis.

Los principios de la inspección continua fue publicado inicialmente por Antonio Calero at Antonio Calero el March 03, 2016.

Los retos de la gestión de la calidad del código

2016-03-01T06:00:00+00:00

Por su naturaleza, las auditorías puntuales pueden provocar perturbaciones en el ciclo de desarrollo, ya que dan lugar a cambios en el software “completado”. En el mejor de los casos, este método de control de calidad ocasionará retrasos y repetir trabajo. En el peor de los casos, conduce a la liberación de software de mala calidad. En cualquier caso, el enfoque tradicional fomenta la percepción de que la construcción de software de calidad es demasiado complejo y caro.

Se necesita hacer hincapié en la calidad en todo el ciclo de desarrollo, con bucles de retroalimentación más cortos, para asegurar una rápida resolución de los problemas internos de calidad; en definitiva, un modelo que se base en la calidad desde el principio, en lugar de considerarse después de haber cometido los errores, un modelo proactivo en lugar de reactivo.

Las auditorías puntuales se ejecutan, por diseño, a intervalos específicos y no de forma continua. Este enfoque de la gestión de la calidad del código tiene cuatro grandes tipos de deficiencias o retos a superar:

Demasiado poco, demasiado tarde

Las auditorías puntuales identifican dos tipos de mejoras: cambios cosméticos y cambios estructurales.

Mientras que los cambios cosméticos requieren modificaciones menores, los cambios estructurales pueden incluir importantes reingenierías de software.

Si bien pueden ser necesarios estos cambios, los planes de acción resultantes de las auditorías puntuales se definen demasiado tarde en el proceso; de manera que o la fecha de lanzamiento de una versión software necesita ser ampliada, para incluir esta reingeniería del software, o peor todavía, el software llegará a producción con un nivel bajo de calidad, y por lo tanto con baja mantenibilidad y capacidad de adaptación cuando surjan nuevos requisitos.

El rechazo de los desarrolladores

Los desarrolladores tienden a rechazar los planes de acción generados a partir de auditorías puntuales, ya que:

Se generan fuera del equipo, y lo normal es que sean vistos como una nueva restricción en el trabajo diario
Son subjetivos; evidencias que se suelen basan en el juicio de los auditores, más que en medidas objetivas
Se pierde el contexto e historia de la información, y por lo tanto se consideran irrelevantes
Están invalidados por los cambios constantes, el código está vivo y evoluciona tan rápido que la auditoría se hizo sobre código antiguo, provocando que esos datos rápidamente queden obsoletos
No involucra a los desarrolladores y otras partes interesadas en el proceso de revisión y auditoría
Intervienen demasiado tarde en el proceso; para cuando una característica es auditada, los desarrolladores necesitan “reaprender” el código para hacer frente a una evidencia

Falta de propiedad de los procesos

Hay una clara falta de apropiación del proceso de calidad dentro de la organización.

Los auditores no pueden poseer el proceso, debido a que ni son propietarios del código ni tienen control sobre la resolución de los problemas. Del mismo modo, el modelo de command-and-control de los auditores evita que el equipo de desarrollo sea dueño del proceso, ya que no está involucrado en las auditorias o revisiones.

Así que, jaque mate, al final tienes dos grupos inconexos que son ambos responsables de calidad, mientras que en realidad ninguno de ellos es responsable.

Heterogeneidad de los requerimientos

Los enfoques tradicionales miden el software en valores absolutos, como por ejemplo el número total de problemas encontrados con un umbral de calidad específico. Esto fuerza a los evaluadores a medir cada aplicación contra diferentes requisitos, en función de su origen.

Por ejemplo, ¿un proyecto legacy se hace con el mismo estándar de alta calidad que se espera de un proyecto nuevo? ¿el desarrollo interno podría ser juzgado de manera diferente que el código subcontratado? Todo esto se debe al hecho de que se debe autorizar el software para pasarlo a producción, y para ello hay que tener requisitos que definan los criterios.

Es muy poco práctico que cada proyecto deba alcanzar los mismos valores absolutos para los umbrales de calidad antes de su puesta en producción. El uso de este tipo de valores absolutos implica que sea casi imposible de conseguir requisitos comunes para todas las aplicaciones, y por lo tanto difícil de adoptar buenas prácticas en todos los ámbitos.

La inspección continua al rescate

Todos esos retos clave en la gestión de la calidad del código se combinan, a menudo, para crear una percepción de que “la creación de software de calidad es cara”.

Para ser eficaz bajo el enfoque tradicional la gestión de calidad llega demasiado tarde en el proceso y altera el ciclo de desarrollo, causando retrasos inesperados, repitiendo trabajo no planificado o perdiendo características funcionales. Para agravar el problema, los equipos de desarrollo frenan o rechazan las evaluaciones de calidad, las ven como algo que reduce la productividad y la colaboración del equipo.

Además, las empresas no obtienen mejoras a largo plazo en la calidad general, debido a que el enfoque tradicional no tiene en cuenta la necesidad de educar a los desarrolladores. Como resultado, los mismos o similares problemas de calidad surgen repetidamente durante el ciclo de vida del proyecto.

La inspección continua es un paradigma en la gestión de la calidad del código diseñado para hacer que la calidad del código forme parte integral del ciclo de vida de desarrollo de software. Es un proceso holístico, plenamente efectivo, que aumenta tanto la calidad del software interno de un proyecto como la visibilidad de la calidad del software para todos los interesados.

La clave del concepto de la inspección continua es detectar problemas a tiempo, cuando resolverlos sigue siendo barato y fácil. Bajo este modelo, las auditorías de código automatizadas se realizan sobre una base diaria y se colocan a disposición de la organización.

Los miembros del equipo son alertados tan pronto como se encuentren nuevas evidencias para que puedan abordarse lo antes posible, mientras que el código está todavía fresco en la mente de los desarrolladores. La puntualidad de estas alertas tiene el beneficio añadido de que educa a los programadores respecto a los malos hábitos y los conduce a codificar según los buenos.

La inspección continua goza de mayor aprobación entre los equipos de desarrollo debido a su naturaleza de colaboración, que conduce a un sentimiento de verdadera propiedad del código, y ayuda a los equipos a ofrecer un mejor software. Con sus pequeños ciclos, con identificaciones rápidas y tratamiento de estas evidencias, se ha demostrado que aumentan la eficiencia de los equipos de desarrollo y aumentar la longevidad de las aplicaciones, mediante el fomento del desarrollo de código de mayor calidad.

La inspección continua de código es un elemento clave de apoyo para los jardineros del software y es una de las mejores formas de mantener “sano” y “limpio” nuestro código.

¿Y tú? ¿Llevas a cabo un proceso de inspección continua?

Los retos de la gestión de la calidad del código fue publicado inicialmente por Antonio Calero at Antonio Calero el March 01, 2016.

Jardineros del Software

2016-02-25T06:00:00+00:00

No eres un ingeniero de software. No construyes rascacielos. No construyes puentes. Cultivas jardines. Eres un jardinero del software. Chris Aitchison

¿Conocías la metáfora y su manifiesto? Recientemente me he cruzado con ella a través de twitter (gracias a Patroklos) y la verdad es que la comparto completamente y por eso me decidí a firmar el manifiesto. Tiene ciertas similitudes con la artesanía del software (Manifesto for Software Craftsmanship) pero añadiendo el componente de ser algo vivo y en constante cambio.

Así que me he animado y he aprovechado para traducir el manifiesto y así compartirlo con todos vosotros. Os dejo un enlace al final por si alguien también quiere firmarlo. Espero vuestros comentarios :)

Como jardineros del software creemos e impulsamos los siguientes principios:

1 Tratamos a los sistemas de software como jardines y el código como sus flores y plantas. Aunque no estamos en desacuerdo con entender el software como un artefacto artesanal, creemos que el software es un “ser” que vive y respira, no es solo un objeto, creado utilizando los mejores materiales.

2 Estamos constantemente tutelando a jovenes desarrolladores y compartimos nuestro conocimiento en cada oportunidad. Los desarrolladores jóvenes son como las plantas que necesitan regarse para llegar a florecer. Somos el agua, el sol, la tierra, el fertilizante para cada (joven) profesional del software.

3 El desarrollo de software es mucho más que picar código. Conocemos las prácticas y las aplicamos eficazmente. Hacemos uso de las herramientas más productivas y nuestro conjunto de habilidades incluye tanto habilidades técnicas como transversales. También entendemos que nuestra actitud general es lo que nos define como jardineros del software.

4 Nos preocupamos por nuestro código y esta preocupación la mostramos continuamente, día tras día, en cada momento en cada línea de código que escribimos.

5 No solo somos capaces de responder al cambio sino que estamos preparados para la reformulación constante -interna y externa- del entorno.

6 Tratamos a los clientes como las personas que pasean por nuestro jardín y huelen el ároma de nuestras plantas y flores. Dicho esto, nos comprometemos con ellos desde el primer día, para asegurarnos de que se cumplan todas sus necesidades, requerimientos y expectativas.

Firma el manifiesto

Jardineros del Software fue publicado inicialmente por Antonio Calero at Antonio Calero el February 25, 2016.

¿Por qué tenemos que visualizar el software?

2015-03-02T06:00:00+00:00

El informe nos ofrece cifras de los proyectos de software, de su éxito, de su fracaso, o de proyectos cuestionados (es decir, que han costado más de lo inicialmente previsto, económica o temporalmente, o que no alcanzan los requisitos y se quedan a mitad).

La tendencia dice que vamos a peor. Afortunadamente han mejorado los proyectos con éxito pero aún así sigue siendo insuficiente.

¿Y todo esto por qué?

Porque el software es intangible, físicamente no tiene forma ni volumen.

Entender el software requiere un gran esfuerzo

Porque el tamaño del software hace que sea difícil de leer y estructurar.
Porque la complejidad es muy alta y con el software intentamos resolver problemas difíciles.
Porque el software evoluciona… Cambia muy rápido, se adapta, y lo que entendíamos hoy mañana ya no sirve…

Muy bien, y entonces ¿qué podemos hacer para entender el software?

TENEMOS QUE VERLO

Tenemos que ser capaces de entender el software “viéndolo”. Parecerá un ejemplo "cutre" pero ¿cómo ayudó a Neo en The Matrix el llegar a “ver el código”?

Ver el código le permitió ENTENDER, y así resolver los problemas más rápidamente.

VER ES ENTENDER.

Hagamos un poco de historia y repasemos grandes acontecimientos... Londres, 1854. Epidemia de cólera.

Dos tendencias, los contagionistas, pensaban que se transmitía por el contacto, y la teoria miasmática, transmitido por el viento, por los miasmas: vapores tóxicos emitidos por descomposición que transportaban de un lugar a otro el cólera.

En medio de todo eso llegó John Snow (si, si, y no tiene nada que ver con Juego de Tronos), y convencido de que debía haber otras causas, comenzó a realizar un estudio de cada caso, así que cogió su libretita y fue a visitar a todos los enfermos, y fue apuntando las zonas donde vivían y donde se desplazaban.

Hizo un mapa y detectó que se concentraba la mayor parte de los fallecidos cerca de un pozo de agua.

Con ese mapa resolvió uno de los mayores problemas de la época, y se convirtió así en el padre de la epidemiología moderna.

Una sola imagen bastó para detectar donde estaba el problema:

Mapa de casos de cólera de John Snow

Una imagen vale más que mil palabras

Pero cuidado, que algunos se lo toman al pie de la letra y se construyen UMLs o Gantts pensando que ayuda a ver mejor el estado y resulta que en esas “imágenes” hay más de mil palabras. No vale poner palabras y hacer lineas de un lado a otro ;-)

Así no, estas imágenes no siempre valen para ayudar

Así que aquí es donde viene la visualización al rescate:

Y todo esto tiene sentido, ¿no conocéis los principios de Gestalt? ¿Proximidad, cierre, conectividad, semejanza? Nuestro cerebro procesa la información teniendo en cuenta toda esa información y nos permite extraer conclusiones simplemente al verlo.

¿Cuántos grupos ves en cada imagen?

La mente configura a través de ciertas leyes los elementos que llegan a ella a través de los canales sensoriales (percepción) o de la memoria (pensamiento, inteligencia y resolución de problemas). La forma, orientación, longitud de línea, curvatura, grosor de línea, marcas, tamaño, ... nos ayudarán a detectar visualmente elementos diferenciadores en las imágenes.

Más del 70% de los estímulos externos que percibe el organismo provienen de la función visual.

Muy bien, ¿pero entonces? ¿qué visualizamos del software para entenderlo? Pues evidentemente el código fuente. ¿Os suena el coloreado de sintaxis? ¡guau! Una aplicación de los principios de Gestalt sobre el código ;-)

¿Y qué más podríamos visualizar? Métricas, muchas métricas, hoy día ya tenemos métricas para dar y tomar…

Visualización de estructura del código

Pero todo esto es complejo y tenemos que abstraernos un poco:

podemos ver la estructura, con diagramas de paquetes o clases, por ejemplo, esto ayuda un poco a entender la arquitectura de un proyecto, ¿verdad?

podemos usar las vistas polimétricas… Cada nodo es un elemento software, y cada línea es una relación entre esos dos elementos. El tamaño de cada nodo se puede representar con diferentes métricas (alto y ancho) según lo que nos interese ver. El color puede ser otra métrica. Lo interesante es que podemos ver esas jerarquías o relaciones y también evaluar tamaño y complejidad.

Vistas polimétricas

podemos usar los mapas de distribución. Cada rectangulo pequeño es una clase, que esta agrupados en paquetes (rectangulos grandes), y el color de cada clase viene determinado por el concepto predominante (o funcionalidad principal de las clases, o lo que me interese conocer).

podemos usar mapas de paquetes… Muestra quien “posee” cada clase y sus jerarquías.

¿y quién no ha usado alguna vez un treemap (o mapa de árbol)? El resultado final es una visualización muy intuitiva y dinámica de un plano dividido en áreas proporcionales a los datos que representan, jerarquizado por tamaños y código de color, y optimizando el espacio.

Forma circular

otra forma es representar nuestros elementos de software en forma circular, y dibujando líneas entre ellos con las dependencias (rojo=invocado, verde=invocador). En el ejemplo las unidades 16 y 18 son las que más veces se invocan pero es difícil saber desde donde. Demasiado ruido en la imagen. Aunque esta forma de representación evoluciono para intentar ser más limpia.

incluso tenemos diagramas de arco para detectar código duplicado… complicado pero visual…

¿Pero es todo esto suficiente?

Un día comiendo en restaurante japonés, con grandes amigos, Paco, Carlos y Hugo la conversación fue volviéndose cada vez más "friki" (de cuatro informáticos no puede salir nada bueno). Uno de los problemas que teníamos en excentia era como poder trasladar la complejidad del mundo del software a todo el mundo, sin necesidad de entender métricas ni ver números ni ser expertos en calidad. Hacer tangible lo intangible.

Y recuerdo perfectamente ese momento, en el que Carlos estaba de reformas en su casa del pueblo hablándonos de las "chapuzas" de los obreros, cuando nos dimos cuenta de que quizás lo más visual sería representar el software como una ciudad, como casas, como edificios. Y es ahí donde surgió la idea de City Model y empezamos a crear la metáfora de la ciudad para representar el código, el nacimiento de un producto que hoy día puedes descargar directamente en cualquier instancia de SonarQube, pero todos estos detalles ya los dejo para el siguiente artículo ;-)

¿Por qué tenemos que visualizar el software? fue publicado inicialmente por Antonio Calero at Antonio Calero el March 02, 2015.

¿Qué es SonarQube?

2014-11-28T08:00:00+00:00

Durante los dos días que pase en Madrid en las jornadas de calidad de producto software mucha gente hablaba de SonarQube, de cómo lo utilizaban, lo comparaban con otras herramientas, se cuestionaban su coste, ... pero es sorprendente como mucha gente no sabe en realidad qué es SonarQube y uno se da cuenta de eso cuando te encuentras con comentarios como que “solo sirve para Java”, que "solo integra herramientas como PMD, Findbugs, Checkstyle", "que necesita Maven para hacer análisis", que "no se integra con IDEs", ...

Así que, siguiendo los pasos de Patroklos con su artículo original, he decidido trasladar sus principios aquí, he añadido algunos más, y espero que sirva para aclarar todos esos conceptos.

Para eso vamos a definir qué es SonarQube definiendo lo que NO es:

SonarQube NO es una herramienta de construcción. Hay muchas herramientas disponibles ahí fuera que ya hacen las cosas tremendamente bien, como pueden ser: Maven, Ant, Gradle, etc. SonarQube espera que antes de analizar un proyecto, el proyecto haya sido compilado y construido con tu herramienta favorita. SonarQube no es intrusivo en el proceso de desarrollo, no tienes que cambiar tu forma de construir tus proyectos.

SonarQube NO es (solamente) una herramienta de análisis estático de código. SonarQube no sustituye a Findbugs o a CPPCheck o cualquier otra herramienta similar. Todo lo contrario, SonarQube, además de ofrecer su propio motor de análisis estático de código, permite integrarlo con todas esas herramientas externas. La consecuencia es que puedes obtener de forma homogénea, y agrupada todas las evidencias detectadas por esa gran variedad de herramientas de análisis estático y dinámico. Todo integrado en un único cuadro de mandos.

SonarQube NO es una herramienta de cobertura de código, claramente no lo es. Igual que antes, se integra con las herramientas más populares de cobertura de código como JaCoCo, Cobertura, PHPUnit, NCover, … pero no calcula la cobertura de código de forma propia. Simplemente lee los informes de pruebas pre-generados y los muestra en un cuadro de mando más usable y conveniente. Una vez más, SonarQube, no es intrusivo en el proceso de desarrollo, si ya estás haciendo pruebas unitarias, basta con que le digas donde están los resultados.

SonarQube NO es una herramienta de formateo de código. Nunca modificará una sola línea de código de tu proyecto. Lo que si que puede hacer es revisar el estilo para ver si cumple con ciertas convenciones de código, puedes utilizar tus reglas de Checkstyle, CPPCheck, ScalaStyle, … o implementar las tuyas propias.

SonarQube NO es solo otra herramienta de revisión manual de código. Por supuesto que ofrece un mecanismo que facilita la revisión de código, pero no solo eso. Esta muy ligado al mecanismo de detección de evidencias de incumplimiento de buenas prácticas, por lo que cada revisión de código puede asociarse fácilmente a la parte concreta del código problemático y al desarrollador que lo ha escrito.

SonarQube NO solo gestiona la calidad del código Java. Esa época se acabo hace mucho tiempo. Por defecto, en su versión “community” puedes analizar código en los lenguajes más populares de hoy en día: Java, C#.NET, JavaScript, PHP, … y si necesitas más, existen otros plugins opensource y comerciales para cubrir hasta más de 20 lenguajes de desarrollo. No dejes que te engañen, SonarQube ya es independiente de la tecnología de desarrollo y no está ligado a Java.

SonarQube NO necesita Maven para analizar tu proyecto. Hace ya mucho tiempo que se desacopló de Maven, aunque por supuesto, puedes seguir usándolo. La realidad es que SonarQube dispone de un analizador autónomo (sonar-runner) que se encarga de llevar a cabo todo el análisis independientemente de tu tecnología y de tus herramientas de construcción. SonarQube nunca te va a pedir que cambies absolutamente nada en tu proceso de desarrollo, simplemente debes añadir un paso más para la inspección de código y empezar a medir.

SonarQube NO solo usa reglas para validar la calidad. Además de las reglas, calcula muchas métricas referentes al código fuente (complejidad, código duplicado, deuda técnica, ...) y permite extender la funcionalidad para crear tus propias métricas y tus propios modelos de calidad.

SonarQube NO solo permite ver la calidad desde la aplicación web. Por supuesto que cualquiera que quiera conocer todos los detalles de la calidad de su producto puede acceder vía web a la herramienta, ¿pero qué pasa con los desarrolladores? Los desarrolladores siempre están trabajando con su IDE favorito y no les gusta cambiar. SonarQube provee de extensiones para los principales IDEs (Eclipse, IntelliJ, VisualStudio) de forma que los desarrolladores no tengan que salir de su entorno favorito para saber si están haciendo las cosas con los niveles de calidad adecuados. Es más, los desarrolladores pueden incluso ejecutar análisis locales para así revisar las evidencias antes de subir el código al control de versiones.

Así que después de todo esto, ¿qué podemos decir que es SonarQube?

SonarQube es una plataforma de gestión de la calidad del código que permite a los equipos de desarrollo gestionar, hacer seguimiento y mejorar la calidad de su código fuente.

Es una herramienta que mantiene datos históricos de una gran variedad de métricas y proporciona tendencias de los indicadores de referencia para no cometer los pecados capitales del desarrollo de software.

Espero que con este artículo queden resueltas muchas de las dudas que han surgido durante las jornadas de calidad de producto software... y si todavía quedan algunas, por favor, planteadlas que seguro que podemos encontrar respuesta entre todos :-)

__________________________________________________

Artículo basado en el original de Patroklos Papapetrou

¿Qué es SonarQube? fue publicado inicialmente por Antonio Calero at Antonio Calero el November 28, 2014.

Imagina la vida como un juego...

2014-09-01T06:00:00+00:00

Pronto entenderás que el trabajo es una bola de goma. Si la sueltas, rebotará en el suelo y volverá a subir. Pero las otras cuatro bolas - familia, salud, amigos y espíritu - están hechas de cristal. Si se cae alguna de ellas, se fracturarán de forma irrevocable, con pequeños agujeros, picados, o incluso roturas más grandes. Nunca volverán a ser iguales una vez se hayan caído.

Tienes que entender eso y luchar y esforzarte para que no ocurra.

Bryan Dyson - CEO de Coca-Cola

Me cruce con este discurso el otro día y gustó mucho porque es una filosofía que a mucha gente le cuesta entender...

Trabaja eficientemente durante las horas de oficina e intenta salir del trabajo a la hora que corresponda. Tienes que proporcionar tiempo a tu familia, tus amigos y a descansar correctamente cuerpo y mente. Si no es así poco a poco se irán fracturando y no podrás recuperar ese tiempo perdido jamás.

El valor solo tiene valor si su valor es valorado.

Imagina la vida como un juego... fue publicado inicialmente por Antonio Calero at Antonio Calero el September 01, 2014.

Jugando podemos conseguir un mundo mejor

2014-02-19T07:49:00+00:00

Estaba el otro día preparando una presentación para un evento de calidad de software (expoQA) y me encontré esta maravillosa charla de Jane McGonigal en un TED que me inspiró muchísimo.

Para quién no la conozca, Jane McGonigal es una diseñadora de videojuegos que aboga por el uso de la tecnología para canalizar actitudes y colaboraciones en el mundo real. Jane ha escrito un libro muy interesante: "Reality is Broken", por qué los videojuegos nos hacen mejores y cómo nos pueden ayudar a cambiar el mundo.

Como fanático de los videojuegos me encuentro en una lucha constante para que los demás entiendan que los videojuegos, en la mayoría de casos, son positivos. Evidentemente, como el resto de las cosas de la vida, todo en exceso es malo, así que no entremos en esa discusión.

Me quedo con algunos datos interesantes que dan que pensar:

El joven promedio hoy de un país con marcada cultura de juegos habrá pasado 10.000 horas jugando online a los 21 años. Para los chicos de EE.UU. 10.080 horas es el tiempo exacto que pasarán en la escuela desde quinto grado hasta la graduación de secundaria si tienen asistencia perfecta.

Nadie quiere cambiar el modo de vida sólo porque es bueno para el mundo, o porque se supone que debemos hacerlo. Pero si uno los sumerge en una aventura épica y les dice: "Nos quedamos sin petróleo". Esta es una historia asombrosa y una aventura para que te sumes. Desafiarte a ti mismo a sobrevivir en ese mundo. Muchos jugadores han conservado los hábitos aprendidos en este juego.

¿Impresionante, verdad? Pasamos casi el mismo tiempo jugando que en el colegio... ¡Canalicemos entonces todo eso para conseguir mejorar la realidad!

Aquí os dejo la fantástica charla:

Jugando podemos conseguir un mundo mejor fue publicado inicialmente por Antonio Calero at Antonio Calero el February 19, 2014.

¿Qué es la calidad de software?

2014-01-22T08:32:00+00:00

No hay mejor manera de estrenar el blog que la de ponernos en contexto respecto a lo que entendemos con "calidad de software".

Según el Diccionario de la Real Academia de la Lengua Española:

calidad es la propiedad o conjunto de propiedades inherentes a algo, que permiten juzgar su valor. Esta tela es de buena calidad.

Esto, para casi todas las cosas generales de la vida, lo entiende todo el mundo, pero ¿y en el mundo del software?

Por ejemplo, si hablamos de la calidad de un coche o automóvil, todo el mundo tiene muy claro cuales son las propiedades que tienen que conocer para juzgar si es mejor o peor que otro: la potencia, la seguridad, la capacidad del maletero, el consumo de gasolina, ...

Si hablamos de la calidad de un teléfono móvil o de una tablet , también todo el mundo tiene claro cuales son esas propiedades o características a evaluar: el tamaño, el sistema operativo, la capacidad de almacenamiento, el peso, el procesador, ...

Sin embargo a veces puede ocurrir que no todos tengamos claro como evaluar esas propiedades de las cosas, en cuyo caso siempre se suele buscar a alguien (el primo al que le encantan los coches, el familiar que sabe de tecnología, el vecino informático ...) que es quién ayuda a determinar esos valores para juzgar y tomar decisiones.

Todo esto que se aplica para tantas cosas en el día a día parece que con el software se nos olvida.

Pues bien, la calidad de software no es más que esa propiedad o conjunto de propiedades que nos permiten juzgar el valor de un determinado sistema informático, aplicación, programa o como cada uno lo llame.

Y esto no es nada nuevo, ya hace mucho tiempo que se conocen cuales son estas propiedades y se han estado utilizando para evaluar la calidad del software desde sus inicios.

En el año 1977 se definió el triángulo de calidad de McCall (revisión de producto, operaciones y transición del producto), o en el año 1978, se definió el árbol de características de Boehm, que definía varios niveles en los que se iban desglosando características del software. Posteriormente en 1992 basándose en el trabajo anterior se definió el modelo FURPS (utilizado por Rational, ahora IBM), y así muchos otros modelos a lo largo de la historia.

Hoy día, el modelo de características que más utilizamos es el que define la norma internacional ISO-25000 (que une las normas ISO-9126 y la ISO-14598 que definían los atributos de calidad del software y su evaluación).

Según la norma ISO-25000, la calidad del software viene determinada por las siguientes ocho características o propiedades:

Funcionalidad: grado en que un producto o sistema provee las funciones que cumplen las necesidades implícitas y explícitas cuando se usa bajo condiciones específicas
Rendimiento: rendimiento relativo a la cantidad de recursos utilizados bajo condiciones indicadas
Compatibilidad: grado en que un producto, sistema o componente se puede intercambiar información con otros productos, sistemas o componentes y/o realizar sus funciones requeridas, mientras comparten el mismo hardware o entorno de software
Facilidad de uso (usabilidad): grado en que un producto o sistema puede ser utilizado por usuarios específicos para alcanzar las metas especificadas con efectividad, eficiencia y satisfacción en un contexto de uso específico
Fiabilidad: grado en que un sistema, producto o componente realiza funciones que se especifican en determinadas condiciones durante un período determinado de tiempo
Seguridad: grado en que un producto o sistema protege la información y los datos para que las personas u otros productos o sistemas tengan el grado de acceso a los datos adecuado a sus tipos y niveles de autorización
Mantenibilidad: grado de eficacia y eficiencia con que un producto o sistema puede ser modificado por los responsables previstos
Portabilidad: grado de eficacia y eficiencia con que un sistema, producto o componente puede ser transferido de un hardware, software del entorno de uso a otro

Estas características se dividen a su vez en diferentes subcaracterísticas más específicas que permiten indagar más profundamente en qué aspectos de calidad hay que evaluar en cada caso.

Además, la norma también específica que estas características se han de evaluar en diferentes escenarios ya que en función de esos escenarios la calidad que se está evaluando es diferente: calidad interna, calidad externa y calidad en uso . Pero eso lo dejamos para siguientes post ;-)

Y tú, ¿qué definición de calidad de software utilizas? ¿qué características consideras que hay que evaluar para determinar si un software tiene más calidad que otro?

¿Qué es la calidad de software? fue publicado inicialmente por Antonio Calero at Antonio Calero el January 22, 2014.