archivo

Archivos diarios: junio 16, 2012

Si la visión que tienes del desarrollo de software está demasiado condicionada por los enfoques clásicos y por gestiones orientadas a procesos demasiado rígidas es posible que no estés de acuerdo con la siguiente reflexión de Ken Schwaber: “El software que funciona es la principal medida de progreso”.

Lo demás son papeles y palabras (teniendo en cuenta que para el desarrollo de software se requieren papeles (o su equivalente digital) y palabras).

Ahora bien, hay que tener claro qué se entiende por software que funciona: orientado a las expectativas del usuario, no tiene por qué ser una versión final y debe ser fácilmente evolucionable (teniendo en cuenta las características del producto que se desarrolla).

Alistair Cockburn realiza la siguiente reflexión: “El primer objetivo es entregar el software; el segundo objetivo es estar preparado para el siguiente partido”.

En la misma refleja la esencia de la naturaleza evolutiva o iterativa del desarrollo de software. El desarrollo de software no termina con su entrega, su ciclo de vida va más allá independientemente de la metodología utilizada. Si el enfoque es iterativo incremental la entrega de una versión no es más que el punto de partida de la siguiente.

Es muy importante el detalle de que hay que estar preparado para lo que venga después y es que lo que desarrollemos hoy tendrá impacto en las evoluciones futuras del producto y todo trabajo debe hacerse con intención minimizando o eliminando la improvisación.

El primer objetivo debe ser la entrega porque sin esta versión no hay versiones posteriores.

Hay muchos desarrolladores que aplican TDD en sus desarrollos o, al menos, desarrollan pruebas unitarias para el software que están implementando.

Sobre ambos aspectos TDD (las pruebas unitarias se construyen antes) o las pruebas unitarias en general hay defensores y detractores y como suele suceder en tantos aspectos, no hay una verdad absoluta, sino que la aplicación o no de estas estrategias dependen del contexto en que se realiza el desarrollo, del tipo de sistema y del equipo de programadores.

Pese a que hablo de contexto incluso en situaciones favorables existen reticencias por muchos desarrolladores que lo consideran una pérdida de tiempo o una carga que llevar encima desde que se implementan, sin embargo quienes lo utilizan y lo consideran como una actividad más dentro de la programación lo suelen aplicar prácticamente en cualquier contexto.

No voy a defender a unos o a otros, cada cual tiene su criterio. Desde mi punto de vista la posibilidad de realizar testing unitario y su automatización supuso en su día una revolución en el desarrollo de software y en el mantenimiento de sistemas porque todo lo que sea establecer controles que permitan construir sistemas más robustos y entregar productos con menos errores debería ser bienvenido

Martin Fowler como buen defensor de estas prácticas realizó la siguiente reflexión sobre los frameworks de pruebas unitarias: “Nunca en el campo de desarrollo de software tantos le debieron tanto a tan pocas líneas de código”.