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)

El BASIC del TRS-80 tan sólo podía almacenar dos cadenas: A$ y B$. Igualmente, yo nací con sólo dos huecos para almacenar errores en mi cerebro. En un momento dado, sólo soy capaz de recordar dos bugs pendientes de solucionar. Si me pides que recuerde tres, uno de ellos se me caerá al suelo y será barrido bajo la cama con los Conejos del Polvo (Dust Bunnies), que se lo comerán.

Mantener una base de datos de errores es seña de un buen equipo de desarrollo de software. Nunca dejo de sorprederme por los pocos equipos que lo hacen. Uno de los fallo más comunes en los que continuamente caen los desarrolladores es creer que pueden recordar todos los errores o mantenerlos en notitas adhesivas. Si me prestan atención, me gustaría explicarles una manera bastante sencilla de llevar el seguimiento de errores, siguiendo el espíritu de mis artículos anteriores sobre planificación y especificación fáciles.

En primer lugar se necesita una base de datos de verdad. En equipos de dos personas escribiendo algo de código en un largo fin de semana, probablemente basta con un fichero de texto en lugar de la base de datos. Si se trata de algo más grande necesitará una base de datos de seguimiento de errores de verdad. Hay millones de bases de datos de seguimiento de errores a la venta (Auto anuncio descarado: la que hemos escrito en Fog Creek Software, llamada FogBUGZ, está basada en web, es muy fácil de usar y bastante potente, modestia aparte)

He aquí lo ocurrido realmente:

Mikey el Programador está codificando en una característica del cliente de FTP de su software tan chulo para Macintosh. En algún punto, como está juguetón, decide que va a usar su propia función de copia de cadenas. ¡Eso les enseñará a poner esas molestas políticas de reusabilidad de código! ¡Ja Ja Ja!

Pero cuando no se reutiliza el código ocurren cosas malas, Mikey. Y hoy, lo malo que ha pasado es que a Mikey se le olvidó terminar con un cero la cadena copiada. Pero no se dió cuenta porque la mayor parte del tiempo resultaba que copiaba cadenas en zonas de memoria que estaban inicializadas a cero.

Esa misma semana, algo más tarde, Jill la Ingeniero de Pruebas Muy Muy Buena está machacando el programa, tecleando con su cabeza en el teclado, o alguna otra práctica de pruebas igualmente cruel (casualmente, todos los probadores se llaman Jill o algo parecido como Gillian) De pronto, algo muy extraño ocurre: el demonio de FTP contra el que estaba probando se cae. Sí, ya sabemos que es una máquina con Linux y los servidores con Linux nunca se caen (que no gruña el personal de Slashdot, por favor) pero esta vez se cayó. Y ni siquiera estaba tocando el servidor, tan sólo estaba subiendo los ficheros por FTP usando el codigo para Mac de Mikey.

Ahora bien, Jill es una ingeniero de pruebas muy muy buena, así que ha llevado un registro muy detallado de lo que estaba haciendo (la inclinación y giro de su cabeza según la movía sobre el teclado está en su libro de laboratorio, por ejemplo). Lo reinicia todo, arranca con una máquina limpia, repite los pasos y -- ¡Oh, maravilla! -- vuelve a ocurrir. ¡El servidor de FTP de Linux se ha vuelto a caer! ¡Con esta van dos veces en un día! ¡Toma eso, Linus!

Jill introduce el nuevo error en la base de datos de errores. Ahora bien, sólo el acto de introducir un nuevo error requiere cierta disciplina: hay buenos informes de errores y malos informes de errores.

Los tres pasos a seguir para escribir un Buen Informe de Errores.

"Y de este modo se hará, primero deberá extraerse el punzón, luego se contará hasta tres, ni más ni menos. Tres es el número que se contará. Y el número de la cuenta será tres. No se deberán contar cuatro ni se contarán dos, salvo para seguir después a tres. Eliminado será el cinco. Una vez que se haya mencionado dicho número tres, se enviará cual rayo la Granada de Antioquía sobre el enemigo, que por su mal comportamiento será exterminado"

