¿Cómo podemos discernir que una aplicación es de mayor calidad que otra?

Lejos de plantear una definición demasiado académica y siendo pragmáticos, podemos decir que un software es de calidad no solo cuando cumple correctamente la funcionalidad requerida, además, lo consideramos de mejor calidad cuando el coste de su mantenimiento es bajo y la dificultad para introducir nuevos cambios (nuevos requisitos) también es baja o trivial.

Fácil de decir, pero en cierta medida, difícil de conseguir. Esta es la definición de calidad de software que, en mi opinión, es más interesante considerar en el día a día como programador en cualquier compañía.

La mayoría de los desarrolladores, por falta de experiencia, o bien por presiones en tiempo o ausencia de disciplina, nos quedamos atascados en ese primer aspecto de la calidad que comentamos en el párrafo anterior: cumplir la funcionalidad y punto, dejando la implementación de la funcionalidad X del primer modo en que la hemos escrito y resuelto. Sin embargo, ya sabemos que en cualquier negocio o proyecto, salvo excepciones muy contadas, a nuestro código se le va a requerir cambiar, sí o sí. Precisamente de esa realidad (todo software va a sufrir cambios), nació el movimiento de software ágil como forma de abordar mejor el código que escribimos, dando a pie a técnicas, al concepto de diseño ágil, etc.

Métete esto bien en la cabeza: debemos escribir código pensando en que sufrirá cambios necesariamente. La capacidad de aceptarlos determinará el coste de mantenerlo e incluso el éxito o fracaso del proyecto.

Recapitulemos: no programamos únicamente para cumplir con cierta funcionalidad que se exige en la aplicación hoy, también para hacer funcionar un negocio (que es el que paga en última instancia), y pocos negocios hay estáticos y que no tengan que cambiar, optimizarse o mejorar continuamente.

En este sentido, es fácil determinar si una aplicación es de calidad o no, tan solo tenemos que mirar los siguientes aspectos:

  • El código es simple (fácil de entender). La habilidad de un buen programador reside básicamente en encontrar soluciones sencillas a problemas que no lo son tanto.
  • También es legible (fácil de leer y de seguir). El código debe ser fácil de leer por cualquier miembro del equipo y  debe poder ser asumido con facilidad por cualquier nuevo miembro que se incorpore.
  • Existen tests que proporcionan una cobertura suficiente, esto es, un porcentaje alto de todo el código de la aplicación está cubierta por pruebas. El testing es un tema extraordinariamente amplio de modo que un tester en condiciones tiene habilidades técnicas diferentes que un desarrollador. Digamos que, con los pies en la tierra y siendo prácticos, que nuestro proyecto debe tener al menos una buena batería de tests unitarios y de integración.
  • El diseño y el código es homogéneo y coherente. No programamos del primer modo en que se nos ocurre solucionar algo, sino que esta solución debe mantener el diseño de la misma y estar alineada con el resto del código de la aplicación en estilo, uso de librerías externas, normas consensuadas de hacer las cosas, etc. Nada peor que identificar una parte específica de un proyecto en el que se reconoce la mano concreta de un compañero.
  • El desarrollador dedica la mayor parte de su tiempo a añadir nueva funcionalidad, no a corregir bugs. Si pasamos mucho tiempo detectando o corrigiendo errores, entonces ya sabemos que la aplicación se aleja de la definición de calidad que hemos dado más arriba y, por tanto, hay mucho trabajo para mejorarla.
  • A producción solo llegan (si llegan) pequeños defectos, nunca errores críticos. No es profesional liberar una versión de nuestro proyecto de modo que en explotación presente errores graves que impidan el buen funcionamiento de la actividad que soporta.
  • Las métricas más básicas dan buenos valores. Existen muchas métricas para evaluar diferentes aspectos del código, pero algunas básicas son fáciles de obtener y nos pueden ayudar a detectar ciertos problemas, como el número de líneas por método, la complejidad ciclomática, detección de código que nunca se ejecuta, etc

Nota: este artículo es es un resumen y forma parte del proyecto en desarrollo El Libro Práctico del Programador Ágil. Lanzamiento en julio 2018.


 

¿Por qué leer El Libro Negro del Programador?

Adquirir desde:
Amazon (kindle eBook / papel)
CreateSpace (papel)
PayHip (epub / mobi / pdf)

El libro negro del programador.com
Segunda Edición - 2017

Archivo

Trabajo en...

Mis novelas...