sábado, 27 de marzo de 2010

Gestión de Configuración

Gestión de Configuración de Software

Durante el desarrollo de cualquier producto de software, sea pequeño o sea grande, no importa el tamaño del equipo, ni el lenguaje de programación, el único factor que permanece constante irónicamente es el cambio. El desarrollo se refiere a que los componentes o artefactos que creamos y combinamos para crear nuestro producto de software, van evolucionando a lo largo del tiempo hasta que llegamos a una configuración que satisface el conjunto de requisitos que son prioritarios para los interesados en el producto en ese momento.

Cuando hacemos un programa pequeño, de manera personal, el grado de complejidad es bajo. Por lo tanto somos capaces de administrar los cambios de manera aceptable. Sin embargo, qué pasa cuando tres meses después de estar trabajando en otras cosas, volvemos a tratar de mejorar ese pequeño programa, cambiando el código para utilizar algún patrón que recién aprendimos o agregarle funcionalidad.

La mayoría de los programadores aborrecen la documentación y en un proyecto pequeño, inclusive evitan agregar comentarios al código, pues resulta obvio lo que está haciendo y cómo lo hace. Muy probablemente sí era obvio el qué y el cómo mientras se estaba tecleando el código. Pero tres meses después, ya no resulta tan obvio e inclusive puede despertar dudas acerca de la efectividad o eficiencia del código. Esa capacidad limitada de retención de memoria a largo plazo tiene su lado positivo, es lo que permite la evolución de las ideas.

En cuanto comenzamos a modificar el código de hace unos meses, estamos modificando la configuración de los componentes de nuestro producto de software, o sea, nuestro programa. Si tenemos suerte, después de hacer las modificaciones el código compila, pero eso no significa que el programa siga funcionando como esperamos. De hecho lo peor que puede suceder es que el código pase sin problemas las fases de análisis léxico y sintáctico del compilador y se produzca un nuevo ejecutable y que al utilizarlo nos genere un error de ejecución críptico en el método con el código más obvio de todos y que ni siquiera tocamos durante la modificación.

Aprender de la historia o ¿por qué el programador odia la documentación?

Utilizar un sistema de gestión de configuración, también conocido como control de cambios o control de versiones, es registrar la evolución de nuestro producto a lo largo del tiempo. Considero que es la documentación más importante que podemos registrar en cualquier proyecto de desarrollo.

La aversión que tienen la mayoría de los programadores con respecto de la documentación, proviene de las prácticas del milenio pasado. Las primeras metodologías para el desarrollo de software eran muy estrictas y extrapolaban prácticas que funcionaban bien en otras industrias, como la construcción, en las que el grado de incertidumbre es relativamente bajo. Sin embargo, todo proyecto para el desarrollo de software comienza con una gran incertidumbre que va disminuyendo paulatinamente hasta que al final conocemos la configuración final del producto el día en que se pone en operación.

Debido a esta incertidumbre, el tratar de definir un producto de software y plasmarlo en documentación inamovible es una causa perdida. En el desarrollo de software es imposible tener los planos antes de empezar a codificar. Para empezar, la persona o grupo que pide la creación de un producto de software, rara vez sabe exactamente y a nivel detallado qué es lo que quiere, y no se diga qué necesita en realidad. Luego, a diferencia de la construcción de un edificio en la que resulta relativamente sencillo conocer el impacto que tiene la modificación de las especificaciones iniciales. En el desarrollo de software, al ser un producto intangible, resulta muy difícil comprender el impacto que tiene un cambio en los requisitos, por minúsculos e insignificantes que le parezcan al interesado.

Entonces, ese tipo de documentación aplicado al desarrollo de software simplemente no sirve. En cambio, las prácticas contemporáneas que se han agrupado bajo el término de Metodologías Ágiles, tienen como premisa la incertidumbre inherente al desarrollo de software y en lugar de tratar de amoldar el desarrollo a la rigidez del método, se adaptan de manera flexible al proceso evolutivo del desarrollo de software.

Como ya lo expuse, desarrollo implica un proceso evolutivo, cambios constantes y es por eso que en lugar de tratar de reducir la cantidad de cambios a través de documentación rígida, lo racional y lógico es aceptar la constancia del cambio y documentar la evolución. En lugar de intentar detener el río y caminar sobre el agua, hay que fluir con la corriente.

Un sistema de gestión de configuración nos permite guardar la historia evolutiva de nuestro producto de software. Así la podemos revisar para saber por qué se tomaron decisiones en el diseño de los componentes y entender cómo llegamos al estado actual. A partir de esta historia, podemos deducir cuánto costará agregar o modificar funcionalidad. También puede servir como un curso abreviado para miembros nuevos del equipo. Es más interesante para un programador novato ver la evolución del código que leer manuales técnicos con análisis y diseño que nunca llegó al producto final.

¿Por qué es importante?

A medida que crece un producto de software y que el equipo de desarrollo pasa de una sola persona a una docena, la complejidad de la configuración de los componentes, así como la de los canales de comunicación crece geométricamente, o sea, no se suma, se multiplica. Resulta pues, que aventurarse a intentar desarrollar software sin un sistema de gestión de configuración, es como conducir un automóvil de carreras a través de un túnel de doble sentido, sin luces y con los ojos vendados.

Cualquiera que se autodenomine como desarrollador de software debe utilizar un sistema de gestión de configuración para todos sus proyectos. Si te fascina codificar y compilas en la mente, te hace falta una cosa para ser un buen programador: registrar la historia de tu código. Si tan sólo pudieramos ejecutar

diff
entre el presente y la historia del mundo y aplicar
patch
sobre todas las injusticias del mundo...

2 comentarios:

  1. A mi me parece que un sistema de gestión de configuración aún así no es suficiente (aunque es esencial). Para mi, lo de interés no es solo ver "cómo" evolucionó el código sino el "porqué". Entonces cada "check-in" debe llevar comentarios con detalle suficiente para explicar los motivos o dirigir quien lo esté leyendo a dónde obtener más detalles (incluyendo típicamente el ID del requerimiento o defecto identificado, que pudiera estar almacenado en un repositorio separado). Esto es especialmente crítico si más de una persona está haciendo cambios al código para saber quién le movió a qué y por qué.

    ResponderEliminar
  2. Carlos, precisamente ese es el punto de la documentación "a posteriori" y a la que me refiero como la historia de la evolución del código. Quizás me faltó enfatizar más la importancia de realizar anotaciones detalladas y explícitas cada vez que se registre un cambio en la configuración.

    ResponderEliminar