Joel on Software   La Opinión de Joel sobre qué es Software

Otros artículos de "Joel on Software" en Español

Otros artículos de "Joel on Software" en Inglés

Envíele un Email al autor (solo en Inglés)

En 1982, mi familia recibió la primera PC-IBM en Israel. De hecho fuimos a la bodega y esperamos mientras entregaban nuestra computadora en el puerto de desembarque. De alguna manera había convencido a mi papá a que comprara la versión que traía TODO, la versión de "lujo", traía dos discos floppy, 128 K de memoria junto con una impresora de matriz de puntos (para hacer borradores) y otra marca Brother con calidad para cartas con "Daisy Wheel" que se escucha como una ametralladora cuando esta operando, solo que más fuerte. Creo que compramos todos los accesorios disponibles: PC-DOS 1.0, el manual técnico que costo $75 y que contenía un listado del código fuente del BIOS, Macro Ensamblador y el impactante monitor Monocromático con espacio para 80 columnas y...... letras minúsculas! Toda la computadora con los accesorios nos costó como $10,000 incluyendo los, para aquel entonces, impuestos ridículos de importación que tenia Israel. ¡Que Extravagante!

Bueno, "Todos" sabían que BASIC era un lenguaje de programación para niños que requiere que escribas una sopa de código y te convierte el cerebro en queso “Camembert.” Decidimos desembolsar $600 para IBM Pascal, que venia en tres disquetes floppy. La primera pasada del compilador era en el primer disquete, la segunda pasada era en el segundo disquete y el enlazador se encontraba en el tercero. Escribí el famoso programa "Hola Mundo" y lo compilé. Tiempo total transcurrido: 8 Minutos.

Hmmm. Yo diría que es demasiado tiempo. Escribí un proceso por lotes para automatizar el proceso y lo recorte a 7.5 minutos. Mejor, pero cuando intente escribir programas largos como mi versión emocionante de Otelo que siempre me vencía, me pasaba la mayor parte del tiempo esperando que el programa se compile. "Claro," me dijo un programador profesional, "nosotros teníamos una tabla para hacer abdominales mientras estábamos haciendo compilaciones. Después de pocos meses teníamos un abdomen escultural."

Un día, apareció desde Dinamarca un programa elegante llamado “Compas Pascal” que luego fue comprado por Philippe Kahn y lo renombró Borland Turbo Pascal. Turbo Pascal era impactante, por que hacía básicamente todo lo que hacia el Pascal de IBM, solo que corría en aproximadamente 33K de memoria incluyendo el editor de textos. Esto no era menos que increíble. Pero aun más increíble era que podías compilar completamente un programa en menos de un segundo. Es como si una empresa de la cual jamás hubieses escuchado introdujera un auto que era una clonación del Buick LaSabre que podría alcanzar velocidades de 1,000,000 Millas / hora y podría conducirse alrededor del mundo con tan poca gasolina que una hormiga se la podría tomar sin enfermarse.

De repente, me convertí en un ser mucho más productivo.

Entonces fue cuando aprendí el concepto del "REP LOOP". Rep significa (por sus siglas en ingles) "Leer, Evaluar, Imprimir", y describe lo que hace un interpretador lisp; "Lee" tu información, lo evalúa, y luego imprime el resultado. Un ejemplo del "REP LOOP" a continuación: Yo escribo algo, el interpretador LISP lo lee, lo evalúa e imprime el resultado.

A una escala, pero más grande, cuando estas escribiendo código, estas en una macro-versión de una Repetición REP llamado la repetición de editar-compilar-probar. Editas tu código, lo compilas y luego lo pruebas para ver que tal funciona.

Una observación crucial aquí es que tienes que pasar por la repetición vez tras vez para escribir un programa, de tal manera que mientras mas rápido los ciclos de editar-compilar-probar, mas productivo serás, hasta llegar a un límite de compilar instantáneamente. Esa es la razón de la ciencia-computacional por la cual los programadores de computadoras quieren hardware rapidísimo y los desarrolladores de los compiladores hacen cualquier cosa por lograr hacer más rápido la repetición de Editar-compilar-Probar. Visual Basic lo hace analizando cada línea mientras lo vas escribiendo, de esa manera la compilación final será súper rápido. Visual C++ lo hace ofreciendo compilaciones por incrementos, módulos o "headers" precompilados, así como enlazamientos incrementales.

