TDD y Diseño de Implementación (1)

Post Siguiente


Sirva el post de hoy como introducción a un gran tema, que seguramente no podré comentar completamente. Es el tema de la relación entre TDD (Test-Driven Development) y diseño de implementación (no de interfaz o experiencia de usuario, digamos, diseño del código y su arquitectura).


Comienzo con una pregunta:


¿Qué esperamos de un sistema o aplicación?


Lo primero que se me ocurre, es que funcione bien. Imaginemos que estamos usando un procesador de texto, y cuando guardamos el documento se graba nada más que la mitad y lo demás se pierde. No será lo que esperamos. A esta altura de la historia del software, esperamos que una aplicación funcione bien, sin ese tipo de problemas. Yendo más específico, debería:


- Brindar la salida esperada, ante una entrada esperada


- Reaccionar de forma adecuada, ante una entrada no esperada


- Reaccionar de forma adecuada ante una falla en el entorno (por ejemplo, pérdida de conexión con la base de datos)


Seguramente se les ocurriran más puntos de este estilo.


Ahora bien, me puedo imaginar una aplicación así, y que no esté bien diseñada. Muchos de nosotros recordamos (y aún puede ser que tengamos) aplicaciones Visual Fox, o Visual Basic clásico, donde todo está escrito en el botón de aceptar. Conozco aplicaciones así, que funcionan según lo esperado. Y los clientes y usuarios están contentos.


Pero muéstrenme un ejemplo de una aplicación exitosa así, y casi seguro que los creadores de ese sistema tuvieron que lidiar bastante en sacar nuevas versiones, y todavía están viendo cómo migrarlas a la web y dispositivos móviles, impulsados por lo que la gente y el mercado espera hoy.


Entonces ¿qué esperamos de un buen diseño de implementación? No sé ustedes, pero yo espero que el diseño de implementación (el código, su funcionalidad interna, su distribución, su arquitectura) sea simple. ¿Por qué? Porque es la cualidad más importante para conseguir que sea mantenible.


Si un sistema exitoso no necesitara cambios, no buscaríamos mantenibilidad. Pero si un sistema es exitoso, casi seguro que sobrevivirá en el tiempo, y como la realidad cambia, habrá que actualizarlo. Un contraejemplo: si conseguimos escribir un sistema que nos dé el número ganador de la próxima gran lotería en EE.UU. y de sólo esa lotería, con un grandísimo premio, el cliente final no se va a preocupar por la mantenibilidad o nos va a pedir actualizaciones. Pero en general, los sistemas y aplicaciones exitosos necesitan evolucionar.


Por supuesto, podemos conseguir sistemas y aplicaciones exitosos programando sin buen diseño, por ejemplo, para llegar primeros a un mercado. Algunas de las aplicaciones Visual Fox que mencionaba antes, al salir rápidamente, consiguieron que la empresa creadora pudiera llegar primero a un nicho de mercado, y eso fue más importante que el tener un buen diseño desde el comienzo. Luego, se pudo pagar la deuda técnica en la versión 2.x con todo el ingreso y el posicionamiento que se consiguión en la versión 1.x.


Entonces, volviendo a la mantenibilidad, ¿por qué pido que la implementación sea simple? Porque será entonces


- más entendible para quien quiera que venga (individuo o equipo) a escribir la versión 2.0


- tendrá menos piezas, y cada modificación se podrá encarar tocando pocas de esas piezas a la vez


Por añadidura, una aplicación internamente simple, se verá expuesta a menos fallas de las piezas (en general) por tener menos puntos de posibles problemas en ejecución. No es lo mismo tener una aplicación que actualice una sola base de datos, que otra que tenga que actualizar 10 bases de datos distribuidas y heterogéneas.


Hay quien pedirá: no, yo no quiero que el diseño sea simple, sino flexible. Acá llegamos a un punto crucial, para lo que quiero tratar y todavía no apareció: desarrollar con TDD.


Bien, bastante por hoy, veré de escribir en próximos posts:


- Lo simple vs lo flexible


- Cómo TDD promueve lo simple


- Cómo TDD nos ayuda a conseguir lo “flexible” por añadidura y sin gran esfuerzo


- Cómo TDD nos da una mano para conseguir lo primero que mencioné: que la aplicación funcione como esperamos


- Cómo un buen diseñador puede diseñar “mejor” con TDD, y además cómo eso beneficia a quien quiera que venga a mantener el sistema


Vean que pongo “TDD promueve”, “TDD nos ayuda”, porque TDD solo no hace nada. Hay que poner cabeza. Pero desde hace unos años veo que TDD + Cabeza, nos da un sistema mejor que sólo aplicar Cabeza, es decir, sólo con nuestros conocimientos y destrezas.


Nos leemos!


Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez

This entry was posted in 10549, 11699, 18052. Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *


*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>