Cómo pensar los errores en el No-Code

May 18, 2020

Simplemente voy a decirlo. Claro que ha habido errores en nuestra página. Creo que es algo intrínseco al desarrollo web. No importa si se piensa desde un enfoque de código o sin código. Es algo que pasa y que nos ayuda a avanzar.

Algunos de nuestros errores, o bugs, nos han llevado a algunas de las ideas y desarrollos más emocionantes. Así que yo diría que lo primero que uno tiene que pensar a la hora de hacer software, es que los bugs y los errores ocurrirán, que se deben asumir, y que son caminos de oportunidades.

Pero también pueden ser increíblemente frustrantes.

¿Así que cómo nos podemos preparar para los bugs? ¿Cómo encontrarlos y no estar perdiendo el tiempo eternamente? Es probable que la mayoría de personas leyendo no sean técnicas y no estén familiarizadas con jerga de programación tradicional (o incluso de programación sin código). Y está bien, lo mantendremos en términos sencillos.

Tal vez lo más importante es realmente conocer las herramientas con las que trabajarán. Algunos de ustedes ya están haciendo nuestro curso de réplica de Twitter, donde usamos Bubble —y si no lo están haciendo, ¿qué esperan? ¡Inscríbanse!—, así que pondremos eso como ejemplo.

¿Acaso tienen problemas con las condiciones? ¿Con los workflows? Bueno, pueden intentar revisar eso en la página de preview de Bubble. En la parte inferior de la pantalla encontrarán un debugger mode donde podrán cargar su página con el error paso a paso, lentamente o a velocidad normal. Esto puede ser de gran ayuda para saber en qué paso del flujo las cosas dejaron de funcionar, así que no dejen de revisar esta función (para usuarios más avanzados esto puede sonar obvio, pero hay muchas personas que hasta ahora están empezando a enfrentarse a este tipo de herramientas, así que seamos solidarios).

Adicionalmente, para sacarle el mayor provecho a dicha función, creemos que es muy útil tener un mapa o flujo mental de cómo las cosas deberían funcionar normalmente. De ese modo, si algo no está bien, al menos es más fácil saber dónde buscar.

Otra cuestión importante, no solo para detectar errores, sino para un desarrollo exitoso, es poder tener un dominio del condicional material (cosas de lógica del tipo 'si x ocurre, entonces y...'). Muchos errores pueden surgir por escribir erradamente ciertas frases (como ingresar el email del usuario en vez de escribir algo como 'email del usuario actual'), así que es muy importante asegurarse de redactar correctamente estas oraciones.

Una cosa con la que muchas personas sufren (culpable), es con nombrar y etiquetar elementos al hacer desarrollo de software. Este tip es muy fácil de seguir y puede prevenir muchas lágrimas y frustración. Es simplemente eso: etiquetar todos los grupos, páginas, estilos y cualquier otra cosa que vayas a crear. ¿Por qué es útil? Aguanta Érika, voy a eso. Puede no parecer mucho, pero si, por ejemplo, estás usando el debugger, y empiezas a ver entre los errores elementos con estos nombres: asfsf, eifughr, qwrt, eriug, va a ser mucho más difícil detectar dónde se esconde el error. Así que dale unos segundos de amor a tus elementos y nómbralos. Tu 'yo' del futuro va a agradecértelo.

Y eso es. Nuestros primeros consejos para bugs en desarrollo sin código. Tal vez, conforme avancemos, podemos seguir haciendo esto en un lenguaje sencillo, y sin tecnicismos. ¿Les suena bien? ¡Esperamos sus comentarios!

const headerTagLinks = document.querySelectorAll('.js-header-tag-link'); for (x = 0, l = headerTagLinks.length; x < l; x++) { const lang = headerTagLinks[x].getAttribute('data-slug').split('-')[1]; const shouldRemoveLink = lang !== document.documentElement.lang; if (shouldRemoveLink) { headerTagLinks[x].remove(); } }