¿Cómo mejorar la calidad de un software?

calidad de un software

calidad de un software

El primer problema de la calidad es definirla. Hay muchas definiciones, pero mi preferida en el contexto de la ingeniería de software es «adecuación al uso». Uno de los problemas de la definición es que es muy vaga pero, paradójicamente, el propio hecho de ser tan vaga es lo que la hace útil. La calidad es un asunto muy complejo, por lo que simplificarlo, lejos de ayudarnos a entender, sólo nos dará la ilusión de que lo entendemos. Y la ilusión de entendimiento es muy peligrosa porque hace que nos resistamos al aprendizaje real.

Cómo mejorar la calidad de un software

Como ya expone el apartado anterior, es imposible dar una «receta mágica» para mejorar la calidad. De hecho, intentar mejorar la calidad simplemente siguiendo una lista de pasos es un camino casi seguro hacia el fracaso. No importa qué pasos sigamos, qué hayamos oído de ellos o quién los haya recomendado: nuestra única vía para alcanzar un buen nivel de calidad es usar nuestra experiencia y conocimiento del contexto para decidir qué es lo que nos ayudará en cada momento.

Tenemos que ser conscientes de lo que hacemos y tomar el control de nuestras decisiones. Sin embargo, sí se pueden dar guías para mejorar la calidad. Por ejemplo: mantener siempre el qué, no el cómo, como la guía de todo lo que hacemos; mantener el escepticismo y cuestionar cómo hacemos las cosas y por qué; estar preparado para cambiar cómo trabajamos y luchar contra la «programación de culto al cargo»; no creer en la tecnología como el centro de lo que hacemos; darse cuenta de que lo principal no es hacer código bonito o fácil de entender, sino resolver problemas; no creer que los problemas tengan una solución única o mejor.

Esto no quiere decir que las herramientas, técnicas y costumbres no sean útiles. En absoluto. Lo que sí significa es que éstas nos ayudarán según qué contextos, según qué proyectos, según qué equipos y según qué clientes, pero nunca en todos los casos.

Ejemplo 1: procesos

Como regla general, tener procesos y reglas ayuda a los equipos de desarrollo a trabajar más eficientemente. Por una parte, facilita que nos concentremos en lo que estamos haciendo y no en el cómo.

Sin embargo, los procesos y las reglas pueden quedarse obsoletos. Por ejemplo, digamos que uno o dos miembros del equipo causan problemas con la integración continua: con frecuencia hacen cambios que hacen fallar a la batería de pruebas y no tienen disciplina para escribir pruebas. Ante esta situación, decidimos que cada cambio enviado al repositorio debe contener alguna modificación a algún fichero de pruebas. La medida funciona más o menos bien, esos miembros del equipo empiezan a tomarse las pruebas más en serio, y así aumentamos la productividad del equipo con ella.

Ejemplo 2: automatización de pruebas

Aunque es desde luego una de las prácticas más recomendadas y útiles, también es verdad que con frecuencia tenemos que trabajar con código legado (es decir, sin pruebas). En esos casos, ¿qué hacemos?

Por ejemplo, digamos que nos unimos a un equipo que no tiene cultura de pruebas automáticas, y vamos retrasados con la siguiente entrega. Una parte concreta del código está dando bastantes problemas, y las pruebas manuales (la manera en la que el equipo prueba el código) no están encontrando suficientes fallos, o no lo suficientemente pronto. Aunque automatizar las pruebas es probablemente la mejor idea a largo plazo, no hay ninguna regla exenta de excepciones.

Ejemplo 3: especificaciones

Cuando se desarrolla software normalmente se tienen especificaciones. Pueden ser formales (un documento) o informales (el conocimiento compartido del equipo). El objetivo de las especificaciones es poder concentrarse en la solución técnica sin tener que estar preguntando continuamente a los clientes o al resto del equipo sobre el enfoque a la hora de resolver el problema. Pero de nuevo, las especificaciones son sólo una herramienta, y cumplir más a rajatabla con las especificaciones no tiene por qué garantizar una mayor calidad del proyecto una vez completado.

Ejemplo 4: diseño simple

Una parte importante de la calidad es, por supuesto, tener código mantenible. El código mantenible normalmente se consigue con código legible y un diseño simple. Sin embargo, y como muchas otras cosas, estos dos aspectos son sólo una herramienta para conseguir calidad: un código legible y un diseño simple hacen que el código contenga, de media, menos errores, y éstos serán más fáciles de detectar y corregir.