Pero apenas comiences a trabajar con un equipo más grande de programadores y probadores de programas te encontraras de nuevo con la misma repetición, solo que más grande (¡es un fractal, mi amigo!). Uno de los probadores encuentra un problema en el código y reporta el problema. Un programador arregla el problema. ¿Cuánto tiempo tardara para que el probador reciba de nuevo la nueva versión del código? En algunas organizaciones, esta repetición de reportar-Componer-(volver-a-probar) podría tardar hasta varias semanas, que significa que toda la organización llega a un alto y por lo tanto nadie produce. Para mantener todo el proceso del desarrollo trabajando bajo control, necesitas enfocarte en mantener lo mas unido posible el ciclo de reportar-componer-(volver-a-probar).

Una buena forma de para hacer esto es haciendo construcciones diarias. Una "construcción del día" es una construcción automática, diaria, y completa de toda la estructura del código fuente.

Automática -- por que tu ordenas a que un programa, "cron jobs" en UNIX y "scheduler service" en Windows, que compile todo el código a una hora especifica todos los días.

Diaria -- o hasta mas seguido de lo normal. Existe la tentación de hacer construcciones continuas pero lo más probable es que no puedas por restricciones del controlador del código, hablaré más de estas restricciones en un momento.

Completa -- Existe la posibilidad de que tu código tenga múltiples versiones. Múltiples versiones con lenguajes diferentes, múltiples sistemas operativos, o una versión de alto nivel y otra de bajo nivel. La construcción diaria necesita construir todas las versiones. Y necesita construir cada archivo desde cero y no fiarse en las capacidades de construcciones increméntales del compilador que posiblemente sean imperfectas.

Aquí hay algunos de los muchos beneficios que podrían venir de hacer construcciones diarias:

1. Cuando un error [“bug”] es corregido, los probadores reciben la nueva versión rápidamente y puede volver al probarlo para ver si realmente se haya corregido.
2. Los desarrolladores pueden sentirse más seguros de que el cambio que hicieron no afectará negativamente ni una de las 1024 versiones del sistema que se producen, sin tener que tener una maquina con OS/2 en su escritorio para probarlo.
3. Los desarrolladores que registran sus cambios momentos antes de que se haga la construcción del día saben que no van a detener a los demás al registrar algo que podría "destruir o romper la construcción", es decir algo que cause que nadie pueda compilar. Esto es equivalente al "pantallazo azul" de la muerte para todo el grupo de programadores, y esto pasa mucho cuando a un programador se le olvida agregar un archivo que el haya creado en el repositorio del programa. La construcción corre bien en su máquina pero cuando otra persona intenta accesar el archivo reciben errores de enlace y son detenidos completamente de hacer cualquier trabajo.
4. Grupos externos como el de mercadotecnia, sitios beta de clientes y demás, quienes necesitan utilizar el producto inmaduro, podrían elegir una construcción que podría estar lo suficientemente estable para utilizarlo un rato.
5. Mantenido un archivo de todas las construcciones diarias, cuando descubras un error muy extraño y no tienes ni la menor idea de que lo puede estar causando, podrás utilizar una búsqueda binaria en el historial de archivos para poder saber cuando fue que apareció el error en el código. Combinado con un buen controlador de códigos fuentes, es muy probable que puedas precisar exactamente que registro de código fue el que causó el problema.
6. Si un probador reporta un problema que el programador piensa que ya arregló, el probador puede decir en que construcción vió el problema. Luego el programador puede ver cuando registró el código para corregir el error y de esta manera sabrá si realmente se arregló el problema.

A continuación explicaré como se hacen. Necesitas un servidor de construcciones diarias, que generalmente sería la computadora mas rápida que puedas conseguir. Escribe un script que reserve una copia completa del código fuente del repositorio del programa (¿sí estas utilizando un controlador de códigos fuentes verdad?), y luego las construcciones, todo desde cero, todas las versiones del código que venderás. Si tienes un instalador o un programa instalador, entonces construyen eso también. Todo lo que el cliente recibirá en la caja de software que enviaras deberá ser producido por el proceso de la construcción diaria. Pon cada construcción en su propio directorio identificados por la fecha de la construcción. Ejecuta el script a la misma hora todos los días.

