Si no has leído la primera parte acerca de la calidad en el Software, da clic aquí para leerlo primero.
Con la finalidad de complementar el post anterior, esta semana voy a enfocarme en elemento más específicos que rodean la calidad en el desarrollo de software. Estos elementos son importantes y los debes de considerar siempre que estés programando. Por sí solos, ninguno de estos puntos significa Calidad, más bien son elementos indispensables en cualquier Software. Es decir, si generas más funcionalidad, pero que no cumple con estas características, no tiene calidad.
“El Software con calidad, es Confiable, Mantenible y Escalable”
Confiable
Una de las principales características que todo producto debe de cumplir, no solo los de software, es ser confiables. Nadie quiere un coche solo arranca el 50% del tiempo, o que solo frena el 90% de las veces, seria absurdo. Un producto que no es confiable no tiene razón de ser. Para que un producto sea Confiable, tiene que está Disponible (arrancar siempre), y su funcionamiento debe de ser Predecible (frenar siempre que presionas el freno).
Y esto aplica especialmente en el software. Los niveles de disponibilidad esperados por la industria son del 99% para arriba. Incluso con esos niveles, miles de usuarios que abandonan una aplicación si no abre rápido y a la primera. Si tenemos suerte el usuario pedirá soporte, pero en la mayoría de las veces habremos perdido su confianza.
“Para que un software sea Confiable, debe tener Alta Disponibilidad.”
Lo mismo pasa con problemas funcionales. El usuario utiliza el software de la manera que aprendió a usarlo. Lo alimenta con la información que conoce y espera que el software haga lo mismo siempre. En sistemas mal diseñados, con exceso de reglas o con demasiada complejidad, el usuario prefiere no usar el sistema porque no sabe que esperar cada vez lo utiliza. El funcionamiento del software debe de ser 100% predecible para el usuario, nunca debe de arrojar resultados inesperados.
“Para que un software sea Confiable, su funcionamiento debe de ser Predecible.”
Esto es tan importante, que el 99% las solicitudes de soporte que son levantadas por usuarios serán por una de dos razones: O no pueden entrar el sistema (Disponibilidad); o el sistema está haciendo lo que el usuario espera (Predictibilidad).
Por eso, al diseñar las funcionalidades, la arquitectura, la interacción (UX/UI), y la lógica, trata de considerar todos los escenarios. Ponte en los zapatos de los usuarios y piensa en todos los caminos que puedes tomar. Piensa en la relación que existe entre cada campo en un formulario. Piensa en que pasaría si recibes un valor incorrecto. Piensa en los diferentes estatus que puede tener un flujo, y como estos estatus cambian la interacción con el usuario. Si en algún momento consideras que el funcionamiento es demasiado complejo, lo más seguro es que sea peor para el usuario. Busca otras opciones. Divide la funcionalidad. Simplifica la interacción.
Finalmente, el usuario quiere que el sistema sea Confiable, si no lo es, no tiene Calidad.
Mantenible – Velocidad vs Deuda Técnica
Ahora entramos en temas donde lo que debemos encontrar equilibrio. Que el sistema sea Confiable es muy directo y claro. No hay que hacer ningún tipo de balance entre sacrificar algo a cambio Confiabilidad. Confiable es Confiable y punto. Sin embargo, que el sistema sea Mantenible es siempre un ejercicio de balance entre entregar más funcionalidad, y menos Deuda Técnica.
“Un Software Mantenible es el que encuentra el correcto equilibrio entre la entrega de nueva funcionalidad, y minimizar la Deuda Técnica.”
¿Pero que es Deuda Técnica? Son todas esas tareas de limpieza y optimización que hacen que un software sea más mantenible. Cuanto tenemos prisa son tareas que dejamos pendientes con la finalidad de entregar una funcionalidad más rápido. Básicamente es el sacrificio de los patrones y mejores prácticas a favor de entregar lo antes posible. Es esa primera versión de tu función, sucia y al aventón, enfocada únicamente en solucionar el problema, sin pensar en el futuro. Es la la clase con una sola función, que tiene IFs dentro de otros IFs, y FOR dentro FORs. Es esa función que la siguiente vez que tienes que modificar, tienes que leerla 10 veces para poderle entender. Esto puede que sirva para prototipos, pero no es una buena apuesta a largo plazo.
Y es que una función así no es Mantenible. Al estar creando nuestro software tenemos que equilibrar entre la velocidad que entregamos la función y la limpieza, optimización y orden de nuestro código. El código sucio es más difícil de mantener, y cada minuto que utilizas en limpiarlo se traduce en más de 15 minutos ganados al momento de solucionar un bug o agregar nueva funcionalidad. Aún mejor es cuando eres capaz de escribir código limpio a la primera. Algo que todo programador debe de hacer.
Para esto te recomiendo leer uno de los libros indispensables en la librería de todo programador, Clean Code de Robert C. Martin (Uncle Bob). Es un libro de mejores prácticas que se ha vuelto un estándar para todo programador. Si quieres comprarlo, utiliza la siguiente liga y además apoyaras al crecimiento de d0a.dev.
Clean Code: A Handbook of Agile Software Craftsmanship; Robert C. Martin – Amazon México
Clean Code: A Handbook of Agile Software Craftsmanship; Robert C. Martin – Amazon USA
Finalmente, aquí solo mencionamos el código. Sin embargo, para que una solución, con todo lo que la rodea, sea mantenible, no solo el código tiene que ser limpio. También su arquitectura, sus módulos, y su interfaz. Junto con el código limpio, estos son temas que iremos desarrollando en posts futuros. Si quieres ir empezando, Uncle Bob también tiene un libro de Arquitectura limpia. Puedes comprarlo dando clic en la siguiente liga:
Escalable
Finalmente, Escalabilidad, la capacidad del software para crecer y aumentar sus recursos dependiendo de la demanda.
Y esto no solo significa crecer de manera infinita para recibir un infinito numero de usuarios. La escalabilidad se puede medir en cualquier cosa que crezca, como la simple capacidad de aumentar el número de registros.
“Escalabilidad es el equilibrio entre lo que necesitan los usuarios, y los recursos que necesitamos estamos dispuestos a utilizar para esto.”
Aquí, igual que con Mantenible, no es algo muy directo. Tenemos también que hacer un ejercicio de equilibro entre la escalabilidad que realmente necesita el usuario, y los recursos que estamos dispuestos a utilizar para esto. No tiene ningún sentido dedicar cientos de horas para diseñar una arquitectura con escalabilidad infinita, si el sistema lo van a usar 5 personas dentro de la empresa. En general el nivel de escalabilidad dependerá principalmente en el número estimado de usuarios que utilizarán el sistema, y la cantidad de uso que le den. Posteriormente es algo que se puede ir adaptando a la demanda.
Afortunadamente el día de hoy podemos hacer software escalable no es tan complicado, especialmente si utilizamos arquitecturas e infraestructura el Cloud. Con simplemente respetar ciertas prácticas sencillas, que no te quitan mucho tiempo, puedes crear aplicaciones que podrán escalar infinitamente. Y cuyo costo de infraestructura escalará dependiendo de la demanda.
Pero recuerda que el mínimo de escalabilidad requerido por toda aplicación tiene que ser el suficiente para que lo utilicen los usuarios actuales sin ninguna sorpresa. Nadie quiere dar clic en Guardar, y que el sistema le diga que ya no hay espacio.
Resumen:
- El Software tiene que ser Confiable, Mantenible y Escalable. Si entregas más funcionalidad, pero no cumple con estos 3 requisitos, no tiene Calidad.
- Un producto Confiable es el que siempre está Disponible y su funcionalidad es Predecible.
- Un Software Mantenible es el que encuentra el correcto equilibrio entre la entrega de nueva funcionalidad, y minimizar la Deuda Técnica.
- Escalabilidad es el equilibrio entre lo que necesitan los usuarios, y los recursos que necesitamos estamos dispuestos a utilizar para esto.
