jueves, 8 de enero de 2009


Supongo habran sabido que los zunes se suicidaron el pasado 31 de diciembre. Un zune es un aparato de hasecorp medianamente parecido a iPod. Al grano, resulta ser que una validación mal hecha en la función de calculo de la fecha tenia la condición if (days > 366) para darse cuenta de los años bisiestos pero deberia ser if (days >= 366), es decir, mayor o igual. Como la comparación esta mal y solo pregunta por mayores entonces el día 366 de un año bisiesto no entra a la condición, que desafortunadamente esta puesta dentro de un ciclo así que el zune se quedo ahí de por vida el 31 de diciembre. Les dejo el fragmento de código fuente.

while (days > 365)
{
if (IsLeapYear(year))
{
if (days > 366)
{
days -= 366;
year += 1;
}
else
{
days -= 365;
year += 1;
}
}
}

Pueden ver el código fuente completo aquí


El caso de esto es una muestra de que un pequeño descuido en la programación puede crear problemas futuros inimaginables bajo quien sabe que circunstancias. En mi trabajo ultimamente me dedico más al analisis y desarrollo de aplicaciones nuevas así cuando es necesario dar mantenimiento o agregar funcionalidades simples a mis aplicaciones ya terminadas suelo recurrir a un programador cualquiera del centro para que el haga la talacha aburrida. Por un lado es comodo, por otro es un volado. Esta semana estuvimos a punto de meternos en un broncon por una falla en la programación casi tan simple como ese del mencionado zune, una consulta dirigida en dirección equivocada y voila, hiba a sobreescribir información y por más suerte que merito encontre el bug antes de que lo pusieran a trabajar en el ambiente final, y eso que la aplicación ya la habia probado el área de beta testers, según.


El caso es que me ha tocado ver de manera relativamente frecuente fallos de programación así y por lo regular la causa es el uso de programadores que no rinden cuentas directamente si no que "la bronca es del lider" y por lo tanto salen las cosas como sea nada más para decir que se hizo pero el resultado es que las posibles excepciones o situaciones extrañas no estan validadas ni probadas y por eso pasa lo que pasa. El estar apurando los tiempos de entraga y dejar que las pruebas sean un mero requisito hecho por decir que se hizo no coopera, cuanta razón tienes Fuckwoski.


Me acorde del ultimo juego de Tomb Raider, muchos errores de programación sin testear.

0 comentarios:

Publicar un comentario

Por favor trata de escribir bien, no te pido que no te falte ni un acento pero por favor evita escribir como metroflogger o facebookero. Este blog es un sitio decente. Gracias.

Subscribe to RSS Feed Follow me on Twitter!