featured image

El tema de la calidad ha llenado páginas y páginas de la literatura informática en todos los idiomas. Es tal la necesidad de la búsqueda de la calidad, que hay estudios, técnicas y departamentos dentro de empresas e incluso empresas dedicados a establecer parámetros de calidad a los productos y proyectos que se realizan en las empresas de desarrollo de software.

Dentro del tema de la calidad, visto como un amplio abanico de elementos que la conforman, nos topamos con uno bastante confuso y complejo al principio: la calidad interna.

Actualizado (26 de septiembre de 2018) Ampliado y corregido para especificar más qué es la calidad interna y un acercamiento a cómo poder medirla.

¿Qué es la calidad interna?

En principio debemos saber que la calidad se define como la propiedad o conjunto de propiedades inherentes a algo que permite juzgarlo para determinar su valor. Si el software se define a través de unos requisitos funcionales y no funcionales y los cumple se dice que tiene calidad.

Sin embargo la calidad interna está dentro del sistema. Está más ligada a cómo se ha diseñado e implementado la solución. Un software puede presentar una buena (o aceptable) calidad general pero a la vez muy poca calidad interna. Esto es porque aunque el código haya sido mal escrito en estilo, elección de patrones y uso de recursos si aún así cumple su misión y los requisitos puede obtener una apariencia de calidad externa buena.

No obstante una mala calidad interna limita la vida útil del producto o proyecto. La mantenibilidad del mismo se ve muy afectada y las modificaciones suelen hacer fallar aleatoriamente sus características funcionales terminando por afectar a su calidad externa a medio y largo plazo.

La importancia que tiene este tipo de calidad se muestra de manifiesto en varios textos como Scrum y XP desde las trincheras (de Henrik Kniberg) y algunos blogs como el de José Manuel Beas, Joseba Enjuto, una entrada de Diego Gómez en la web Dos Ideas, o incluso en el propio estándar ISO/IEC 9126.

¿Cómo mantener y mejorar la calidad interna?

Lo ideal es escribir código limpio o claro. Cada lenguaje tiene su estilo, paradigma, mejores prácticas y ecosistema. Empleando sus fortalezas y siguiendo las buenas prácticas recomendadas es seguro mantener un buen nivel de calidad interna.

No obstante es fácil caer en algunos agujeros como cuando programábamos en lenguajes con líneas enumeradas como Basic que podíamos caer en la programación spaguetti, o como cuando programamos con lenguajes estructurados como C, Pascal o Modula–2 entre otros que podemos caer en la programación ravioli.

Al iniciar el desarrollo de cualquier solución es difícil tener presente qué desarrollar y más importante cómo hacerlo. Lanzarnos rápido a por un prototipo evolutivo nos garantiza tener una idea real de cómo puede funcionar la solución, nos permite probar y nos permite ver nuestras equivocaciones rápido. Nos permite corregir.

Lo ideal es desarrollar algo que funcione. Que cumpla su misión y que además tenga un mínimo de calidad interna y tras cada nueva característica asegurarnos de refactorizar para alcanzar una mejor calidad. La regla de oro sería: dejar el código mejor que cuando comenzaste a modificarlo.

¿Cómo saber si la calidad de un código es mejor?

Hay ciertos factores que nos facilitan a ver si nuestro código tiene una calidad interna. Podemos decir que un código tiene calidad cuando:

  • Es legible, es fácil de leer y se entiende. Cuando llegas al código después de un tiempo y lo lees no te cuesta entenderlo. Esto implica escribir el código con un buen estilo para verlo y entenderlo rápido, haber elegido bien el nombre de las variables, de las funciones, de los objetos, los módulos y/o los paquetes.
  • Es intuitivo, no necesita comentarios porque es auto explicativo. No tiene excepciones extrañas ni mecanismos de recursión difíciles de seguir. Es aburrido. El buen código es aburrido, es predecible, no te sorprende y resulta obvio. Cada cosa está en el lugar que se espera y resulta simple.
  • Es conciso, siempre he asociado la elocuencia con personas con un amplio vocabulario que son capaces de expresar cualquier pensamiento con una sola y adecuada palabra. En el código pasa algo similar. Cuando el desarrollador tiene un amplio dominio de las librerías, funciones, objetos, sintaxis, le permite emplear más elementos que expresen el mismo código de una forma más concisa y menos locuaz.
  • Es eficiente, además de ser conciso, funciona. Y funciona mejor gracias a ser conciso. Emplea mejor los recursos: procesador, memoria, disco y/o acceso a red.

Son algunos de los parámetros que podemos emplear para calibrar la calidad de nuestro software. No como escala sesgada a unos valores fijos sino como elementos referenciales que nos permitan conocer el beneficio de un cambio realizado en el código evaluando con puntos relativos cómo de legible era y es ahora, como de intuitivo era y es ahora y así con cada uno de los parámetros.

¿Por qué es tan importante?

Para el desarrollador implica un desafío para mejorar. Hacer cada vez mejor un desarrollo no solo agregando nuevas características sino afianzando y haciendo más robusto el código para garantizar su fácil mantenibilidad.

Para el dueño o receptor del software es incluso más importante porque un código con una muy buena calidad interna facilita integrar nuevos desarrolladores a trabajar sobre el código sin suponer un problema por no entender lo realizado. Palia o elimina la fricción de la entrada de estos nuevos desarrolladores.

Además, no trabajar en incrementar la calidad interna del producto puede declinar en lo contrario. Cada vez más podríamos acercarnos a un punto donde ya no sea posible avanzar sin modificar grandes partes del software o incluso tener que reescribirlo todo en el peor de los casos incrementando la deuda técnica.

¿Y tú? ¿Dedicas tiempo a incrementar la calidad interna de tu software? ¿Mides o te gustaría medir la calidad de tus desarrollos? ¿Conoces más formas de incrementar la calidad interna? ¿o de no decrementarla aún más? ¡Déjanos un comentario!