8 criterios de elección de una herramienta de análisis de código (1/2)

Siempre me sorprenden los comparativos de herramientas de análisis de la calidad de código que pretenden definir los criterios para dicha elección, cuando la única respuesta exacta a esta cuestión es que ‘esto depende’.

Si deseas comprar un coche, por supuesto efectuarás tu elección según unos criterios que van a depender del uso futuro del vehículo. Un cupé descapotable o un coche deportivo son unos objetos por cierto muy atractivos pero poco prácticos si se trata de transportar una familia numerosa, ir a la playa con tu plancha de surf o ayudar a mudar tu vieja tía.

Lo mismo ocurre con la selección de una plataforma de análisis de la calidad de las aplicaciones.


Este post no tiene por objeto definir los ocho más importantes criterios de elección de un software de análisis de código, si no los cuatro criterios que se encuentran lo más y (en el próximo post) tres otros criterios que no encuentro tanto. Sí, lo sé, la cuenta no es buena. De hecho, el último criterio, el costo del software, será tratado por separado.

Numero de tecnologías analizadas

Casi siempre es el primer criterio de selección. No entiendo por qué una herramienta capaz de cubrir 20 lenguajes sería superior al que analiza solamente 5, si los dos pueden analizar el código de tus aplicaciones. Hoy en día, el 50% de las aplicaciones son de tipo J2EE y un otro 25% de tipo Legacy (Cobol Mainframe / SAP). Varía más o menos dependiendo del país: algunos continentes son más Microsoft que otros, con una tasa mayor de C++ y de .Net. También varía según los sectores: bancos y compañías de seguros dejan de funcionar si mañana Cobol desaparece.

Los editores de software lo saben bien: de manera que van a centrar sus esfuerzos en las tecnologías las más encontradas entre sus clientes y no van a invertir en Powerbuilder o Delphi.
A menos que tu empresa sea en las más grandes y/o más viejas del sector, que haya acumulado estratos de todas las tecnologías en el curso de los años, o que haya fusionado con otras empresas, o haya cambiado a menudo de estrategias de desarrollo, es probable que tengas más de 75 % del portafolio de aplicaciones en 2 o 3 tecnologías diferentes. Y mucho probablemente J2EE / Cobol / SAP. Y muy ciertamente la parte más crítica, para el corazón de negocios de la empresa.

Saca de tu lista de selección las herramientas que no cubren tus aplicaciones. Para las que se quedan, verifica en detalle – con un piloto por ejemplo – la calidad de los análisis realizados. El numero de otras tecnologías constituye una simple información, no un criterio de elección.

Numero de métricas

Así como para el punto anterior, centrete en la calidad y el valor de las métricas propuestas más bien que en su número. Es bueno tener 20 reglas de nomenclatura para todo tipo de objetos que tienen las aplicaciones, pero esto no vale una métrica que sepa identificar un defecto grave de programación con un riesgo alto de ver la aplicación pararse o provocar una corrupción de datos.

Identifica las 10 o 20 métricas más importantes para:

  • Validar la entrega de una aplicación (Quality Gate).
  • Comprobar los SLAs de los proveedores.
  • Los procesos de Integración / Mejora continua de los equipos de desarrollo.

El número de métricas desempeñará un papel sólo en dos casos muy precisos:

  • El cálculo de la deuda técnica (tendremos la oportunidad de verlo).
  • La auditoría de la calidad de una aplicación que se va a ‘adquirir’ (por que vas a recuperar el mantenimiento por ejemplo) o con el fin de identificar un problema concreto (de rendimiento por ejemplo).

Pero incluso en este caso, es raro encontrar exactamente el error en cuestión o un defecto específico usando una métrica particular. Además, este caso corresponde a un contexto de consultoría y no de adquisición de una herramienta de software.

Crea una lista de las mejores prácticas necesarias para tus aplicaciones: son estándares en el mercado y, normalmente, la mayoría de las herramientas deben integrarlas. Si no, es que el producto es, probablemente, todavía un poco joven para esta tecnología.

Identifica luego las métricas interesante pero no esencial, con arreglo a los casos de uso que deseas colocar. El resto es “nice to have”.

Capacidad de crear nuevas métricas

Advertencia: criterio peligroso.
Un principio básico en informática: si está disponible, se va a utilizar. Si es posible hacerlo, se hará. Incluso si no se necesita.

¿Te acuerdas de esa caja de “pequeño químico” que te dieron en Navidad, con pretexto de qué se trataba de un juguete educativo destinado á despertar tus instintos científicos?
¿Quién habría imaginado que acabarías jugando al científico loco en busca de la mezcla más explosiva de sustancias de colores diferentes?

