10 Consejos para la resolución de problemas técnicos inexplicables
En ocasiones, compañeros de trabajo y otros conocidos acuden a mi con problemas técnicos difíciles (deprogramación, sistemas, etc.) incomprensibles y/o aparentemente inexplicables, tratando de que les echeuna mano en la búsqueda de una solución. Supongo que me he ganado fama de "gurú técnico" a base deencontrar soluciones inesperadas a problemas extraños (qué engañados les tengo a todos :-) Seguro que sitrabajáis con temas técnicos, habéis escuchado multitud de veces frases como estas:
No lo entiendo! Pero si ayer funcionaba y no he tocado nada!Lo he probado todo y no soy capaz de saber por qué falla!Esto es imposible! Pero si el programa nunca debería pasar por ahí!Si en mi máquina funciona y todo está igual en esta otra, ¿por qué ahí no funciona?
He hecho un ejercicio de reflexión para tratar de analizar las reglas que inconscientemente aplico a lahora de tratar de resolver algún problema, esas reglas que sólo se aprenden a lo largo de añosenfrentándote a este tipo de situaciones. Quiero compartir con vosotros algunos consejos/conclusionesque he sacado de esta reflexión, espero que os sirvan:Consejo 1: Simplifica el problemaCuando te enfrentas a un problema complejo suele haber muchas variables que pueden influir en él. Enese caso, hay que tratar de reducir el problema a su mínima expresión, para poder tratarlo sin tantasvariables que introducen ruido al asunto. Muchas veces, cuando estás tratando de reducir el problema auno más simple, das con la solución.Ejemplo: Imagina que tienes una aplicación que estás programando, que consta de 1000 archivos ymás de 100.000 líneas de código. Tienes un problema con un archivo de la aplicación,concretamente en un método de una clase que no se comporta como debería. En ese caso, lo ideales aislar ese método y tratar de probarlo independientemente del resto de la aplicación. Si esposible, además, quitar todas las líneas del método que no sean relevantes para el problema, hastadejarlo reducido a su mínima expresión. Como digo, muchas veces aplicando este procedimiento desimplificación te das cuenta de la causa del problema.Consejo 2: Se metódico en las pruebas Lo primero que hay que hacer a la hora de enfrentarse un problema,aún a riesgo de parecer un autómata, es SER MUY METÓDICO. El más claro ejemplo de esto es que si paracomprobar que algo funciona estás realizando las pruebas de una determinada manera, las realicessiempre de la misma forma y en el mismo orden (aunque creas que lo que estás cambiando no puedeafectar al resultado!!!).Ejemplo: Si estás realizando las pruebas en una máquina, hazlas siempre en la misma (aunque hayaotra exáctamente igual). El cambio de máquina muchas veces introduce ruido en las pruebas(siempre suele haber problemas con idiomas distintos, encodings - UTF8, etc.).Ejemplo: Si para las pruebas estás lanzando dos scripts en un derminado orden, aunque los scripts
Blog de Manuel Pereira Gonzalez: 10 Consejos para la r...http://manuelpereiragonzalez.blogspot.com/2010/10...1 de 508/02/11 01:55
sean independientes (teóricamente el orden no sea relevante), lánzalos siempre en el mismo orden.Consejo 3: No mates moscas a cañonazos, primero Reflexiona! Muchas veces cuando uno estáenfrentándose a un problema incomprensible, tiene la tentación de "empezar de cero". Yo soy de laopinión de que esta tiene que ser la última solución, antes hay que tratar de descartar todas las otras vías.Volviendo a empezar de cero, corres el riesgo de tardar más de lo necesario, o lo que es peor, trabajardurante días rehaciendo algo para luego encontrarte con el mismo problema.Ejemplo: En nuestro día a día trabajamos a diario con las herramientas
Maven, JDK1.6, Eclipse,
etc.Tengo un compañero (con cariño eh!) que cada vez que no le funciona algo se lanza a reinstalarWindows, y todas las herramientas necesarias. Suele tardar un par de días en reinstalar todo, yalgunas veces, cuando ha terminado, vuelve a probar lo que fallaba y... sigue fallando!. Muchasveces, si se hubiese parado a reflexionar sobre el problema en lugar de "tirar por la tangente",habría ahorrado mucho tiempo y esfuerzo.Consejo 4: La máquina tiene la presunción de inocenciaLo que he aprendido a lo largo de muchos años es que lo más probable frente a un error es que el culpablesea el ser humano, no la máquina. Lamentablemente en estos casos la presunción de inocencia es para lamáquina, y no para ti :-(Ejemplo: Mucha gente, cuando algo no funciona, culpa a problemas en el hardware (las típicasfrases "Eso es que la memoria está corrupta" o "A lo mejor el disco duro tiene clusters defectuosos").La mayoría de las veces suele ser problema del programa, no del hardware.Ejemplo: Siempre me acuerdo de un antiguo compañero de trabajo que a menudo, cuandoencontraba algún problema en Java aparentemente inexplicable, culpaba a la Java Virtual Machine."Tiene que ser un error de la JVM!!" - decía. Siempre se confirmó que eran errores suyos en el código.Consejo 5: A veces es más fácil hallar la solución que la causaEn ocasiones la gente se ofusca tratando de buscar la causa a un problema. Pasan días tratando deencontrar el por qué... cuando a veces existe un "atajo" (los ingleses lo llaman
workaround
) que te hacesolucionar el problema, aunque no encuentres qué era lo que lo producía. Hay ocasiones en las que hayque saber rendirse ante el enemigo, y siendo prácticos, dejar atrás nuestra necesidad innata de conocer elpor qué de las cosas. Ojo porque tampoco hay que abusar de esto, puede convertirse en un arma de doblefilo (cada uno tiene que saber poner límites prácticos a su curiosidad, sobre todo si te pagan por producir;-)Ejemplo: Un conocido tenía un problema con un programa en Java que se suponía que eracompatible con la JDK1.3 y superiores. El tipo llevaba semanas persiguiendo el problemaejecutando el software con la JDK1.4, y no era capaz de encontrar la causa. Después de variosintentos fallidos de conocer la causa, le pregunté si había probado a ejecutarlo con la JDK1.3. Surespuesta fue que la 1.4 era compatible con versiones anteriores, por tanto si funcionaba con la 1.3debería de hacerlo con la 1.4. "Muy bien" - le dije - "¿pero lo has probado?". Insistí en ello, y al
Blog de Manuel Pereira Gonzalez: 10 Consejos para la r...http://manuelpereiragonzalez.blogspot.com/2010/10...2 de 508/02/11 01:55
probarlo con la 1.3 el error dejó de producirse. Nos quedamos con ganas de saber qué es lo queproducía el error... pero solucionamos el problema!Ejemplo: La semana pasada un tipo me llamó porque estaba detectando errores de intentos fallidosen la conexión a SQL Server en un servidor. Después de darle muchas vueltas, probé a detener elservicio "Microsoft Reporting Services", y el error dejó de producirse. El tipo dijo: "
¿Pero por qué ese servicio trata de conectarse a SQL Server? No lo entiendo
", a lo cuál le respondí con otra pregunta:"
¿Usas el servicio de Reporting Services o lo vas a usar en un futuro?
". "
No
" - respondió. "
Entonces me da igual saber por qué trata de conectarse, dejamos el servicio apagado y problema solucionado
".Consejo 6: Si ayer funcionaba y hoy no, algo ha cambiadoCuando alguien viene a mi con la típica frase "
Pero si ayer funcionaba y no ha cambiado nada!
" siempre lerespondo lo mismo: "
Como mínimo ha cambiado algo: La fecha
". Si estás en la típica situación en la que tefuiste el día anterior dejando algo funcionando y hoy ya no funciona, intenta pensar
verdaderamente
quépuede haber cambiado, y echa para atrás todo lo que haya cambiado para volver a la situación en la quefuncionaba. Después vuelve a hacer los cambios probando uno a uno, para ver cuál es el que introduce elproblema.Ejemplo: El día 19 de Septiembre estuve mejorando el Crawler para el BOCM del proyectowww.booletin.es. Para identificar hasta dónde llega la fecha de un boletín en una cadena de texto(Por ej: "19
de Septiembre de 2010. Bla bla bla
"), estaba buscando "
20
" en la cadena de texto, y así identificaba dónde se encontraba el año en la fecha, y sabía por dónde cortar. Todo funcionaba biencon los boletines desde el 1 de Septiembre hasta el 19. Sin embargo, al día siguiente (20 deSeptiembre) volví a probar el programa y fallaba. "
Pero si no he cambiado nada!
"- pensé. Sinembargo sí que había cambiado algo, el día del mes. El algoritmo funcionaba con todos los días delmes menos el día 20, ya que cortaba la cadena "
20 de Septiembre de 2010. Bla bla bla
" justo despuésdel primer "
20
", y no después del año como pretendía.Consejo 7: Pregúntale (bien) a GoogleNo creo que exagere si afirmo que el 90% de los problemas extraños se resuelven sabiendo buscarcorrectamente en Google. Cuando nos enfrentamos a un problema, lo más probable es que ya le hayapasado antes a alguien. Internet está lleno de foros en los que la gente plantea sus dudas/problemas, y enlos que hay multitud de respuestas a ellos.Cuando me enfrento con un problema y ando perdido, acudo aGoogle y le pregunto. Es muy importante
saber buscar bien
, para encontrar lo que buscas. Para buscaralgo, trato de buscar
palabras distintivas
de lo que ando buscando (es decir, palabras que debería decontener el documento que estoy buscando, y no deberían de contenerlas otros documentos que nobusco).Ejemplo: La semana pasada un compañero de trabajo experto en tecnología J2EE (un arquitecto delos buenos) estaba buscando la solución a un problema con la herramienta Maven. Llevaba más dedos horas buscando en google y no encontraba nada. Me pidió que le echase una mano, y en cincominutos (buscando los términos correctos en google) dimos con la solución.
Blog de Manuel Pereira Gonzalez: 10 Consejos para la r...http://manuelpereiragonzalez.blogspot.com/2010/10...3 de 508/02/11 01:55
Search History:
Result 00 of 00
00 results for result for
p.
