calidad

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

Todos defendemos nuestro trabajo, sin ninguna duda, aunque hay elementos subjetivos para ello pero también otros muy objetivos e incontestables.

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 y le aporta valor al cliente que la usa (y que paga por ella), 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 (esto último es, en realidad, el mantra de todo este libro, de modo que lo vas a leer a menudo hasta que se grabe en tu ADN de desarrollador).

Fácil de decir, pero en cierta medida, difícil de conseguir. Como muchos otros temas, lo simple no siempre es fácil. 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, porque lo que persigue cualquier empresa es rentabilizar al máximo cada esfuerzo que se realiza en crear un nuevo producto.

Muchos desarrolladores, por falta de experiencia o por presiones en tiempo o ausencia de disciplina metodológica, 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, y así se queda hasta el final de los tiempos, suponiendo en ocasiones un auténtico lastre y acumulando una deuda técnica que algún día nos pasará factura, a nosotros o a los compañeros que tengan que retomar el proyecto.

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»), en esencia, nació el movimiento de software ágil como forma de abordar mejor el código que escribimos, dando lugar a técnicas específicas, metodologías, técnicas de pruebas, 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. Y ya sabes, si tu trabajo fracasa, te obligarán a buscarte otro.

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 ello está además la esencia de la nueva economía de este siglo, en la que aparecen productos de un día para otro al mismo ritmo que otros evolucionan o desaparecen.

Es cierto que no existe una bola de cristal que nos anticipe qué cambios en concreto tendremos que introducir, pero veremos que, sin suponer más esfuerzo, podemos programar de un modo que facilite en el futuro la inclusión de nueva funcionalidad. Si, por poner un ejemplo, te cuestionas de verdad que crear tests te «retrasa» o piensas que programar bajo principios de diseño es un rollo (porque aún no comprendes bien su razón de ser y entiendo que muchos de ellos son sutiles de captar), entonces trabajas bajo una dinámica de pan para hoy y hambre para mañana y todavía no sabes que esas prácticas, en realidad, mejoran tu productividad y la calidad de tu trabajo.

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, y también en la capacidad de desmenuzar un problema grande abstrayéndolo en otros muchos más pequeños y manejables.

○    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. Me atrevo a decir que no hacen falta gurús para hacer las cosas bien.

○    Existen tests que proporcionan una cobertura suficiente, esto es, un porcentaje alto de todo el código de la aplicación está cubierto por pruebas, y éstas son de distinto tipo, como veremos en el capítulo dedicado al testing, que es un tema extraordinariamente amplio de modo que un tester en condiciones tiene habilidades técnicas diferentes a las de un desarrollador. Digamos que, con los pies en la tierra y siendo prácticos, nuestro proyecto debe contar al menos con 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 que se nos ocurre al tratar de solucionar algo, esto puede valer en una primera aproximación, sino que se debe mantener el diseño seguido en toda la solución 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, queda mucho trabajo para mejorarla.

○    A producción (entorno final en donde se ejecuta la aplicación para dar servicio al cliente) solo llegan pequeños defectos, si es que existen, pero nunca errores críticos, porque ya hemos hablado al comienzo que el coste de probar exhaustivamente un software de cierto tamaño es extraordinariamente alto. 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. Siguiendo el símil de los arquitectos… ¿os imagináis un edificio que al día siguiente de su inauguración comienza a mostrar grietas?

○    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.

En los siguientes capítulos hablaremos de todos estos aspectos y los describiremos a nivel técnico con mayor detalle.

Nota: este es el capítulo completo de título "Qué es la calidad del software" incluido en El Libro Práctico del Programador Ágil.