En nuestra carrera como programadores nos vamos a encontrar, en mayor o menor medida, con errores que vamos a tener que encontrar y solucionar, y que dependiendo de nuestras experiencias vamos a tomar decisiones para corregirlos. ¿Pero que pasa si no tengo la suficiente experiencia? ¿Por dónde empiezo?. Este post viene a tratar de ser una guía para aquellos que necesiten responder estas preguntas. Sin más que agregar comencemos.

Errores

Para poder tratar de no poner todo en la misma bolsa, los errores en nuestro código pueden deberse a múltiples causas y por ende no vamos a actuar de la misma ante diferentes tipos de errores. En este post vamos a tratar dos errores comunes que ocurren en nuestro día a día como programadores, que son los errores de código y los errores de diseño.

Ejemplo Error de código

Programamos en el lenguaje Java y seguimos el paradigma orientado a objetos, tenemos una calculadora que hace divisiones, y contamos con el siguiente código:

Con lo cual en nuestro método main utilizamos ese objeto para hacer divisiones:

Lo que vemos en consola es lo siguiente:

Ahora bien este código funciona como ya vemos para ciertos casos, pero para este caso nos encontramos con un error:

Lo primero que debemos hacer es mirar la consola o en su defecto los logs, si es que lo tenemos en un archivo aparte. Siempre el primer paso es mirar los logs, estos nos dan la información concreta del fallo que hemos tenido.

Nos encontramos con esta impresión en consola/logs:

En el caso de que no entendamos cuál es el significado del log lo siguiente es utilizar al buen amigo Google, seguramente a alguien ya ha tenido que lidiar con este error y nos pueda brindar más información:

Este error es muy fácil de entender sin la necesidad de buscar en Google, pero la práctica para otro tipo de errores que tenemos que incorporar es esta. Si bien podemos encontrar infinidad de soluciones en internet esta claro que tenemos que entender lo que estamos leyendo y no copiar y pegar soluciones mágicas sin entenderlas, no tiene ningún mérito hacer eso ya que no aprendemos nada y podríamos estar incorporando otro error sin darnos cuenta. Además al entender la solución que nos brindan generamos la capacidad de adaptar esa solución a nuestro caso en particular, ya que no siempre tendremos el caso exacto resuelto en internet y tendremos que adaptarlo a nuestro código.

Yo elijo que el error este en español y sea más claro para mí, por lo que cambio la implementación para que ahora lance una excepción personalizada de la siguiente manera:

Para este caso siempre es una buena practica mantener la información, en este caso de la excepción origen:

Recapitulando los posibles pasos a seguir para este tipo de errores sería:

1. Leer la consola/logs.
2. En el caso de que no sepamos que significa el error buscamos el Google el error.
3. Tenemos muchas respuestas, tratamos de entender que es lo que esta pasando y si nos dan una solución JAMÁS copiamos y pegamos sin entender.
4. Una vez entendido el problema podemos o no utilizar la respuesta adaptándola a nuestro caso.

Ejemplo Error de diseño

Suponemos que tenemos el mismo programa que se encarga ahora de Multiplicar y quienes usan nuestra aplicación nos informan que encontraron un caso en el que la operación les da un resultado erróneo. "Cuando multiplico 100 por 1000 me da como resultado 99."

Lo primero que tenemos es el caso que nos representa el usuario, es una información muy relevante, en este caso la explicación de lo que le pasa es clara pero hay casos en los que el usuario no se sabe explicar por lo que tendremos que indagar un poco más.

Lo segundo que tenemos que hacer es reproducir el caso que nos mencionan, ya sea de manera práctica o si utilizamos la práctica de desarrollo TDD hacemos un caso de test para ese caso en particular.

Ya tenemos el test o hicimos la prueba, bien, estamos seguros que ese caso no esta cubierto, perfecto, lo siguiente es entender como esta diseñada la solución, esto es una recomendación, ya que me resulta más simple de entender un diseño si lo veo representado en uno más tipos de diagramas con el que pueda tener un panorama claro de en qué consiste la solución, además de que no siempre nos vamos a encontrar con un desarrollo hecho full por nosotros y que lo conozcamos a la perfección, de hecho en nuestra carrera profesional vamos a entrar en nuevos proyectos que en su mayoría van a estar avanzados y van a ser muy grandes, y encontrar bugs de diseño en ese tipo de proyectos suele ser difícil incluso aplicando algunos de estos consejos.

 

Revisando MagiaNegra nos encontramos con el error.

Una vez identificado el problema nos encargamos de diseñar una solución al problema, es decir diagramar nuevamente los pasos a seguir para resolver el bug. Para esto yo recomiendo tener más de un diseño para que compitan y ver cuál es el mejor. Para que compitan tenemos que hacer la tarea de definir los pros y contras de cada uno y luego si, con esa información definir cuál va a ser el que aplicaremos.

Por último una vez aplicada la solución deberemos ejecutar el test o la prueba manual nuevamente y ver que ahora si la respuesta sea la esperada.

Posibles Pasos para encontrar y resolver errores de diseño:

1. Hablar con el cliente del comportamiento no esperado que esta obteniendo, si es que es posible, relevar hasta comprender bien.
2. Una vez entendido el paso anterior hay que replicar el error mediante una prueba manual o creando un nuevo test si estamos aplicando TDD para desarrollar.
3. Entender en profundidad la solución con la que trabajamos, es decir si el proyecto es complejo es buena idea diagramar o ver un diagrama para entender, puede ser un diagrama de flujo, clases o secuencia (Este paso es opcional por si hay dudas o sos nuevo en el proyecto y todavía no se comprende la solución)
4. Nos encargamos de diseñar una solución, para ello recomiendo tener más de un diseño para que se pueda hacer una comparativa y quedarnos con el mejor diseño posible
5. Implementar la mejor solución y asegurarnos de que cumple corrigiendo el error del cliente y obviamente no estemos rompiendo una funcionalidad pre-existente, para ello TDD reduce mucho la posibilidad de romper algo que funcionaba pero no nos da el 100% de seguridad de incorporar un nuevo bug.

Muchas gracias por leer este post, este no trata de ser palabra santa de lo que hay que hacer ante un error de algunas de estas características si no como bien mencioné al comienzo una guía para los principiantes o los que ya han tratado de resolver un error y aun no creen haber agotado todas las opciones para ello. Nos vemos en próximas entregas.