Antipatrón: pensar en cambios

A diario nos enfrentamos con problemas, y con frecuencia caemos una y otra vez en los mismos errores, siguiendo unas conductas que nunca llevan a nada bueno pero que nos obstinamos en repetir. La wikipedia recopila algunos de estos antipatrones. Me gustaría añadir uno que suelo ver y que también considero negativo.


En caso de error pensar qué hemos cambiado
A veces (con demasiada frecuencia) nos encontramos con que algo "ha dejado de funcionar". En mi opinión, buscar cambios es una tarea inútil:
  • Parte de que la premisa de que antes estaba bien, lo cual no tiene por qué ser cierto. Podría ser que nuevos datos hayan hecho aparecer un fallo que antes estaba oculto, podría haber cambiado algo en el servidor, en la configuración... 
  • Rara vez se programa solo, así que lo normal es que varias personas pudiesen estar implicados en una misma línea. 
  • Aún suponiendo que antes estaba bien, para comparar hay que localizar una versión correcta y analizar el cambio, y ver por qué se hizo... 
En mi opinión es mucho mejor centrarse en el error para localizar el problema.

Corolario: hay que leer las excepciones, y depurar, incluso a través del código de las librerías.

Posted by Juan Ignacio Sánchez Lara 18:52  

4 Comments:

  1. Joserra said...
    Te doy la razón parcialmente ;)
    Centrarse en el error es clave, pero pensando en el objetivo de funcionamiento correcto!
    A veces te zambulles en stacktraces (otro tema es que hay que aprender a leerlas), lineas de código,...etc... solucionas aparentemente el error, ero has perdido el foco del requerimiento a cumplir.
    Ender Wiggins said...
    un buen log es fundamental, por supuesto.

    Y tienes razón; suponer que la cosa funcionaba bien es el peor error que se puede cometer, porque puedes perder mucho tiempo.

    Lo primero es identificar el alcance del error; si el error no lo ha detectado el equipo de calidad del software, la descripción del error suele ser muy vaga, proque los usuarios no piensan de la misma manera. Hay que acotar, cuando, como ocurre. y tendrás más cerca el porqué. Ir acotando casos, ver el caso más simple que produzca el error. De esta manera, incluso antes de meterse al código, ya tienes una idea de por dónde van los tiros.
    Nacho said...
    Justo me pillas escribiendo una miniguía con recomendaciones para resolver un error. Con tu permiso, añado la de buscar el caso más simple que produce el error, que no había caído en poner y es muy importante.
    Ender Wiggins said...
    no problem. uno ha sido ingeniero de calidad del software antes que arquitecto y algo tenía que quedárseme :-)

Post a Comment