-- Monty Python, "Los caballeros de la mesa cuadrada"

Es muy sencillo recordar la regla para hacer un buen informe de errores. Todos los informes de errores necesitan, exactamente, tres cosas:

Parece fácil, ¿verdad? Tal vez no. Como programadores, la gente tiende a asignarme errores cuando en realidad pasaron por alto una cosa u otra. Si no me cuentas cómo reproducir el error, probablemente no tendré ni idea de qué estás hablando. "El programa se cayó y dejó un apestoso objeto con pinta de caca en el escritorio". Está bien, cariño. No puedo hacer nada con eso a no ser que me digas lo que estabas haciendo. Ahora bien, admito que hay dos casos en los que es difícil conseguir los pasos exactos para reproducir el fallo. A veces uno simplemente no se acuerda, o simplemente estás transcribiendo un problema que ocurre "en campo" (por cierto, ¿por qué dicen "en campo"? ¿Es como un campo de cereales o algo así?) El otro caso en que puede que no se tengan los pasos para reproducir el fallo es cuando el fallo ocurre a veces pero no todas las veces, pero aún así, habría que proporcionar los pasos para reproducirlos, con una nota que diga que no ocurre con frecuencia. En estos casos, va a ser muy difícil encontrar el fallo, pero por intentarlo...

Si no especificas lo que esperabas ver puede que no entienda por qué esto es un error. La pantalla de presentación está manchada de sangre. ¿Cómo dices? Me corté los dedos cuando estaba codificándola. ¿Qué esperabas? Ah!, di que las especificaciones requieren que no tenga sangre Ahora ya entiendo por qué lo consideras un error.

Tercera parte. Lo que ves en su lugar. Si no me dices esto, no sé cuál es el error. Esto es obvio.

Volvamos a nuestra historia

Allá vamos. Jill introduce el error. En un buen sistema de seguimiento de errores, el error automáticamente se asigna al desarrollador principal de ese proyecto. Y aquí radica el segundo concepto: cada error necesita asignarse exactamente a la misma persona todas las veces, hasta que es cerrado. Un error es como una patata caliente: cuando te la asignan, eres el responsable de resolverla de algún modo, o asignársela a otra persona.

Willie, el desarrollador principal, mira el fallo y decide que tiene probablemente que ver con el servidor de FTP, y lo resuelve como "no tiene arreglo". Después de todo, ellos no escribieron el servidor de FTP.

Cuando un fallo se resuelve, se vuelve a asignar a la persona que lo abrió. Este es un punto crucial. No desaparece simplemente porque el programador piensa que debería desaparecer: la regla de oro es que la única persona que abrió el fallo puede cerrarlo. El programador puede resolver el error, lo que quiere decir: "¡eh! creo que ya está hecho", pero para cerrar definitivamente el error y sacarlo de los libros, la persona que originalmente lo abrió necesita confirmar que ya ha sido arreglado o estar de acuerdo en que no debería ser arreglado por alguna razón.

Jill recibe un email que le dice que el error está de nuevo en su tejado. Ella lo examina y lee los comentarios de Willie, el Desarrollador Principal. Algo no tiene buena pinta. La gente ha estado usando este servidor de FTP durante años y no se cae. Sólo se cae cuando usamos el código de Mikey. Así que Jill reactiva el error explicando su posición, y el error se devuelve a Willie. Esta vez, Willie asigna el error a Mikey para que lo arregle.

Mikey estudia el error, piensa durante largo rato, y se equivoca por completo en el diagnóstico. Arregla un error completamente distinto y luego resuelve el que abrió Jill.

El fallo se devuelve a Jill, pero esta vez marcado como "RESUELTO-ARREGLADO". Jill sigue los pasos para reproducir el error con la última versión compilada y, ¡oh maravilla!, el servidor de FTP de Linux se cae. Reactiva el error de nuevo y se lo asigna directamente a Mikey.

