Encontrando errores en tu codigo

Hacer software no es tarea fácil, dominar y ejecutar este arte es tarea ardua y digo arte porque al final termina siendo el ejemplo más próximo de lo que hacemos los ingenieros de software. Arte en el momento que convertimos sentencias if/else/while en complejos sistemas informáticos. Para llegar a dominar este arte primero es necesario dominar la técnica y para lograr el dominio de la técnica es necesario la ejecución repetitiva durante horas y horas de práctica en la cual nos enfrentemos a diversos ejercicios que nos permitan llegar a dominarla.

El ejemplo más claro para entender esto es lo que sucede con los deportes, piensen en el deporte que más les gusta (en mi caso el tenis), pueden haber visto miles de partidos, entender de qué se trata, conocer las reglas de arriba abajo, conocer los movimientos, pero el ejecutarlo ya es otra cuestión, encontrar el swing perfecto para el golpe, el movimiento de rodillas, cadera y brazos tomará horas, semanas e incluso años en lograr dominarlo, es por esto que conocer de algo no es igual a saber ejecutarlo. Por lo anterior, es preciso empezar primero con cientos de ejercicios diferentes que nos permitan conocer la técnica y una vez domines la técnica podrás empezar a perfeccionar tu arte; este arte será el que te haga distinguirte de los demás o ser uno más del montón que aprendió hacer algo y se quedó ejecutando el mismo trabajo los últimos 20 años, será la perfección de tu arte que permita que las personas digan “llámenlo a él, él sabrá cómo resolverlo” y no es porque necesariamente ya lo hayas resuelto antes sino tu capacidad de resolver problemas te da un factor diferenciador. 

Quiero compartir contigo un par de tips para la resolución de problemas. Lo siguiente lo considero mi mantra para la resolución de problemas o bugs, no considero que es la mejor, se que no es la única, simplemente es la mía y quiero compartirla contigo y pueda servirte en algún momento:

  1. Debes empezar a leer detenidamente y compilar mentalmente que es lo que está sucediendo, compilar mentalmente consiste en leer línea a línea el código e ir reemplazando las variables por sus valores, esto es conocido como prueba de escritorio.
    En lo posible ejecuta tu depuración (debug) con voz alta la cual ayudará a tu cerebro a aclarar las ideas, verás que leyendo línea a línea y preguntándote si está bien o no es una ayuda invaluable.
  2. Si el problema de compilación o runtime aún no se soluciona empieza a eliminar líneas de código que hayas hecho recientemente y no hayas aún verificado que funciona, esto te permitirá ir descartando errores de lo último que acabas de agregar y una vez encuentres el error podrás agregar nuevamente el código eliminado.
  3. Una técnica que considero infalible consiste en echarle la culpa algo de tu código y verificar si es esto lo que falla y en caso de no ir descartando, un error muy frecuente que cometen las personas es pensar que algo tiene el problema y quedarse dando vueltas en el mismo punto durante horas, considero es mucho mejor si empiezas a culpar a un if, luego al else y de esta forma vas verificando funcionamiento y descartando potenciales errores que no son.
  4. Usa el método de depuración del patito de goma el cual consiste en tratar de explicarle a alguien que es lo que sucede en tu código, muy parecido a lo que hiciste en la línea uno pero ahora tratando de explicarlo a un ser imaginario o si tienes un compañero que te escuche mucho mejor, ya verás que en el momento que estés haciendo la explicación línea a línea de lo que está haciendo tu código, tu solo encontrarás la respuesta. Lo anterior tiene una explicación psicológica, al tratar de explicar a alguien que no sabe que está sucediendo debes desenredar primero el nudo mental que tienes que no te deja avanzar para poder hacerle entender. Desenredando este nudo la solución se presentará ante ti.
  5. Si nada de lo anterior funcionó, para! no continúes, si continuas caerás en un estado de frustración el cual no te ayudará en nada a tu problema,  una ida a tomar cafe y continuas al rato te ayudará.

4 comentarios en «Encontrando errores en tu codigo»

  1. Tambien se podría incluir en el primer paso si el problema es muy complejo o te cuesta repasarlo mentalmente, dibujar el diagrama de flujo ayuda aclarar tu mente y puedes compartirlo con un colega para verificar que si cumple con lo que esperas

    Responder
  2. Esta buena y concisa la información que compartes, muchas gracias. Para estos casos de errores en porciones de código, me apalanco mucho de test unitarios, si existen deberían estar fallando, si no existen los creo.

    Responder
  3. Totalmente de acuerdo y más con el punto 4, esa nunca falla.
    La prueba de escritorio si la recreo en un excel, notepad o una hoja y lápiz. Devolverse a un diagrama de secuencia, Estados, o un simple diagrama de flujo de proceso ayuda mucho también. Pero me quedo con la 4.

    Responder
  4. Parce algo que nunca hace nadie al acercarse a los bugs es leer los logs. Creo que lo puede poner en lo primero que hay que hacer… Leer los logs de los errores, entender si en ese log hay la suficiente información para saber que es, buscar en Google en el caso de errores de librerías para saber si la excepción me da pistas. Después todo lo que dices tiene sentido pero si hay un sistema de manejo de excepciones y reporte en un log, lo primero para mí es ir a leer. Hay que leer! Dicen por ahí 🙂

    Responder

Deja un comentario