Errores de Programación

Antes de culpar a otro desarrollador, comprueba tu código.

Todos los desarrolladores, todos nosotros, a menudo cometemos errores y el programa deja de funcionar. Es muy improbable que ese mal funcionamiento del programa se deba a factores externos.

Sí, es la verdad, es muy (extremadamente) improbable que el código se rompa por un fallo (bug, en el argot) del compilador, del intérprete, del sistema operativo, del servidor, de la base de datos, de la memoria, o cualquier otra parte del hardware. Sí, es verdad queeste tipo de bugs existen, pero seamos francos, son mucho menos comunes de lo que a veces queremos hacer ver al cliente.

Es cierto, que en estos 16 años de desarrollo, me he enfrentado al algún problema real con el compilador, el en enlazador, con alguna librería, con el Sistema Operativo, con la gestión de memoria e incluso con el hardware. Estos problemas existen y nos han hecho perder mucho tiempo, desafortunadamente o bien se arreglan con una actualización del Sistema Operativo o una pieza del Hardware, o bien con alguna actualización de las herramientas de desarrollo, o sorteándolos de forma un poco artesanal.

Pero centrémonos en los bug originados por los desarrolladores finales.

Tras varios años de trabajo, he detectado cuatro causas por las que principalmente se comenten errorres:

  1. Hemos de tener en cuenta que muchas veces la naturaleza del software desarrollado, implica compatibilizar diversos entornos de desarrollo, librerías e implantaciones físicas. Esta mezcla de entornos, suele causas de errores de muy difícil solución. Normalmente nos hace contactar con las partes implicadas para lograr arreglar el error, unas veces con un buen resultado y otras veces no. Tiempo y dinero, que a veces nos obliga a volver a desarrollar de nuevo.Hemos de minimizar esta interacción.

  2. Muchas veces, un desarrollador tiene diversas tareas a su cargo y no se centra al 100% en la tarea que tiene entre manos. Estos provoca errores, por falta de tiempo y atención a la tarea asignada. Afortunadamente, si el desarrollador y el jefe de proyecto son personas competentes, cuando ven que algo empieza a ir mal debido a este particular, reorganizan su trabajo. Reorganizar el trabajo, es una forma fácil de aumentar la efectividad (menos errores) y productividad (menor tiempo dedicado a la tarea).

  3. Las pruebas, antes de enviar el producto al área de Control de Calidad, debería dedicar un 30% del 100% del tiempo reservado para el desarrollo. Hemos de ser concienzudos y escrupulosos a la hora de realizar la batería de pruebas. Debido a que esta es la peor parte que solemos hacer, es donde se nos escapa un porcentaje de errores que fácilmente podríamos haber visto y nunca tendrían que haber llegado al Control de Calidad.

  4. Y la última, por ello no menos importante, es la falta de formación, conocimientos y capacidades para la tarea asignada.

Por eso, antes de asumir que otros han cometido un error, cuestiónate, si has sido tú el que ha podido errar.

Tags:

No comments yet.

Deja un comentario