El mismo síndrome se encuentra a veces, entre algunos arquitectos o responsables de Calidad que reconstruyen la norma ISO 9216 con su propio modelo y sus propias métricas. He visto a menudo tales intentos abandonados al cabo de 2 o 3 años, simplemente porque el beneficio de esta customización es inferior a los costes de desarrollo y de mantenimiento. En el mundo Open Source, es posible que tus nuevas métricas sean incorporadas por la comunidad en una versión de la herramienta. En el mundo propietario, olvidalo. Deberás llevar tu propio modelo solo, en cada upgrade de software.

Son pocos los casos en que se justifica la necesidad de nuevas métricas, principalmente cuando no existen estándares bien definidos en el mercado. Esto puede ocurrir para unas pocas tecnologías raras. De lo contrario, es que el editor del software no integró las reglas que correspondían a las buenas prácticas. O lo apartas de la lista, o trabajas con él para incorporar estas normas en una versión futura.

En todos los casos, hay que medir bien el coste del desarrollo y del mantenimiento de nuevas métricas y asegúrarse de que las necesitas. Keep It Simple, no juegas al alquimista.

Enlaces entre componentes

Ciertos compradores de una herramienta de análisis de código presentan una actitud muy curiosa: tratan de atrapar a los que les proponen una solución. “Veamos si saben encontrar las llamadas dinámicas entre las capas de mi framework propietario”. “No digamos nada: ¿serán capaces de identificar los enlaces entre estos componentes?”.

Si tienes una necesidad particular, si las aplicaciones utilizan un mecanismo específico, expongalo claramente. Muchas empresas de servicios han creado su propia versión de frameworks Struts o Hibernate y sus clientes son ahora atados con componentes absolutamente no estándares. En ciertas aplicaciones Cobol, los programas, los JCLs y hasta a veces las transacciones CICS no se llaman directamente, sino a través de una tabla de codificación de estos enlaces.

La mayoría de las métricas identifican violaciónes de buenas prácticas de programación. Buscan las sintaxis incorrectas o incompletas o la estructuración incorrecta de diversas instrucciones. Las buenas prácticas de arquitectura no se apoyan en una sintaxis particular sino en los enlaces entre los diferentes componentes dentro de diferentes capas de la aplicación.

Veo principalmente dos intereses á una herramienta de análisis de código que sabe descubrir estos enlaces:

  • Realizar análisis de impacto: salimos allí del campo de la calidad de código para entrar en el dominio de las herramientas de documentación o de ayuda a la migración.
  • Verificar el respeto de las reglas de uso de frameworks, propietarios o no.

Creo que este segundo punto tiene un interés, por ejemplo, cuando se centraliza en algunos componentes el acceso a la capa de datos, o cuando todos los objetos de la capa de presentación utilizan un componente único para acceder a la capa de lógica de negocio. Entonces es bueno ser capaz de identificar los objetos que no respetan estas reglas. Porque la próxima modificación en una de estas capas corre peligro de no funcionar con estos objetos.

En cambio, esta funcionalidad se necesita sólo para las arquitecturas 3-tiers, pues J2EE y .Net. Además, en caso de frameworks y de buenas prácticas propietarios, se debe contar con un coste de customización.

También, estas métricas son las que presentan el número más grande de false-positivos y necesitan más validaciones. Es (relativamente) fácil verificar que una sintaxis particular es respetada o no, pues las métricas que corresponden a las buenas prácticas de programación son generalmente fiables. Una métrica que verifica las llamadas entre ciertos tipos de objetos o ciertas nomenclaturas de componentes será mucho más sensible al contexto aplicativo y puede necesitar una comprobación sistemática de los enlaces después de cada análisis. Con un coste más importante de puesta en ejecución.

Por fin, probablemente encontrarás una proporción de 1 a 10 entre estos diferentes tipos de reglas, es decir que las métricas de buenas practicas de arquitectura representarán no más de 10 % del conjunto de las reglas en la herramienta. Y no todas serán críticas.

Pues una vez más, verifique bien la adecuación, y el coste, y la necesidad. La herramienta más completa no es siempre la que conviene mejor.

No hay necesidad de comprar un Hummer para ir de compras en la ciudad: cuando te das cuenta del esfuerzo de maniobra y del tiempo perdido a procurar parqueo, corres peligro de dejarlo muy pronto al garaje.

Esta entrada está también disponible en Lire cet article en français y Read that post in english.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *