archivo

Archivos diarios: junio 18, 2011

La simplicidad es ágil. Siempre que se pueda es necesario huir de soluciones complejas. Tal vez la solución más simple no sea la mejor pero a larga se podrá comprobar como las complejas tampoco lo son y el esfuerzo para llegar a ellas, su coste de mantenimiento y la más que posible pérdida de productividad por parte de los usuarios harán inviable un retorno de la inversión a corto/medio plazo o incluso su propia recuperación.

¿Por qué tienen éxito muchas soluciones basadas en herramientas ofimáticas? Son sencillas.

Cierto es que aunque hagas un sistema de información absolutamente idéntico, nunca podrá competir con la flexibilidad con la que puede trabajar el usuario en ellas y con el rendimiento que supone trabajar con una solución que tiene en local o que se encuentra en su red de área local y eso hace por ejemplo que los usuarios muestren rechazo cuando le sustituyes estas soluciones por una aplicación.

Sin embargo es su simplicidad el principal motivo por el cual sus usuarios se sienten ligados a ellas.

A veces nuestra propia creatividad pone muy cuesta arriba el desarrollo de un sistema de información y tenemos que tener muy presente que nuestro objetivo no es ser artistas, sino desarrollar aplicaciones que sean útiles a los usuarios, dentro de unos plazos y presupuestos definidos.

Sucede con demasiada frecuencia que cuando se entrega una evolución de un software, ya sea en una iteración en un desarrollo iterativo incremental o en un mantenimiento correctivo o evolutivo, se realiza testing exclusivamente sobre las funcionalidades que se han desarrollado y no se comprueban otros segmentos del programa que se han podido ver afectados por los cambios realizados en el código.

En muchos casos son las prisas por cumplir plazos en el proyecto, en otros por la necesidad de solucionar una urgencia y en otros tantos porque no se piensa que determinados cambios en el código puedan provocar efectos colaterales en la aplicación.

Las posibilidades de que se produzcan este tipo de problemas dependerá mucho de la calidad de la codificación y de la sección del código que se esté tocando, ya que no es lo mismo tocar una clase con un alto acoplamiento que otra.

Para reducir el riesgo de que aparezcan efectos colaterales, es conveniente la realización de pruebas de regresión que se basan principalmente en realizar testing sobre funcionalidades de la aplicación que presentan riesgo de haber sido afectadas por los cambios. El esfuerzo necesario en realizar estas pruebas dependerá del nivel de automatización de las mismas que se tenga hasta el momento en el rango que va desde las pruebas unitarias hasta las funcionales.

Sobre las pruebas de regresión y en general sobre el hecho de que en la programación no hay que dar nada por sentado, podemos recordar la siguiente cita de Doug Linder: “Un buen programador es aquel que siempre mira a ambos lados antes de cruzar una calle que tiene un único sentido”.