Si una hay una lección que la Ley de Murphy nos puede dar a todos los desarrolladores es que "Si algo puede fallar, lo hará". No sabemos como, cuando ni donde, pero aceptemoslo:
Nuestro código no es perfecto, y por distintos factores, puede ser proclive a fallas.
Entonces, en el caso particular de JavaScript… ¿Cuál es la manera más rápida para detectar la procedencia de un error? ¿Cómo detectamos que una petición Ajax esta fallando a ciertos usuarios? ¿Porqué a unos les ocurre un error al presionar el botón Comprar y a otros no? ¿Porqué… < inserte su error favorito aquí >?
En cierta forma, es un deber de nosotros utilizar mecanismos que ayuden en la detección temprana de errores y herramientas de registro de datos que permitan mantener un historial de variados tipos de eventos (errores, información detallada sobre acontecimientos, advertencias, etc). Pero además, una vez detectado un problema, necesitamos herramientas que nos permitan depurarlo en variadas condiciones.
Por otro lado, en un ambiente de desarrollo puede que sea fácil encontrar en donde se encuentra un error, podemos modificar nuestros archivos sin consecuencias… ¿pero si el error sucede sólo en producción (es decir, en el sitio público)?
Me gustaría hablar un poco del asunto yendo por partes:
Detección de errores
La idea es poder detectar, en el contexto de la aplicación, cuando un error (o evento) sucedió y tener un registro de ello. No se debe confundir estos mecanismos con la utilización de herramientas que mejoran la calidad del código como las pruebas unitarias o herramientas de análisis (aunque si las utilizamos apropiadamente existirán menos posibilidades que un error ocurra). Un ejemplo de lo que queremos detectar puede ser: tener un registro cada vez que existe un error JavaScript en el navegador de cualquier usuario y obtener la mayor cantidad posible de información para poder reproducirlo y analizarlo.
- Una solución es la utilización de algún framework JavaScript dedicado al registro de información. Por ejemplo, log4javascript es una herramienta que ya tiene varios años de desarrollo (aunque su última versión es del 2009). La parte más interesante es su utilización con AjaxAppender el cual permite enviar a un server log la información del error (o lo que queramos registrar) para su posterior análisis.
- Otra alternativa es crear nuestra propia versión del controlador de errores. Justamente el ejemplo mostrado utiliza jQuery para enviar la información al servidor, ¿pero que sucede si el error es la misma biblioteca? Muchas veces es importante pensar en soluciones que puedan actuar de manera independiente ;)
Depuración JavaScript
Una vez que hemos sido notificados sobre el error, necesitamos depurar el código para saber porqué sucede y cómo lo vamos a solucionar. Sin embargo, en el ambiente productivo, pueden existir varios factores que dificulten el proceso:
- El error puede ocurrir sólo allí y no es posible reproducirlo en nuestro ambiente de desarrollo (por ejemplo por existen diferentes datos en la base, diferentes concurrencias, etc);
- Si se realizaron ajustes de optimización, los archivos JavaScript pueden estar empaquetados y comprimidos en uno solo;
- La aplicación puede ser compleja y hacer uso de muchas características: Modificación del DOM, variadas peticiones Ajax, validaciones…
Veamos algunas herramientas, trucos y cuestiones útiles para estos momentos, desde cosas básicas a otras más avanzadas:
- Cada desarrollador posee una herramienta de depuración por excelencia: Firebug, Chrome Developer Tools, IE Developer Tools, Dragonfly, etc. Todas proveen una forma para poder registrar mensajes de eventos en la consola a través de diferentes métodos (
console.log(), console.dir(), console.trace()…). Sin embargo no es recomendable dejar estos registros en nuestro código: sólo funcionan si tenemos la consola abierta, caso contrario aparecerá un error JavaScript similar a ‘console’ is undefined). De todas formas, si necesitamos dejar los mensajes en el código, una manera segura puede ser la que plantea Paul Irish o escoger otras alternativas un poco más robustas basadas en la misma idea. Notar que, por ejemplo, el JavaScript de Facebook que inserta el botón “Like” utiliza de forma segura el console.log() para registrar mensajes cuando existe un error (pueden comprobarlo buscado FB.log en dicho JS), por lo cual no es una práctica prohibida.
- Al utilizar alguna de las herramientas de depuración mencionadas, es fundamental aprender el manejo y funcionamiento de los puntos de ruptura (breakpoints). En la web de Firebug se pueden encontrar varias demostraciones para aprender a utilizar esta funcionalidad, de igual forma en la documentación de Chrome Developer Tools.
- Teniendo en cuenta que el archivo JavaScript a depurar puede estar comprimido (o fue mal deployado en producción, por ejemplo, con una versión antigua), un buen truco es el que describió Nicholas Zakas hace un tiempo: Utilizar Fiddler para poder cargar una versión local legible del archivo a depurar. De esta forma, Fiddler se encarga de filtrar las peticiones al servidor, y cuando encuentra al archivo conflictivo, carga la versión local en lugar de la remota, permitiéndonos realizar cambios sin correr riesgos. En mi experiencia este método es muy efectivo, sin embargo, es sólo válido para Windows (ya que Fiddler sólo funciona en ese SO). Una alternativa igual de efectiva para todos los sistemas es utilizar a Apache como proxy cumpliendo la misma función que Fiddler.
- Siguiendo la problemática de tener archivos comprimidos difíciles de depurar, hay varios nuevos features de Chrome Developer Tools que permiten ayudar en este aspecto:
- Posibilidad formatear y “embellecer” el archivo JavaScript para poder analizarlo más fácilmente.
- Versionado de archivos desde la misma herramienta (es decir, poder ir guardando cambios para ir probando con diferentes variaciones del mismo archivo).
- Puede ocurrir que el error no sea de lógica JavaScript, sino por la respuesta POST de un servicio. Para estos casos podemos utilizar Tamper Data, una extensión para Firefox que permite editar los encabezados HTTP y los parámetros que se envian al servicio.
- Si se utiliza Closure Compiler para comprimir los archivos, otro mecanismo interesante es crear un mapa del archivo comprimido (pasando
--create_source_map al momento de ejecutar el compresor) y utilizar el archivo resultante con la extensión Closure Inspector para obtener una versión sin comprimir. Sin embargo, dicha extensión ya no es compatible con Firefox 4 ni las últimas versiones de Firebug (también es raro que tampoco se haya incorporado el asunto en Chrome Developer Tools).
Finalmente, para profundizar, una interesante presentación de Nicholas Zakas: Enterprise JavaScript Error Handling.
Y también un reciente artículo de The List Apart: Modern Debugging Tips and Tricks.
¿Conocen alguna otra herramienta que les ayudó en situaciones de este tipo? ¿Tuvieron experiencias similares? Todo comentario es bienvenido en Twitter ;)
