Saltar al contenido

Introducción a 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 una versión tan libre de bichos. De hecho, en la fecha de lanzamiento, confiabas en 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 tiempo después de la publicación, llegó tu primer informe de errores. El primer informe de error fue algo inocuo, un pequeño error ortográfico en un nuevo cuadro de diálogo. Luego, unos cuantos boletos más de errores pequeños, que rápidamente arreglaste y empujaste al repositorio.

Introducción a la programación defensiva en Python
Introducción a la programación defensiva en Python

Entonces sucedió, la peor pesadilla de todo desarrollador, un bicho reportado en su más preciada porción del sistema. Miras frenéticamente a través del código, a pesar de que lo conoces de memoria. ¿Cómo es posible que esa rama del código se haya ejecutado 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 ha ocurrido. Ni siquiera puedes reproducir el escenario en tu entorno de pruebas. Si tan solo 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 exista.

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 serviría más si alteráramos ligeramente nuestra percepción de esta realidad. Deberíamos escribir software como si estuviéramos planeando los defectos. Deberíamos escribir software a la defensiva, es decir, con calma, poniendo trampas para los inevitables y desprevenidos bichos.