Mikey está perplejo, pero finalmente localiza el origen del fallo. (¿Sabes cuál es ya? Lo dejaré como ejercicio para el lector. Ya he dado suficientes pistas) Lo arregla, lo prueba y ¡Eureka! el caso para reproducir el fallo ya no hace que el servidor se caiga. Una vez más, lo resuelve como ARREGLADO. Jill también intenta reproducir los pasos y descubre que está todo arreglado, así que lo cierra.

Los 10 Mejores Trucos para el Seguimiento de Errores.

1. Un buen ingeniero de pruebas siempre intentará reducir los pasos de reproducción hasta dar con el mínimo número de pasos necesarios; esto ayuda bastante al programador que tiene que encontrar el error.
2. Recuerda que la única persona que puede cerrar un error es la persona que lo abrió en primer lugar. Cualquiera puede resolverlo, pero sólo la persona que vió el error puede realmente estar segura de que lo que vió ha sido arreglado.
3. Hay muchas maneras de resolver un error. FogBUGZ permite resolver el error como ARREGLADO, NO ARREGLADO, POSPUESTO, NO REPRODUCIBLE, DUPLICADO, o POR DISEñO.
4. NO REPRODUCIBLE quiere decir que nadie ha sido capaz de reproducir el error. Los programadores a menudo usan esto cuando el informe de fallos no tiene los pasos para reproducir el error.
5. Te interesará llevar cuenta de las versiones. Cada compilación del software que se le da a los probadores debería tener un identificador de modo que el pobre ingeniero de pruebas no tiene que volver a probar el error en una versión del software que no se supone que lo tiene resuelto.
6. Si eres un programador y no puedes hacer que la gente de pruebas usen la base de datos de errores, simplemente no aceptes informes de errores por ningún otro método. Si los de pruebas están acostumbrados a enviarte correos con informes de errores, devuélveles los mensajes con un escueto: "por favor, ponlo en la base de datos de errores. No puedo seguir los emails".
7. Si eres ingeniero de pruebas, y no puedes hacer que los desarrolladores usen la base de datos de errores, no les digas nada de los errores: ponlos en la base de datos y que ella les envie los correos.
8. Si eres programador y sólo algunos de tus compañeros usan la base de datos de errores, comienza a asignarles fallos en la base de datos. En algún momento cogerán la indirecta.
9. Si eres el jefe y parece que nadie usa la base de datos de errores que tanto dinero costó, comienza a asignar nuevas características del software usando la base de datos de errores. Una base de datos de errores también es una base de datos de características no implementadas.
10. Evita la tentación de añadir nuevos campos a la base de datos de errores. Una vez al mes, más o menos, alguien tendrá una gran idea sobre un nuevo campo en la base de datos. La gente siempre tienen todo tipo de grandes ideas, por ejemplo, llevar cuenta del fichero donde se encontró el error, llevar cuenta del porcentaje de tiempo durante el cual se puede reproducir el bug, llevar cuenta del número de veces que ha aparecido el error, llevar cuenta de qué versiones de qué DLLs estaban instaladas cuando apareció el error... Es muy importante no ceder ante estas tentaciones. Si lo haces, la pantalla de introducción de un nuevo error aparecerá con mil campos que no necesitarás rellenar y nadie querrá volver a introducir informes de fallos. Para que la base de datos funcione todo el mendo necesita usarla. Y si meter los errores de manera "formal" es demasiado trabajo, la gente buscará otras formas.

Si estás desarrollando código, incluso siendo un equipo de una única persona, sin una base de datos organizada que muestre todos los fallos conocidos en el código, simplemente vas a entregar un producto de baja calidad. En los buenos equipos de desarrollo de software, la base de datos no sólo se usa de forma universal, sino que la gente se acostumbra a usar la base de datos de errores para hacer sus propias lista de cosas pendientes, colocan la página de inicio del navegador apuntando a la lista de errores asignadas a ellos, y comienzan a desear poder enviarle al jefe de la oficina un informe de errores pidiendo que compre más Pepsi.