sábado, mayo 14, 2005

Día 0.2 : Recapitulando

Claramente me he excedido en el tiempo a dedicar, lo cual significa que probablemente pasen varios días antes que de el siguiente paso.

Pero para cerrar algunas ideas. Revisé el tema de CruiseControl y esencialmente el problema era que no tenía ningún servicio asociado a los logs. Afiné la configuración de NAnt y que la ejecución sea cada 10 horas (el reporte en el Dashboard me gustó bastante), además, comencé a utilizar CCTray.

Asi que ahora tengo un minuto para recapitular respecto al objetivo de esta herramienta.

¿Cuál es el objetivo de la integración continua? El link de rigor es a un artículo clásico, y está aquí.

Después de eso, ¿qué puede decir uno? Poco probablemente, sólo darle algo de contexto, en base a la realidad nacional.

A excepción de algunas "fábricas de software" en Chile, la mayor parte de los proyectos son proyectos de pocas personas, muchas veces de una sola, que se mueven entre 40.000 a 80.000 líneas de código (a veces las aplicaciones tienen 120.000 líneas, pero buena parte es grasa, y al final se podría tener lo mismo con 80.000).

¿Tiene sentido en esos casos aplicar este tipo de metodología? ¿Vale el esfuerzo?

Yo no lo tengo cien por ciento claro, por algo estoy haciendo esta prueba. Pero, ¿qué hace razonable la prueba?

En primer lugar, los problemas que tiene el desarrollo tradicional, más bien artesanal, que se basa en el conocimiento de los artesanos y que suele no ser reproducible.

Para la generación de entregables (llamese exes o sets de instalación) he visto diferentes métodos (que van en la dirección de dejar de ser artesanía, por lo cual el método 0, es decir, al lote, me lo salto).

Primero, el conocimiento experto, que sólo se hace "repetible" en base a un esfuerzo constante y personal, y que normalmente viene aparejado de problemas cuando un "aprendiz" ingresa al proceso. Temas como integrar esta generación al control de fuentes, por ejemplo, siempre resulta en que al revisar la historia de "liberaciones", los casos especiales saltan a la vista.

Segundo, checklist. Un esfuerzo de transformar estas tareas en un proceso que cualquiera pueda hacer. El problema, es que cada proyecto puede requerir un CheckList distinto. Además, se repite el problema del aprendiz y la presión del tiempo. Tal como una de las reglas más básicas del desarrollo de software es no abandonar las metodologías en los momentos de presión, pues eso siempre resulta peor, lo normal es que si no hay un control constante, el checklist no se realice y nuevamente aparezcan los casos especiales.

Tercero, automatización manual. En algunos proyectos, la generación de los ejecutables y los sets de instalación se han automatizado en algún grado, pero siempre utilizando herramientas básicas, como los archivos .bat. Aunque esto va en la dirección correcta, es fácil que la incorporación de nueva lógica sea difícil, en particular lo que se refiere a dependencias entre las partes (lo cual comienza a complejizarse cuando uno desarrolla parte de la lógica en componentes).

De hecho esto último suena casi a reinventar la rueda, ¿si vamos a automatizar porqué no utilizar lo que ya existe? La pretensión del desarrollador es que siempre uno puede construirse algo más acorde a sus exactas necesidades, que el tiempo que uno gasta en aprender algo lo puede invertir en desarrollarlo. Pero la verdad es que esa es una fantasía (o sólo funciona en casos muy específicos).

Hoy existe un buen número de herramientas, con su propia comunidad de usuarios, que permiten facilitar este proceso y dejar de depender de las habilidades personales.

Esto es lo mismo que pintar una casa.

Si uno va a pintar una pieza, probablemente puede hacer las cosas a la pinta de uno, correr los muebles y comenzar a pintar, mal que mal, si uno pinta sin querer un marco o los interruptores de la luz, se puede arreglar.

Si uno va a pintar toda la casa, o más aún, todas las habitaciones de un edificio, la cosa es diferente. El corregir los errores puede ser muy caro. El presupuesto de pintura se vuelve más importante (es diferente tener que gastar un galón más que 100).

En sistemas de largo aliento (como los que uno puede desarrollar como empresa proveedora o en aquellos que se deberá dar mantención durante largo tiempo), más vale el hacer las cosas bien (hacer las cosas bien a la primera siempre sale más barato).

De hecho, el objetivo de la aplicación a desarrollar, va en la dirección de apoyar el refactoring y traspaso de aplicaciones que fueron construidas en forma artesanal, y en las cuales, el proyecto alternativo de hacerlo de nuevo es muy caro (de hecho, cualquier aplicación de 100.000 líneas de código puede significar un proyecto de 18 a 20 meses con la participación de un buen equipo de desarrollo), tanto por esfuerzo como por oportunidad, y donde nada nos garantiza que el resultado no tenga los mismos defectos que la solución original.

No hay comentarios.: