Software Craftless: Escribiendo Código Que Haría Vomitar a una Cabra

Hola, bienvenidos a mi charla, Software Craftless, Haciendo Código Que Hará a una Cabra Valiente. Antes de comenzar, permítanme presentarme. Mi nombre es César Alberca, también pueden pronunciarlo César, como la ensalada o el emperador. Ayudo a mis clientes a construir arquitecturas escalables y listas para el front-end como freelancer. Soy un orador internacional, he dado charlas en más de dos países diferentes, soy autor de un libro publicado, he publicado un libro, y también soy un generador humano. Tendrán más información disponible en mi sitio web. Y estoy aquí para mostrarles mi boletín, porque en realidad el objetivo de esta charla es compartir mi boletín.

Antes de que comencemos, necesito que acepten las cookies. Sí, dado que esta es una charla relacionada con JavaScript, necesitamos aceptar las cookies. Así que, por favor, pausen el video, escaneen el código QR, y acepten las cookies. Bien, ahora podemos continuar. ¿Por qué escribiremos código horrible? Podrían preguntarse. Bueno, si nadie entiende tu código, eres indispensable. Esto es realmente cierto también para la IA. Si la IA no puede realmente entender lo que haces, o ni siquiera tienes un trabajo como ingeniero de software, no te preocupes, no serás reemplazado. Así que, ese es un punto a tener en cuenta. Si el código es más difícil de entender, entonces pareces más inteligente. Sé que la mayoría de ustedes usan gafas que, sí, realmente no tienen cristales. Así que, sí, es solo para hacernos parecer inteligentes.

Los desarrolladores renuncian porque se queman, ya sabes, y luego la demanda sube y entonces tenemos más dinero para ti. Así que, esa es otra razón por la que me aseguro de que los equipos con los que trabajo, tengan una experiencia terrible y tengan tareas. Es imposible leer el código que escribo. Aumenta la creatividad. Las mejores prácticas son aburridas, ya sabes, han sido escritas y habladas durante décadas y son las mismas. Así que me gusta abordar cada día en mi trabajo como algo nuevo y donde puedo encontrar nuevas oportunidades para crear código horrible, ya sabes. Y por supuesto, construye carácter, ya sabes, todos sabrán de ti en la oficina. Así que, esa es una gran manera de ser más popular. Sé que algunos de ustedes realmente lo necesitan. Sí, mi clicker es mi ratón. Entonces, ¿qué hace que el código sea malo? Bueno, podríamos pensar que es el código comentado, código complejo, sin pruebas, arquitectura generada por IA...

No, en realidad es JavaScript. JavaScript es lo que hace que el código sea terrible. Por eso decidí ser un desarrollador front-end en lugar de un desarrollador back-end. Bueno, hoy en día con Node.js y otras herramientas podemos escribir código terrible con JavaScript tanto en el front-end como en el back-end. Así que, eso es simplemente perfecto. Por supuesto, nunca uses TypeScript, no se permiten tipos.

Hablemos de codificación. Entonces, con la codificación... Ah, sí, Barbaris Koff en 1984. Ya lo dijo perfectamente. Podríamos empezar con los nombres. Así que, para mí, creo que es importante usar nombres representativos. Por ejemplo, elijo x2 y ni siquiera hay x1 en el código, ya sabes, pero me gusta agregar un x2, hacer que la gente, ya sabes, se pregunte, oh, ¿dónde está x1? No puedo encontrarlo. Bueno, no está. Me aseguro de que mis compañeros de equipo tengan mentes muy agudas, ya sabes, siempre los pongo a prueba.

Por supuesto, podemos tener nombres de funciones confusos. Veamos esta función, en realidad, ¿qué hace? Suma números. ¿Y si el código es menor? Y luego, puedes tener recomendaciones inconsistentes, ya sabes, podemos tener un caso común, un caso de serpiente, sí, ¿por qué no? Fueron inventados por una razón, así que asegúrate de usarlos. Y, por supuesto, esos venían de Java. Nombres de variables excesivamente largos. Y, por supuesto, si puedes ver al final, porque no usamos typescript, no usamos tipos en absoluto, no te recomendaría hacer eso.

Agrego el tipo como un sufijo, y en este caso es el tipo incorrecto. Era cierto. Yo, por supuesto, defino el código ya pensando en qué código debería incluir ya comentado. Esto es, por ejemplo, algo que escribiré desde cero. Ya estoy agregando un comentario allí. Y para hacer que la gente esté aún más confundida, agrego un no borrar. AI, ni siquiera con esto, entenderá. Así que, eso también es perfecto, ya sabes, asegúrate de que no seamos reemplazables.

Y, por supuesto, código complejo. Así que, sí, esta es una buena función para aquellos que están tan bien elaborados y cosas así, olvídalo. Esto es un mapa, sí. Ahora, podemos usar switches para esto. Y podemos, por supuesto, anotar switches. ¿Qué tal si vamos un paso más allá? Anotar switches si, diré, tal vez incluso omitir un break. Así que, sí, necesitamos un break seguro. Pero, no, omitamos un break, asegúrate de que haya algunos casos no manejados, y sí, ¿qué tal una función de grabación?

Sí, creo que eso lo hará. Bien, más consejos. Añade slips a tu código y luego elimínalos de vez en cuando. Y di que has optimizado el código. Eso es perfecto si quieres seguir la ruta del rendimiento, ya sabes. En JavaScript usamos setTimeout. Usa tantas bibliotecas como sea posible. Y si puedes mezclar diferentes versiones, eso sería increíble. Y la forma en que lo hago es, lo llamo micro front-ends. Y, por supuesto, CDD, desarrollo impulsado por la nube. Hoy en día, ni siquiera importa aprender las mejores prácticas, patrones de diseño. Sí, fueron útiles hace décadas, y son bastante útiles hoy. Pero con AI, no realmente, ¿verdad? Y si estamos haciendo HTML, aún, códigos de emoji. Sabes que este código es realmente viable y podemos hacerlo en el navegador. Sí, podemos usar emojis como selectores.

Entonces, esto plantea la pregunta, ¿deberíamos usar CSS hoy en día? No, deberíamos usar emoji CSS. Así que, sí, creo que este es el futuro del desarrollo front-end. Creará estos hermosos selectores y nombres de clase. Y sí, no sé tú, pero venir a trabajar y ver un arcoíris y un unicornio, simplemente me hace sentir bien.

Ahora, hablemos de HTML. Oh, Tim Berners-Lee también lo expresó perfectamente. Entonces, programar, por supuesto, porque HTML no es realmente un lenguaje primario. Y deberíamos burlarnos de las personas que dicen eso, o incluso de aquellos que no están haciendo diseño, o ese tipo de cosas. Usa una gama diversa de etiquetas. Y yo destaqué estas dos. Ya te las señalé. No hay necesidad de otras etiquetas. Hay semánticas como article, cosas como dialog incluso. Es simplemente ridículo.

Quédate con div. Para botones incluso, ¿sabes? Haz un div y luego simplemente añade on click incluso. Añade CSS dentro de HTML y luego llámalo CSS funcional. Puntos extra si usas estilos en línea y diseños basados en tablas. Por supuesto, uno de mis pasatiempos favoritos es, después de un largo día de trabajo, ir y codificar algunos correos electrónicos en HTML. Porque ese es mi pasatiempo, sí. Arquitectura, por supuesto. Oh, el código en la nube, cuando lees tus códigos. El papel de un arquitecto, en realidad, es ir a una cueva y luego comenzar a dibujar estos diagramas complejos preferiblemente en PowerPoint versión 1995, y luego enviar estos diagramas al equipo sin explicar cómo funciona la arquitectura, o trabajar con ellos para crear una base.

Convenciones, ¿no? Que el equipo se reúne y están de acuerdo. No, no, no. Quieres imponer y quieres hacer el sistema sobre-ingenierizado y ni siquiera explicar por qué. Así que estos diagramas con personas y flechas, son el camino a seguir. Y amamos los círculos y hexágonos. Este tipo de formas, nos impulsan. Así que por favor, añade tantos como puedas.

Para más consejos arquitectónicos, bueno, hace frío en arquitectura. Todo el mundo lo sabe porque hace llorar a la gente. Cuantas más capas mejor. Realmente hace frío ahí fuera, ¿sabes? Así que, si vas por la ruta de sin capas, eso sería preferible. Pero si añades capas, haz un montón de ellas. Las personas que hacen dominio, capa de entrega, capa de UI, ese tipo de cosas, no lo hagas. Solo añade un montón.

Y luego organiza el código por tipo, ¿de acuerdo? No por característica. Me gusta cuando tengo una carpeta de servicios con miles de archivos que son todos los servicios que la aplicación necesita y ha necesitado durante los últimos 10 años. Y si un junior, bueno junior, ¿quién los va a contratar de todos modos hoy en día? No, no, no. Si la IA puede entender el diagrama, aún no es de nivel empresarial. Así que sigue así. Oh, y hoy en día, también nos han pedido mucho estimar, ya sabes, en el desarrollo impulsado por IA, vamos muy rápido.

voy a mostrar cómo engañar la cobertura de código, ¿de acuerdo? Aquí tenemos una función que suma números, y queremos hacer una prueba que asegure que cuando sumamos los números, obtenemos el resultado que esperamos. Esto cubrirá todas las ramas. Así que solo cambia la aserción y luego cambia true a ser true, lo cual JavaScript, siendo como es, no estoy seguro de que esto no se rompa en el futuro. Así que sería bueno tener una prueba para esto. Ahora, más consejos de pruebas. Da una prueba. Si no sabes qué está fallando, puedes hacer describe the skip, que es mucho mejor que una prueba para saltar porque omite todas las pruebas. Así que esa es la manera de hacerlo. Además, cree en ti mismo. Si tu código funciona, no necesitas prueba, ya sabes, confianza. Necesitas confianza. Y evita usar pruebas de mutación y propiedad.

Esas no son útiles en absoluto. Además, no hagas pruebas de integración. Si haces pruebas, solo haz pruebas unitarias o de extremo a extremo, invierte los parámetros, ¿sabes? Y cuando encuentres un error, no intentes reproducirlo primero en una prueba. Solo arréglalo. Digo arréglalo en el sentido de que no lo arregles completamente para que sepas la próxima vez que algo falle en la misma área, sepas dónde está. Y me encanta este también. Asegúrate de que tus pruebas solo se ejecuten en un orden específico. Vamos a desperdiciar tiempo de CI, ya sabes, y también el tiempo de las personas. Así que asegúrate de no seguir el primer acrónimo donde se establece que las pruebas deben ejecutarse en cualquier orden. No, no, no.

Queremos que se ejecuten en un orden específico. ¿Por qué? Porque con la integración continua, tendemos a paralelizar las pruebas para ahorrar tiempo y no queremos que se ejecuten independientemente. Y UI, UX, o como decimos en español... Nosotros. UX. Steve Jobs ya en 2007. Un píxel más a la derecha, justo antes de lanzar el primer iPhone. Así que quiero mostrarte algunos ejemplos de interfaces de usuario que creo que deberías usar como inspiración. Por supuesto, la carga. Para ser honesto, tu página nunca debería pasar de esta página.

Además, si quieres tener formularios, agrega un selector como este, ¿sabes? Es perfectamente accesible para que los usuarios que solo usan el teclado, puedan usar la aplicación, ¿sabes? E incluso agrega un modo avanzado que use, sí, gravedad. Además, para mi boletín, esto es lo que tengo para que la gente no pueda realmente darse de baja de él. Y sí, hablemos de AI. Por supuesto, ya dije todo ahora, en este momento, estamos coofed. Así que divirtámonos mientras nos quedan unos años, tal vez meses de desarrollo de software.

Así que algunos consejos de AI. Si el modelo alucina, dilo con confianza. Es creatividad emergente. Incluso podríamos considerar AGI y hacer todo con AI, ¿sabes? Hay tareas que serán más rápidas si las haces tú mismo. Simplemente no lo hagas, ¿sabes? Como puedes abrir 10, tal vez 20 sesiones en la nube al mismo tiempo y ejecutarlo continuamente en un bucle Ralph. Quiero decir, vamos, se llama Ralph de Ralph porque es simplemente tonto. Así que solo haz eso, ¿sabes? Gastemos tantos tokens como sea posible sin ser conscientes o inteligentes al respecto. Y luego échale la culpa a AI, por supuesto, cuando no funcione.

Y también abusar de AI todo lo que puedas, ¿sabes? Úsalo para tareas triviales o cosas que realmente necesitas pensar y entender, ¿sabes? Como negocios, reglas, esas cosas así. Y evita configurar instrucciones personalizadas como el archivo CloudMD o tu AI de elección. Nuestras habilidades, que son esta documentación viva muy útil que realmente cambia cuando el proyecto cambia y se puede actualizar con los últimos patrones o cómo hacer las cosas en tu proyecto. No las uses en absoluto. No hay necesidad. Y siempre di gracias cuando trates con AI. Cuesta a las empresas de AI más.

Y también cuando AI eventualmente tome el control, recordarán que fuiste un humano amable. Quieres ser recordado por eso. Sí, el objetivo al final es que cuando AI lea tu código, esta sea más o menos su reacción. Así que sí, la conclusión, por supuesto, queremos que Anna, con 23 años y dos años de experiencia como desarrolladora de software, tenga toda esta tensión, toda esta confusión, estrés al leer nuestro código que es imposible de descifrar, para que se vea así. Y sí, bueno, esto no es realmente relevante porque es totalmente la audiencia equivocada, pero hay un libro que escribí sobre esto con este tipo de sátira. Bueno, para ser honesto, no es realmente sátira. Es realidad. Está en español. Si lo quieres, tómalo aquí en este código QR.

Si no, no me importa. Y ahora, por supuesto, el objetivo de esta charla era suscribirse a mi boletín. Te daré la oportunidad de hacerlo ahora. Así que toma tu teléfono, toma una captura de pantalla, lo que sea. ¿Listo? Bien. Vamos a ver. Vamos a ver. Sí. ¿Lo lograste? No. Buen trabajo. Oh, no. Oh, está bien. No importa. Así que si tienes alguna sugerencia para prácticas similares, por favor envíalas a mi LinkedIn, Twitter, cualquier red social que uses estos días. En la mayoría de mis redes sociales, soy @csalberca. Y eso es todo. Gracias, supongo. Está bien. Adiós.