A veces me he planteado la pregunta de cómo evaluar un buen software de uno que no lo es tanto. Aquí entran en juego seguramente aspectos muy subjetivos; sin embargo, si intentamos llegar a algún tipo de principio del tipo de los que muestra Max Kanat en su libro Code Simplicity, existen realmente varias maneras de evaluar la calidad de un buen software.

No me gusta nada ni siquiera plantear el concepto de calidad, ya que en la mayoría de las ocasiones, los desarrolladores de software hacen lo que pueden en el contexto laboral con el que les toca lidiar; pocas veces he visto que realmente las cosas se hagan mal por pura y llana pereza mental. Sí he visto muchas a menudo que las cosas se hacen mal por ingenuidad o por la falta de un tutor que sirva de guía y ganas de traspasar su experiencia.

¿Cómo entonces distinguir una librería o trozo de software bien hecho de otro no tan bueno?.

Un error muy común que cometen muchos desarrolladores de software es escribir código de manera que es difícil crear a su alrededor las suficientes pruebas o tests que garanticen que ahora y más adelante, el software funciona.

Esto es un mantra que repito a menudo: la estructura de una solución que puede ser probada no tiene nada que ver con la estructura de otra para la que es imposible crear un conjunto de tests. Por tanto, aquí tenemos un elemento que nos puede indicar en cierta medida la calidad de una pieza de código: si se puede probar con facilidad o dificultad.

Pero, ¿qué hay del mantenimiento?, ¿no es verdad que queremos escribir software que viva muchos años y que pueda ser vendido y desplegado en el mayor número de clientes posible?. ¿Cómo vamos a hacer esto si la solución que escribimos es imposible de mantener?. Volvemos a la metáfora del coche que no se puede reparar...

Del mismo modo que antes, un buen software escrito para facilitar su mantenimiento no tiene nada que ver en su forma y estructura de otro que es imposible o muy difícil de mantener (diseño rígido), entendiendo por mantenimiento la detección fácil de pequeños bugs y la capacidad de mejorar el producto con nuevas características o mejoras de las ya existentes.

Efectivamente, con el tiempo nos damos cuenta de que el diseño, estructura y forma de un software que permite ser probado con facilidad y que puede ser mantenido con sencillez, no tiene nada que ver con el diseño, la estructura y forma de un software que ni podemos probar bien y para el que es muy complicado introducir algún cambio.

Esto es un principio de desarrollo de software inquebrantable que uno termina por aprender a lo largo de varios años después de algunas etapas de fracasos y errores.

Cuando llegamos a este tipo de conclusiones, nos damos cuenta de que programar bien no se consigue sencillamente leyendo un buen manual de C#, Ruby on Rails o lo que sea; conocer los rudimentos de cualquier tecnología no es suficiente. Existen principios, leyes, diseños, etc. que nos indican realmente cómo llegar a una solución con la suficiente calidad.

Comparte esta entrada...

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