Saltar al contenido

Minimizar los riesgos con la programación defensiva en Python

Es viernes por la tarde, y tu nuevo lanzamiento ha salido hace unos días. Tu semana comenzó con un sentimiento de orgullo y alivio, pero tu orgullo ha disminuido lentamente a medida que la semana avanzaba. Se necesitó mucho esfuerzo y dedicación para sacar un lanzamiento tan libre de bichos. De hecho, en la fecha de lanzamiento estaba seguro de que las próximas semanas serían tranquilas ya que los usuarios no tenían nada más que necesitar o querer.

Por supuesto, era demasiado bueno para ser verdad y no mucho después de la publicación de su primer informe de errores. El primer reporte de error fue algo inocuo, un error ortográfico en un nuevo cuadro de diálogo. Luego, unos cuantos pequeños errores más, que rápidamente arreglaste y empujaste al repositorio.

Minimizar los riesgos con la programación defensiva en Python
Minimizar los riesgos con la programación defensiva en Python

Entonces sucedió, la peor pesadilla de todo desarrollador, un bicho reportado en su parte más preciada del sistema. Miras frenéticamente a través del código aunque lo conozcas de memoria. ¡¿Cómo es posible que esa rama del código haya sido ejecutada en este escenario?! El código debe estar mintiéndote.

Avanza unos días en la caza de insectos, y todavía no tienes ni idea de cómo sucedió. Ni siquiera puedes reproducir el escenario en tu entorno de pruebas. Si tuvieras más información de depuración sobre el fallo…

La verdad te hará libre

Reconocerás este escenario si has estado escribiendo software durante un tiempo no trivial. Es molesto que, a pesar de tus esfuerzos, hayas enviado software roto, otra vez. No te preocupes, eso pasa.

Esta es la parte de la historia en la que revelo la bala mágica para resolver esto de una vez por todas. Desafortunadamente, no puedo, y no creo que tal cosa sea posible.

La verdad oculta es que todo el software tiene errores. Sin embargo, eso no significa que debamos rendirnos y no esforzarnos por la perfección. Sólo significa que nos beneficiaríamos alterando ligeramente nuestra percepción de esta realidad. Deberíamos escribir el software casi como si estuviéramos planeando los defectos. Deberíamos escribir el software a la defensiva, es decir, tranquilamente poniendo trampas para los inevitables y desprevenidos errores.