Uso del Try Catch vs manejo Global de excepciones

Mi regla es que debes usar el manejo de excepciones para casos específicos o "excepcionales". Un manejo global de excepciones debe manejar las excepciones no manejadas.

El seguimiento de la pila debe usarse para ayudarte a identificar dónde ocurrió algo.

Hay casos en los que podrías esperar una excepción y querer manejarla, como una FileNotFoundException. Sabes que podría ocurrir y quieres manejarla antes del manejador global, y no lanzar una excepción, sino mostrar un diálogo.

Usar ifs para evitar excepciones es bueno si conoces la condición (por supuesto), pero es importante usar ifs vs manejo de excepciones en un bucle muy ajustado con 10k+ iteraciones, ya que es una buena mejora de rendimiento. Las excepciones deshacen la pila y pueden ralentizar realmente los bucles. Si puedes anticipar las condiciones de error, entonces manejalas de antemano.

Tener un manejador global de excepciones es DRY. (Don't repeat yourself), especialmente para el registro. Mantiene el código de registro fuera de los lugares que no lo necesitan necesariamente. El código debe hacer una sola cosa (Principio de responsabilidad única) para mantenerlo libre de dependencias innecesarias.

Como con cualquier cosa, úsalo con prudencia y deberías poder justificar por qué lo usas además de "Me gusta así".

Las siglas extravagantes son geniales, pero siempre entiende por qué necesitas hacer las cosas y si tienen sentido para ti. ¿Hacen que el código sea más fácil de mantener? ¿Lo hacen más simple, más enfocado?

Ejecución de JavaScript después de cargar la página

Durante el desarrollo web, es posible que haya habido momentos en los que su JavaScript se ejecutaba demasiado pronto, lo que puede generar errores o un comportamiento inesperado porque los elementos HTML que su script intenta utilizar pueden no estar completamente cargados todavía.

En este byte, exploraremos cómo hacer que JavaScript se ejecute después de que la página se haya cargado completamente, garantizando que todos los elementos estén listos para la interacción.

¿Por qué ejecutar JavaScript después de cargar la página?

La carga de una página web no es instantánea. El navegador analiza el HTML, crea un Modelo de Objetos de Documento (DOM) y comienza a renderizar la página. Si el código JavaScript se ejecuta antes de que el DOM esté completamente construido, podría intentar manipular elementos que aún no existen, lo que generaría errores. Al ejecutar JavaScript después de la carga de la página, se garantiza que todos los elementos de la página estén disponibles para que el script interactúe con ellos.

Nota: Es importante comprender que la ejecución de JavaScript puede bloquear la renderización de la página. Esto significa que si se ejecuta un script pesado antes de que la página cargue, puede afectar el tiempo de carga y la experiencia del usuario.

Cómo ejecutar JavaScript después de cargar la página

Hay varias maneras de ejecutar JavaScript después de cargar la página. En esta sección, abordaremos el DOMContentLoadedevento, pero también existen otros métodos, como el loadevento y el método de jQuery $(document).ready.

Uso del evento "DOMContentLoaded"

El DOMContentLoadedevento se activa cuando el documento HTML inicial se ha cargado y analizado por completo, sin esperar a que las hojas de estilo, las imágenes y los submarcos terminen de cargarse. Puede configurar un detector de eventos para este evento, y su código JavaScript dentro de este detector se ejecutará una vez que el DOM esté listo.

He aquí un ejemplo:

document.addEventListener('DOMContentLoaded', function() {
  // Your code here
  console.log('DOM fully loaded and parsed');
});

Cuando ejecute este código, verá el mensaje "DOM completamente cargado y analizado" en su consola después de que el DOM se haya cargado completamente.

Nota: El DOMContentLoadedevento es una herramienta muy útil, pero tenga en cuenta que no es compatible con Internet Explorer 8 y versiones anteriores.

Usando el evento "cargar"

El evento "load" es un evento DOM estándar que se activa cuando la página web termina de cargarse. Esto incluye todos los recursos, como imágenes, scripts y archivos CSS. Puedes usarlo así:

window.addEventListener('load', (event) => {
    console.log('The page has fully loaded');
    // Your code here
});

Cuando la página se haya cargado completamente, la consola registrará "La página se ha cargado completamente" y luego se ejecutará su código.

Nota: El evento "load" puede tardar un poco más en ejecutarse que el evento "DOMContentLoaded", ya que espera a que se carguen todos los recursos. Si su script no depende de otros recursos, le recomendamos usar "DOMContentLoaded" para una respuesta más rápida.

Usando el método '$(document).ready' de jQuery

Si usas jQuery, puedes usar este $(document).ready()método. Este método se llama en cuanto el DOM está listo, lo cual puede ocurrir antes del evento "load" si hay muchos recursos grandes que cargar.

$(document).ready(function() {
    console.log('The DOM is ready');
    // Your code here
});

Con este método, la consola registrará 'El DOM está listo' y luego se ejecutará su código.

Nota: jQuery es una biblioteca popular que simplifica muchos aspectos de JavaScript, pero no siempre es necesaria. Si solo usa jQuery para el $(document).ready()método, le recomendamos usar JavaScript simple para reducir las dependencias de su proyecto.

Comparando los diferentes métodos

Cada uno de estos métodos tiene sus propios casos de uso. El evento "DOMContentLoaded" es útil para ejecutar JavaScript en cuanto se analiza el HTML, lo que puede ser significativamente más rápido que el evento "load" si la página contiene recursos de gran tamaño. Sin embargo, si su JavaScript depende de estos recursos, deberá usar el evento "load" para asegurarse de que se carguen completamente antes de ejecutar el script.

Por otro lado, $(document).ready()el método de jQuery es una buena opción si ya lo usas y buscas una forma sencilla y compatible con todos los navegadores de ejecutar JavaScript una vez que el DOM esté listo. Sin embargo, ten en cuenta que jQuery puede resultar excesivo si solo lo usas para eso.

Conclusión

Ejecutar JavaScript tras la carga de la página es un requisito común en el desarrollo web. El método que elija para lograrlo dependerá de sus necesidades específicas y de las bibliotecas que utilice. Ya sea que elija el evento 'DOMContentLoaded', el evento 'load' o $(document).ready()el método de jQuery, cada uno tiene sus propias ventajas y desventajas. Comprenderlas le ayudará a tomar una decisión informada para su proyecto.

Ajax vs fetch

Tanto AJAX como Fetch son técnicas que se utilizan en JavaScript para hacer solicitudes de red asincrónicas (asíncronas) sin tener que recargar la página. Cada una tiene sus ventajas y desventajas, y la elección depende del caso de uso específico y de las preferencias del desarrollador.

Algunas de las ventajas y desventajas de AJAX y Fetch son las siguientes:

Ventajas de AJAX:

• Soportado por todos los navegadores modernos.
• Fácil de usar y de implementar.
• Capacidad para enviar solicitudes en segundo plano y actualizar partes específicas de una página sin tener que recargar toda la página.

Desventajas de AJAX:

• La API de AJAX no es tan moderna y elegante como Fetch.
• No soporta algunas de las funcionalidades de Fetch, como el manejo de errores HTTP.

Ventajas de Fetch:

• Diseñado para ser más moderno y elegante que AJAX.
• Tiene una API más clara y fácil de usar.
• Soporta promesas, lo que lo hace más fácil de manejar y más intuitivo.

Desventajas de Fetch:

• No está soportado en algunos navegadores antiguos.
• No es compatible con algunas API y funcionalidades de red más antiguas.

En general, Fetch es una técnica más moderna y elegante que AJAX, pero AJAX es compatible con todos los navegadores modernos y es más fácil de usar e implementar. Por lo tanto, la elección depende del caso de uso específico y de las preferencias del desarrollador. 

Los 10 mandamientos del control de código fuente

Los sistemas de control de versiones o sistemas de control de código fuente son programas que mantienen el histórico de todos los cambios realizados sobre archivos y carpetas a lo largo del tiempo. Esto permite volver a cualquier punto del pasado en cualquier momento, y también comparar un punto del tiempo con otro para conocer los cambios exactos que se han producido entre ambos. Además almacenan también quién es el autor de cada cambio y facilitan mucho el trabajo en paralelo de varias personas en varias características.

Existen multitud de sistemas de control de código: locales, centralizados o distribuidos. Más apropiados para código fuente o para archivos grandes como gráficos o vídeos. Instalados en un servidor local o utilizados desde Internet...

La lista de software para control de código es extensísima, pero los más conocidos son Mercurial, Subversion, PlasticSCM (que además de ser un proyecto alucinante, está creado desde cero en Valladolid para el mundo), y por supuesto el rey de todos ellos: Git, creado por Linus Torvalds hace ya más de una década y que se ha convertido en el estándar de facto de la industria.

Hoy en día es inevitable usar el control de código fuente en cualquier proyecto. Debería estar castigado con las penas del infierno de los programadores el hecho de no utilizarlo.

Es por esto que he intentado recopilar lo que considero que deberían ser los 10 mandamientos del control de código fuente, tal cual debería haberlos bajado el propio Linus Torvalds desde las montañas para entregarlas a sus seguidores. Las 10 reglas básicas de comportamiento que todo programador debería seguir a la hora de trabajar con este tipo de sistemas.

Ahí van:

1.- Utilizarás control de código sobre todas las cosas para todos tus proyectos

Da igual que sea un proyecto personal en el que solo trabajes tú. Deberías usar control de código fuente, aunque sea con un repositorio local sin respaldo en un servidor. De este modo podrás ir guardando todos los estados importantes del proyecto y volver a cualquier punto anterior, ver qué decisiones y cambios te llevaron al punto actual, etc...

Por supuesto en un equipo, aunque sea de dos, es indispensable. Con servicios gratuitos de repos privados como Bitbucket, Gitlab o el propio Visual Studio Team Services de Microsoft (que también soporta Git) no hay disculpa para no hacerlo.

2.- No te irás nunca a casa sin hacer un commit y un push

Es decir, sin dejar el código perfectamente salvaguardado y recuperable desde cualquier sitio, esté en el estado que esté (más sobre esto luego).

No en vano en algunos sitios el procedimiento anti-incendios incluye un cartel como este:

Aunque este sea para Git, vale para cualquier otro VCS: confirma y almacena antes de irte, aunque sea a comer.

3.- Inspeccionarás tus cambios con cuidado antes de hacer un commit

Lo de crear un commit es tan sencillo que lo hacemos de manera rutinaria, sin fijarnos. Mal hecho. Debemos prestar atención a que todos los archivos necesarios están en el área de preparación. A veces los archivos nuevos no se han añadido. O puede que se hayan agregado archivos que son temporales y no deberían estar ahí. ¿Y qué pasa con archivos que has editado pero que realmente no han cambiado finalmente tras varios cambios? No deberías subirlos y meter más ruido en el commit.

Para ello, revisa siempre bien los cambios antes de subirlos y asegúrate de que solo va lo que es realmente necesario. Utiliza incluso la herramienta de comparación si tienes dudas.

4.- Harás commit con frecuencia

Muchas personas tienen miedo de hacer commits con cosas a medio terminar y que luego se vean así en el histórico, como si todas las características de un desarrollo de software llegaran a la perfección al mismo tiempo que las escribimos. En absoluto. No pasa nada por tener cosas a medias o feas o con "ñapas" mientras no hemos terminado el desarrollo. Es preferible a tener un solo commit varios días después. Perdemos trazabilidad, ideas, conocimiento de cómo el código llegó a ser como es, y es imposible que otras personas del equipo conozcan el progreso actual del trabajo.

Deberías hacer un commit cada vez que tengas código que deseas guardar, porque tiene algo interesante, está una parte completa o, simplemente, te marchas y quieres dejar el trabajo salvaguardado. No pasa absolutamente nada. Además, si quieres dejarlo bonito más tarde también puedes hacerlo mediante cherry picking u otras técnicas. Pero, ¿para qué?.

Además recuerda que en sistemas distribuidos como Git, el hecho de hacer un commit no implica que debas hacer un push y subirlo al repositorio remoto. Los repos locales son para llevar control de tu trabajo y protegerlo. Los repos remotos son para pasar el trabajo a tus compañeros, controlar el trabajo de todos y, también, tener copias de seguridad.

Deberías enviar el código al remoto al menos una vez al día, pero no necesariamente cada vez que hagas un commit. Por lo demás, no te cortes y haz tantos commits como necesites.

5.- Te asegurarás de que los comentarios valen para algo

No hay nada peor que mensajes en un commit que no dicen nada de valor, como el mensaje de este cartel (clásico en marketing):

¿Qué aporta ese mensaje ahí? Absolutamente nada. Ya sabemos que Pizza Hut tiene pizza...

Pues lo mismo ocurre con los mensajes que se ven en los repositorios muchas veces (por no mencionar en los comentarios de código).

Solo hay algo peor que un mensaje redundante: mensajes tan largos que acaban por no servir tampoco de nada, porque encima dan trabajo extra al leerlos.

Un mensaje de commit debería ser conciso pero al mismo tiempo informativo, aportando valor. Debería tener todo lo necesario pero no más. Por lo tanto debería enumerar los cambios importantes que se han hecho y por qué. Esto ayuda a localizar el punto en el que se cambió un comportamiento, una característica o se corrigió un bug. También ayuda a ver de un golpe rápido de vista el trabajo que se ha realizado recientemente y su progreso.

Si vas a hacer muchas cosas una mañana, no pasa nada: haz varios commits y procura que en cada uno haya un mensaje útil sobre cada cosa.

6.- Harás un Fetch/Pull antes de hacer un commit

Antes de empezar a trabajar en tu código después del último commit, haz un fetch o un pull para traerte los cambios del remoto y traer lo último que hayan hecho tus compañeros. Evitarás muchos conflictos en el futuro, y sobre todo evitarás sobrescribir su trabajo si no los gestionas bien.

Esto es de extrema importancia en sistemas no distribuidos como Subversion, porque directamente podrías cargarte el trabajo de los demás. Otros sistemas como Git no permiten que ocurra tan fácilmente (aunque sigue siendo buena costumbre hacerlo para evitar problemas).

Recuerda: antes de nada, tráete los cambios que haya.

7.- No harás push directamente al master

Esto ya no deberían permitirlo los administradores del repositorio, pero cada característica o bug debería trabajarse en su propia rama, y es ahí en dónde se deberían recibir todos los push. Estas ramas deberían salir a su vez de la rama de desarrollo, así que una vez terminado el trabajo en cuestión, la rama debería mezclarse con la de desarrollo.

Solo el código definitivo, bien probado y revisado debería ir al master, y para ello debería ser necesario un Pull Request que alguien deba aprobar. Algunos sistemas de repositorios como Bitbucket o GitLab, por defecto ya lo tienen configurado así para evitar problemas.

Si utilizáis alguna metodología de gestión de ramas como Git-Flow (que deberíais), entonces ya será así como trabajarás.

8.- Comprenderás bien la herramienta de mezcla y comparación

Los conflictos son inevitables al mezclar ramas y al recibir actualizaciones desde los remotos. Así que aprende bien a manejar las herramientas de comparación que integres en tu sistema de trabajo. Pueden ser las herramientas de "diff" de tu cliente de Git favorito o alguna herramienta externa potente (y gratuita) como WinMerge, que a mí personalmente me encanta.

Cuando surja un conflicto será tu salvación. Y cuando no haya conflictos pero necesites ver qué ha cambiado en varias versiones de los archivos para descubrir un bug, también.

9.- Versionarás tus bases de datos y otras cosas

Hay quien se piensa que el control de código fuente solo sirve para código, porque lo lleva en el nombre. En absoluto. Deberías gestionar en él todo lo que tenga que ver con el proyecto, como documentación interna y externa (sobre todo si está en Markdown), gráficos, especificaciones, diagramas de flujo... y sobre todo las versiones de tu base de datos.

Para ello no es necesario que guardes la base de datos, sino su esquema en formato instrucciones SQL para poder reconstruirla en cualquier momento y conocer su evolución en el tiempo.

Cada vez que se realice un cambio sobre la base de datos puedes generar su esquema a un archivo de texto y archivarlo con el resto del código fuente. Puedes hacerlo con alguna herramienta especializada que lo automatice o puedes hacerlo a mano. Pero hazlo.

Estos elementos son tan importantes como el código en sí y deben ser guardados y gestionados con el mismo mimo.

10.- Excluirás tus mierdas cosas del control de código

No hay nada más molesto que un compañero que sobrescribe tus ajustes personales en cada commit. Y es que hay muchas cosas que no deberían estar bajo control de código fuente: tus ajustes personales en el editor de código que utilices, los archivos auxiliares que solo utilizas tú, resultados de las compilaciones (las famosas carpetas "bin" y "obj" por ejemplo), dependencias (carpetas "node_modules", "packages" y similares), etc...

Para algo se inventó el archivo .gitignore en Git o la propiedad svn:ignore en Subversion, por citar los más conocidos. Mete ahí los archivos y carpetas (o plantillas de archivos y carpetas) a excluir del control de código, y asegúrate que no incluyes cosas molestas o contingentes.

En resumen

Todos estos mandamientos se resumen en uno solo: amarás al código sobre todas las cosas 😄

En serio. Seguramente muchas de las anteriores te parecen evidentes si has sabido usar este tipo de sistemas de la forma adecuada. Pero en mi experiencia, muchas personas se olvidan de lo básico y fastidian al resto del equipo y al código a largo plazo. También seguro que hay algunos consejos adicionales que se podrían añadir.