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

Hola, bienvenidos a mi charla, Software Craftless, Haciendo código que hará que una cabra sea audaz. Antes de comenzar, permítanme presentarme. Mi nombre es Cesar 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 frontend 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 en mi sitio web disponible. Y aquí, les muestro 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 incluso si 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 ver inteligentes. Los desarrolladores renuncian porque se queman, ya sabes, y luego la demanda sube, y entonces tenemos más dinero para ti. Así que, por eso, y 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. Potencia la creatividad.

Las mejores prácticas son aburridas, ya sabes. Han sido escritas y discutidas durante décadas, y son las mismas. Así que me gusta abordar cada día en mi trabajo como algo nuevo, y donde pueda encontrar nuevas oportunidades para leer 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ías pensar que es el código comentado, el código complejo, sin pruebas, la arquitectura generada por IA. No, en realidad, es JavaScript. JavaScript es lo que hace que el código sea terrible. Por eso decidí ser desarrollador de front-end en lugar de desarrollador de 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.

Hablemos de codificación. Entonces, con la codificación... Ah, sí, Barbaris Kov en 1984. Ya lo dijo perfectamente. Podríamos empezar con la nomenclatura. 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 añadir un x2 para que la gente, ya sabes, diga, oh, ¿dónde está x1? No puedo encontrarlo Bueno, no hay ninguno. Me aseguro de que mis compañeros de equipo tengan una mente muy aguda, ya sabes. Siempre los pongo a prueba. Por supuesto, podemos tener nombres funcionales confusos.

¿Qué pasa si el código es menor? Y luego podemos tener recomendaciones inconsistentes, ya sabes. Podemos tener common case, snake case. Sí, ¿por qué no? Fueron inventados por una razón, así que asegurémonos de usarlos. Y por supuesto, viniendo de Java, nombres de variables excesivamente largos. Y por supuesto, si puedes ver al final, porque no usamos tipos, 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. Tres tuplas true. Yo, por supuesto, defino el código ya pensando en qué código debería incluir ya comentado fuera. Esto es, por ejemplo, algo que escribiré desde cero. Ya agregando un comentario allí. Y para confundir aún más a la gente, agrego un no borrar.

Asegúrate de que no seamos reemplazables. Y por supuesto, código complejo. Así que sí, esta es una buena función para aquellas personas que también somos crafters 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 digo tal vez incluso omitir un break. Así que sí, necesitamos un break seguro. Pero no, vamos a omitir 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. Agrega 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 setTimeouts. 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 llamándolo micro frontends. Y por supuesto, CDD, cloud-driven development.

Hoy en día, ni siquiera importa aprender mejores prácticas, patrones de diseño. Sí, fueron útiles hace décadas y son bastante útiles hoy. Pero con AI, realmente no, ¿verdad? Y si estamos haciendo HTML, todavía códigos emoji. ¿Sabes que este código es realmente viable y que realmente podemos hacer esto en el navegador? Sí, podemos usar emojis como selectores. Entonces, esto plantea la pregunta, ¿entonces con CSS, deberíamos usarlo hoy en día? No, deberíamos usar emoji CSS. Así que sí, creo que este es el futuro del desarrollo frontend. 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. Así que programación, por supuesto, porque HTML no es realmente un lenguaje de programación. Y deberíamos burlarnos de las personas que lo dicen o incluso de aquellos que están haciendo diseño y ese tipo de cosas. Usa una gama diversa de etiquetas. Y destaqué estas dos solo para señalarlo ya para ti. Solo úsalas. No hay necesidad de otras etiquetas. Hay algunas semánticas como article, cosas como diálogo incluso. Es simplemente ridículo. Quédate con esto. Para botellas incluso, ya sabes, haremos un div y luego simplemente agregaremos un evento on click.

Agrega 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, voy y codifico algunos correos electrónicos HTML porque ese es mi pasatiempo. Sí. Arquitectura. Por supuesto, el código en la nube cuando lees tu código. Así que 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úna y estén de acuerdo. No, no, no, no. Quieres imponer y quieres hacer el sistema sobreingenierado y ni siquiera explicar por qué.

Así que estos diagramas con personas y flechas, son el camino a seguir. Y nos encantan y nos encantan 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. Todos saben esto porque hace llorar a la gente. Cuantas más capas, mejor. Hace mucho frío allá afuera, ¿sabes? Así que si vas por la ruta de sin capas, eso será preferible. Pero si añades capas, haz un montón de ellas. Las personas que hacen dominio, capa de entrega, capa de UI, no lo hacen. Solo añade un montón.

Y luego organiza el código por tipo, 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, ¿quién los va a contratar de todos modos hoy en día? No, no, no. Si AI 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. Ahora con el desarrollo impulsado por AI, estamos llegando muy lejos. Voy a mostrarte lo que uso para estimar para mis clientes. Sí.

Bien, documentación. Bien, siguiente. Pruebas. Hablemos de pruebas. Uncle Bob en 2017. Sí. Así que quiero mostrarte cómo engañar la cobertura de código. 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 describir el skip, lo cual es mucho mejor que un test.skip 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 pruebas, 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 repetirlo 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, ¿sabes? Y también el tiempo de las personas. Así que asegúrate de 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. Uh, Steve Jobs ya en 2007.

Uh, 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í, como gravedad. Además, para mi boletín, esto es lo que tengo. Así que la gente no puede realmente darse de baja de él. Y sí, hablemos de AI. Por supuesto. Ya lo dije todo ahora, ahora mismo estamos cocidos. Así que divirtámonos mientras tenemos unos pocos años, tal vez meses de desarrollo de software restantes. Así que algunos consejos de AI. Si el modelo alucina, dilo con confianza.

Es creatividad emergente. Incluso podrías considerar una 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 ejecutarlas continuamente en un bucle Ralph. Quiero decir, vamos, se llama Ralph de Ralph Weebull porque sí, 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 abusa de AI todo lo que puedas. Sabes, úsalo para tareas triviales o cosas que realmente necesitas pensar y entender, ¿sabes? Como reglas de negocio, cosas así.

Y evita configurar instrucciones personalizadas como archivo MD en la nube o tu AI de elección. Nuestras habilidades, que son esta documentación viva muy útil que realmente cambia cuando el proyecto cambia y puede ser actualizada 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 más a las empresas y también cuando AI eventualmente tome el control, recordarán que fuiste un humano amable. Quieres ser recordado por eso.