• Es crucial que todo lo que se vaya a incluir en la construcción final sea incluido en la construcción del día, desde reservar el código, hasta incluir el proceso de poner los bits en el lugar adecuado en un servidor web para que el publico pueda bajarlo (claro que durante el desarrollo de la aplicación, este será un servidor de pruebas). Esta es la única manera de poder asegurar que ninguna parte de la construcción quede "documentado" únicamente en cerebro de alguna persona. Nunca te encontraras en una situación donde no puedes [soltar] un producto por que solo Shaniqua sabe como crear el instalador, y lamentablemente la atropello un autobús. En el equipo de Juno, lo unico que necesitabas saber para poder crear una construcción completa, era donde se encontraba el servidor de las construcciones y como darle doble-click en el icono de la "construcción diaria".
• No hay nada peor para tu tranquilidad que cuando intentas enviar tu código final, encuentras un pequeño error, así que arreglas ese pequeño problema allí mismo, en el servidor de las construcciones diarias. Como regla principal, solo deberás enviar código que haya sido producido de una construcción diaria completa que haya iniciado desde la reservación de los archivos.
• Asegura el nivel mas alto de prevención de errores (-w4 en mundo de Microsoft; -wall en la tierra de gcc) y póngale la opción para que se detenga si se encuentra con el mas mínimo problema o advertencia.
• Si la construcción del día se rompe, caes en riesgo de detener al equipo entero. Detenga todo y vuelva a intentar la construcción hasta que el problema sea resuelto. De ves en cuando podrías tener múltiples construcciones en un día.
• Su script de la construcción deberá reportar fallos, por medio de email, a todo el grupo de desarrollo. No es muy difícil extraer (grep) del log los errores ["error"] o advertencias ["warning"] e incluirlo en el email también. La construcción también puede anexar un reporte del estado actual a una pagina HTML visible a todos para que los programadores y probadores puedan determinar rápidamente que construcciones terminaron exitosamente.
• Una de las reglas que seguimos en el equipo de Excel de Microsoft, a grandes rasgos, era que quien rompiera la construcción del código seria responsable de cuidar todas las construcciones hasta que otra persona rompa el código de nuevo. Adicionalmente de servir como un hábil incentivo para mantener el código de la construcción, termina rotando a casi todos como master de construcciones para que todos aprendan como son producidos las construcciones.
• Si todo el equipo trabajo se encuentra en la misma zona tiempo, una buena hora para hacer la construcción es a la hora de la comida (almuerzo). De esa manera todos registran su código mas reciente ante de salir a comer, la construcción se ejecuta mientras están fuera, y cuando regresen, si la construcción se rompe, todos están cerca para arreglarlo. Apenas se arregle la construcción todos pueden reservar una copia del código mas reciente sin temer a ser responsables del fracaso de la construcción.
• Si el equipo trabaja en dos zonas de tiempo diferentes, programa la construcción del día a una hora que los integrantes de un equipo no interrumpa a los que trabajan en la otra zona de tiempo. En el equipo de Juno, el grupo de Nueva York registraba su código a las 7 PM hora de Nueva York y luego se iban a casa. Si ellos rompian la construcción, el grupo de Hyderabad, India, llegaban a trabajar (a las 8 PM hora de Nueva York) y estarían completamente detenidos durante todo el día. Empezamos a ejecutar dos construcciones por día, aproximadamente una hora antes de que se fuera a casa cada uno de los equipos, y de esta manera queda resuelto completamente el problema.

Si desea leer mas sobre este tema consulte:

• Un poco de discusión sobre herramientas para construcciones diarias.
• Hacer construcciones diarias es tan importante que es uno de los 12 pasos para mejorar tu código.
• Hay muchas cosas interesantes sobres las construcciones hechas (semanalmente) por el grupo de Windows NT en el libro de G. Pascal Zachary titulado "Showstopper".
• Steve McConnell escribe sobre el tema de la construcciones diarias aquí.