Check in early, check in offen

Acabo de leer el artículo Check in Early, Check in offen de Jeff Atwood acerca de la metodología de uso del control de versiones para el desarrollo de proyectos.

Aunque coincido con los artículos de Jeff en muchas ocasiones, esta es una de las situaciones en las que no lo hago.

En primer lugar, como por otro lado suele pasar con este tipo de artículos, las reflexiones que hace son demasiado genéricas y sobre caso demasiado simples como para poder extraer verdaderas conclusiones sobre ellos.

Hacer check in pronto y a menudo. Suena bonito, parece un concepto adecuado pero hay muchas cosas que quedan fuera del análisis, cosas que en un proyecto pequeño con dos o tres desarrolladores no tienen importancia pero que en grandes proyectos pueden dar verdaderos dolores de cabeza.

Uno de los ejemplos que cita es empezar con un código pequeño, que no haga nada y que tenga pocos, por tanto, pocos bug... de esta forma, según razona, podemos probarlo y subirlo al control de versiones. Entonces desarrollamos una nueva funcionalidad, la probamos y la subimos al control de versiones. Todo claro y sencillo...

Pero la cruda realidad es que eso no es así. En primer lugar no todos los cambios son "pequeños y sencillos". Cuando empiezas a crear una aplicación, cualquiera que sea, los inicios siempre son más complicados de lo que parece, el concepto de "hacer pocas cosas" esta vacio.

Por mucho que mi aplicación haga pocas cosas al principio no puedo diseñarla sencillamente sin tener en cuenta todo lo que voy a tener que hacer. ¿Va a ser una aplicación multihilo? ¿Que estructuras de datos voy a tener? ¿Cómo van a ser utilizadas?.

Lo más probable es que, suponiendo que el diseño de la arquitectura este claro, comiences desarrollando las estructuras que los soportan: clases, estructuras de comunicación, quizá una capa de acceso a datos... de forma que para que tu aplicación "haga pocas cosas", por pocas que sean, necesita una enorme base. Comenzar poniendo un interfaz simple y empezar a ligar eventos a segmentos de código es un paso hacía el caos total.

Podríamos, si acaso, comenzar desarrollando las estructuras de soporte. Una clase que lee los valores de configuración de archivo así como los test de unidad asociados y entonces subirla pero Jeff, sinceramente, ¿una hora?... Es irrealista pensar que en una hora puedes crear una clase mínimamente compleja y subirla al repositorio con confianza en que no haya bugs.

Al final la mayor parte de las tareas llevan bastante más tiempo de un día, al menos las tareas complejas. Si necesito implementar una clase de soporte para serializar mi clase mensajes de forma que se mande a través TCP y escribir el código para deserializarla y reconstruir el mensaje probablemente tarde más de un día... ¿debo entonces ir subiendo las pequeñas actualizaciones?

Como alguien menciona en los comentarios el proposito de un sistema de control de versiones NO es servir de backup de lo que vamos haciendo, aunque en muchos sitios se utilize con ese proposito.

En general cada proyecto exige sus propias configuraciones de control de versiones y es bastante dificil generalizar.

Personalmente a mi me gusta trabajar con una rama para cada versión entregada que tan solo acepta correciones de incidencias, eso es todo. Luego debe existir una versión para la proxima release que se va a entregar (normalmente la rama principal o el trunk) y que debe ser estable es decir, todo lo que suba un desarrollador ahí tiene que estar probado y se debe estar minimamente convencido de que funciona y no va a "romper" nada.

Luego las teorías divergen y hay diversas formas de hacer las cosas. Hay quien para ahí, de forma que todo el mundo hace check in sobre la rama principal. Evidentemente esto obliga a que todo lo que se sube al repositorio tiene que tener unas altas garantías de calidad, sube algo que no funcione y adios a todo el build.

Microsoft por ejemplo utiliza (o al menos utilizaba) una estructura basada en varios niveles. De desarrollador, de grupo, de aplicación, de producto... de forma jerárquica de forma que los check ins tardan tiempo en llegar a la main build del producto mientras se van aprobando y añadiendo cada vez a partes más altas del sistema.

La única regla que realmente podemos aplicar es que, a la hora de subir algo a un repositorio "oficial", esto es, candidato a salir en una build del producto, debe estar perfectamente probado (que no garantiza que no tenga errores). De esta forma todo depende de la organización de la compañía. ¿Que más da que te tires 10 días sin hacer check in? Si no está terminado no está terminado. Lo que hay que entender es que un check in comprende un bloque de funcionalidad completo que no rompe el sistema. No tiene sentido subir la integración del código de envío por red que depende en la capa TCP si aún no has terminado dicha capa.

Jeff sugiere subir stubs... tonterías, ¿de que sirve subir a la versión algo que, en si, no funciona? Los stubs sirven para hacer pruebas unitarias, para probar A que depende de B antes de que B este implementada, no para poder subir cosas cuanto antes al control de versiones. Lo cierto es que mi clase de serialización no sirve de nada sin la capa TCP. En código son dos unidades separadas pero funcionalmente son un conjunto.

Otro de los argumentos que se suele dar es el tener la posibilidad de volver atrás a cualquier punto anterior. Pese a que es un recurso muy importante, eso no tiene nada que ver con el flujo de desarrollo común. Quizá sea política de la compañía que cada desarrollador tenga su propia rama privada y quizá no. Si no lo es, basta con instalarse SVN en local y utilizarlo como control de versiones privado. Desde luego "contaminar" la rama principal con funcionalidad rota o con funcionalidad que no aporta nada a la versión no tiene ningún sentido. Hay que tener en cuenta que subir algo, aunque creamos que no cambia nada, puede tener muchos efectos colaterales y romper muchas cosas.

En conclusión, haz check in cuando estés listo, cuando puedas subir una funcionalidad completa, no utilices el repositorio como backup, hay formas mejores de hacerlo.

0
No votes yet
Your rating: None