Tinselcity

NuevasVerdades en el Desarrollo Web

A continuación una serie de NuevasVerdades difundidas por los círculos de intelectuales del desarrollo web.

Arquitectura es cómo organizas tus ficheros y carpetas en el proyecto.

Me encanta que la gente quiera hablar de cómo organiza sus carpetas y ficheros. En serio, creo que es un tema sobre el que se puede hablar. Personalmente, no creo que dé tanto de sí como para hablar durante mucho rato, la verdad. Vamos, creo que hay igual 3 o 4 formas de organizarlo y creo también que la diferencia entre ellas, aunque interesante a veces, no es algo que tenga un impacto fundamental y clave en el éxito del proyecto. Pero incluso así, me parece bien que quien quiera hablar de ello, hable de ello, evidentemente, y creo que hay momentos en que no está de más dedicarle un rato.

Pero empieza a ser demasiado frecuente que se presente esta estructura de carpetas y ficheros, y como se organizan y se nombran, como “la arquitectura del proyecto”. Y esto es un problema, porque arquitectura es otra cosa. Entiendo que mola usar nombres de cosas más complejas para nombrar otras distintas que quieres explicar. Le da un cierto aire de importancia, ¿verdad? Hace parecer que hablas de conceptos más avanzados, ¿no? Pues te diré: No. Quizá impresiones más a personas con poca experiencia o capacidad para distinguirlo, pero a la vez que haces eso ocurren otras dos cosas. Das una impresión muchísimo peor a esas otras personas que sí tienen capacidad para ver el problema, y a la vez erosionas la calidad de la formación de nuestra profesión.

Es decir, no es sólo cuestión de tu imagen. Es que, además, estás favoreciendo a que la comprensión de las cosas que hacemos, la formación de las personas que trabajan en la profesión, la propia calidad de lo que producimos, sea cada vez peor.

Todo el mundo usa React. Todo el mundo usa Babel.

Esta NuevaVerdad tiene, a veces, una variante en la forma de “React siempre es la solución adecuada”.

Llevamos desarrollando software unos pocos años. Oh, sí, hay autómatas mecánicos programables desde hace siglos… Ya, muy bonito. Pero como actividad explícita, como profesión y como ciencia, con un estudio consciente detrás, apenas llegamos a los cien años. Comparado con el desarrollo de las civilizaciones y culturas, esto son unos pocos años. Pues bien, si hay algo, si hay una idea que podamos aceptar como difícilmente discutible, es la de que no hay balas de plata. No hay soluciones únicas (tecnológicas o no) que solucione todo.

Pero eso en cuanto a la supina estupidez de que React sea “siempre la solución adecuada”. Más allá de que lo sea o no, está la simple evidencia de la realidad sobre la proclama de que todo el mundo use React|Babel. Aquí no hay ya opinión o conjetura. Cualquier estadística más o menos fiable pone a cualquiera de ambas herramientas en una perspectiva real. Su uso, incluso en las estadísticas más generosas, no pasa de una cuota más bien pequeña, en torno al 1 o 2%… Si queréis acepto hasta el doble, un 4%. Así que… ¿todo el mundo? No, lo siento. Si te gusta React o te gusta Babel, me parece estupendo. Da argumentos por los que crees que es bueno, o explica qué te aporta. Pero decir que todo el mundo lo usa, ni es realmente un argumento a favor, ni es siquiera verdad.

Nota: Lo dicho aquí es igualmente aplicable si lo que te da gustito es Angular, Vue, Polymer, Webpack, lodash, jQuery, Wordpress, Symfony, TypeScript, Java, MongoDB, Swift, Go, Python, Node.js, o lo que sea.

Babel es necesario. Babel es bueno.

Siguiendo un poco en la línea de la anterior NuevaVerdad, parece cada vez más frecuente la presunción de que, de forma universal, es bueno y necesario usar Babel. Te voy a decir lo que es bueno y necesario. Lo que es bueno y necesario es escribir tu aplicación web y que funcione como debe.

Y para eso puedes seguir diferentes estrategias (porque, de nuevo, no hay balas de plata). Unas serán “mejores” en ciertos aspectos y “peores” en otros. Otras al revés. Pero independientemente de la estrategia que sigas, lo que es necesario es saber lo que haces, por qué lo haces, qué es lo que ganas y qué es lo que te cuesta. La enorme mayoría de la gente que acepta esta NuevaVerdad de Babel ni siquiera conoce los costes que tiene, y muchos, pero muchos muchos, apenas tienen una idea aproximada de qué es lo que realmente ganan usándolo o por qué lo usan.

Para replantearte esta NuevaVerdad mi consejo es que empieces por mirar:

  1. cuál es tu público y qué navegadores usa
  2. cuál es tu equipo y qué sabe hacer

Nota que cuando digo “qué sabe hacer”, sabe va en negrita porque si no entiende por qué hace las cosas, entonces no sabe realmente hacerlas.

Las alternativas son: O usas un framework o haces código spaghetti.

Esta me encanta. En serio. Es como una criatura llorando. Es como “si no tengo mi mantita de seguridad, la única alternativa posible es el apocalipsis de robots-zombies radioactivos que matan a toda la humanidad… repetidas veces”. Vamos que no es solo una falta total de confianza en las propias capacidades, sino también la imposibilidad de contemplar ningún color intermedio entre el blanco y el rojo-sangre-muerte-y-destrucción.

Los “frameworks” no son cosas mágicas. No nos han sido entregados por seres superiores que ha descendido del espacio. No son extraordinarios artefactos de civilizaciones milenarias que hemos encontrado en las ruinas de Machu Picchu o en las galerías secretas de los templos de Abu Simbel. Los hemos hecho nosotros mismos. Algunos los habrán hecho personas más capaces y otros otras menos capaces. Algunos serán, entonces mejores y otros peores. Todos serán productos humanos, de otras personas que también desarrollan software. Y antes de hacer esos frameworks y de aprender a hacerlos, no sabían hacerlos. ¡¡Oh!! ¡Increíble!

Y es más, incluso si no usas un framework, puedes seguir los principios y prácticas de buena organización y buena estructuración y limpieza. Y puedes desarrollar un código limpio. Sí, es posible. Es tanto o más posible que usar un framework y seguir haciendo un barullo de código horrible e inmanejable, que también es muy posible.

Nota: Cuando digo “framework” incluyo React, porque tú puedes repetir como un loro que “React es solo una librería” pero a mi no me importa una mierda.

El rendimiento o no importa nada o es lo más importante de todo.

Otro caso de extremos. O el rendimiento es el factor determinante que debe guiar todo lo que hagas, o no importa en absoluto.

Unos suelen obsesionarse con los micro-benchmarks, evaluaciones comparativas entre minúsculos detalles del código. ¿Debo usar un bucle for o un while? ¿Cuál es más rápido? ¿Es más rápido si lo hago de 0 hasta 1000 o si lo hago de 1000 a 0? Y si no haces lo que indica la comparativa, lo estás haciendo mal. Otros pegan la primera mitad1) de la cita de Knuth y concluyen que “el rendimiento debería ser lo absoluto último en lo que no deberías pensar jamás”. Es gracioso esto de los extremos porque hace entender un poco algunas cosas, como por ejemplo por qué en el mundo del frontend hay tantos vaivenes, tantos cambios: Y es por esto, porque hay dificultades para ver los puntos medios y demasiada afición a saltar entre extremos.

Secreto que no es tal: El rendimiento es importante. Pero debes tratarlo en dos formas distintas.

Por un lado debes tener siempre en cuenta el rendimiento como una preocupación general y aproximada. Esto implica tener unas ideas aproximadas de lo que en principio cuestan las cosas. En ingeniería lo llamábamos un cálculo de confianza, de estimación. Es decir, tienes una idea aproximada de si algo es “naturalmente costoso” o no. Tienes, por ejemplo, una idea de la complejidad de los algoritmos que usas. Sabes que si metes un bucle dentro de otro, el coste se multiplica. Si pones un bucle detrás de otro, el coste se suma. Cosas así, de ese estilo. Algunas más complejas y otras más simples, pero es algo que tienes siempre en tu cabeza. No como una preocupación obsesiva, sino como una idea de fondo que te guía a no hacer cosas estúpidamente costosas.

A la vez sabes que lo anterior es algo aproximado y que es suficiente para la mayoría de cosas… pero a veces no. ¿Cuándo no es suficiente? Pues cuando realmente encuentras un problema. Es entonces, cuando tienes delante un problema de rendimiento, que entras a hacer evaluaciones y pruebas, y a arañar mejoras donde puedas. Pero solo entonces. Y si la primera parte la has hecho razonablemente bien -no has hecho cosas estúpidamente costosas- entonces será poco frecuente que tengas que llegar a esta segunda parte. Pero si en un momento dado haces algo estúpidamente costoso y te encuentras con un problema de rendimiento, entonces lo bueno es que detectarás rápidamente que lo que has hecho es estúpidamente costoso.

Los patrones de diseño son trozos de código.

Esto es un poco como lo de la arquitectura. “Patrones de código” es una cosa guay. Mola hablar de cosas guays. Parece que sabes más. Y siempre puedes coger algo o inventártelo y simplemente ponerle el nombre de la cosa guay. O, a veces, lo que puedes hacer es esto: Como la cosa guay es complicada, pues nada, la simplificas. Te quedas con la parte que entiendas, mantienes el nombre chulo, y te dedicas a difundir desinformación y a contribuir a la cada vez peor calidad de la formación de nuestra profesión. Porque a ti te basta que parezca que sabes y que parezca que estás enseñando.

Voy a intentar hacer el resumen más claro de lo que es un patrón de código. Y lo voy a hacer para que entiendas que si quitas una sola cosa de lo que hay aquí, entonces ya no estás hablando de patrones de código.

Los patrones de código son esto:

Tienes un contexto determinado. Esto incluye muchas cosas, entre ellas el lenguaje de programación que estás usando. Observas, con el tiempo, que hay un tipo de problema que ocurre frecuentemente. Y cuando decimos “tipo de problema” no hablamos de “necesito sumar dos números”. Hablamos de tipos de problemas, de un nivel un poco más abstracto. No son los mismos problemas que tú intentas resolver programando. Son “problemas” que surgen sobre la propia programación en sí, sobre las formas que toma tu solución. Bien, estudias ese problema e identificas cuáles son los objetivos que aceptamos como “buenos” (en el sentido de “calidad”) que queremos conseguir que tenga nuestra solución. Y entonces vas y explicas una forma de afrontar el problema para producir una solución. Mucha negrita ahí, porque es importante resaltar que el patrón de diseño no incluye “una solución”, sino una guía, un camino para que produzcas esa solución, adaptándola a tu caso específico (el problema es abstracto, tu caso es concreto).

Es decir, que obviamente el patrón de diseño ni siquiera incluye código. No es ya que no puedas reducir “patrón de diseño” a un “trozo de código”, es que el patrón es lo demás, el resto, y no incluye ningún código.

Y recuerda lo dicho. Ni puedes añadir ese trozo de código diciendo que eso es el patrón, ni puedes quitar ninguna de las otras cosas que sí incluye el patrón (contexto, tipo de problema recurrente abstracto, objetivos, guía para afrontar la solución).

Con 3 años ya eres un experto en todo y con más de 10 años estás obsoleto

Esto forma parte de toda una serie de NuevasVerdades que tienen un atributo curioso: Resulta que son NuevasVerdades que se defienden por separado, de forma aislada, siempre positivamente como NuevasVerdades, pero que nunca pueden argumentarse juntas porque son muy evidentemente contradictorias.

El grupo incluye cosas como:

  • cualquiera puede enseñar como un experto aunque no tenga apenas experiencia
  • siempre hay que seguir aprendiendo
  • alguien que lleva más de 10 años, por defecto está obsoleto
  • “no me pagas por los diez minutos de [hacer x] sino por los diez años que me han enseñado como [hacer x] en diez minutos”
  • todo es opinable
  • no se debe criticar al que enseña, y más aún señalando algo que diga mal
  • todo cambia demasiado rápido, es agotador tener que ir detrás de todo lo nuevo
  • no puedes seguir usando algo que -aunque funcione perfectamente- no sea lo último de lo último, está obsoleto

No sé muy bien qué decir de todo esto porque temo que si quienes defienden todas estas cosas realmente se encuentran valorándolas todas conjuntamente, la contradicción produzca un colapso gravitacional en sus realidades actualmente sustentadas sobre palillos y tengan una crisis existencial. Y como sé lo feo que puede ser eso de las crisis existenciales, pues no se lo deseo a nadie.

Diré esto: Aprendemos todos. Aprendemos continuamente. Y aprendemos despacio. Lo que aprendemos, eso forma nuestra experiencia. Es estúpido considerarte experto si no tienes experiencia. Y es más estúpido aún tener opiniones muy fuertes cuando no tienes experiencia. El problema, en mi opinión, es que se busca demasiado la gratificación instantánea. Se busca el “hago un curso de 4 semanas y sé tanto como el que lleva 10 años haciendo esto”. Se busca, incluso, un reconocimiento superficial y vanidoso. Se busca llegar lo más rápido posible a “ser experto”. Y en realidad lo importante no es llegar, sino lo que haces por el camino.

Pero a la vez lo que estáis haciendo es tan pueril y simplista como defender lo mío porque es mío. Pretendéis que la experiencia de los otros no vale, pero la vuestra sí. Que los otros están obsoletos, pero vosotros sois expertos. Que no se puede estar cambiando todo tan rápido, pero que hay que cambiar todo porque lo que hicieron los anteriores está todo mal.

Intentad hacer una pausa en vuestra cabeza. Intentad evaluar y entender antes de descartar y atacar. Intentad valorar lo que está hecho y ya resuelve el problema, antes que las lucecitas brillantes de colores con las que queréis jugar.

Si no sigues ciertos procesos eres mal programador. Pero si los sigues de verdad eres mal programador

Esto es el llamamiento al teatro, a la falsedad, al absurdo y a la apariencia2).

Llámalo Agile. Llámalo falso Agile. Llámalo verdadero Agile. Llámalo Extreme Programming. Llámalo Lean, craft, clean… Llámalo RUP si te da la gana. Llámalo DAD, SAFe, LeSS, DSDM, AUP, Chaos model, V, Slow, UP… Llama a equipos squads, o tribus, o células o departamentos. Usa terminología de biología, o terminología militar. Usa nombres mitológicos o de la literatura fantástica… Llámalo como más te guste llamarlo. Si hay algo que no escasea en la industria son nombres aparentes y llamativos.

El caso es que, sigas el proceso que sigas… más te vale seguirlo. De lo contrario solo estarás repitiendo los mismos errores y teniendo los mismos problemas pero con nombres diferentes y más pintorescos.

Si eliges seguir un cierto proceso, una metodología, o unas prácticas organizativas… Incluso aunque no sea una metodología establecida y famosa. Si quieres haz tú una, mezcla varias. Elige cosas de unas y otras. Todo eso me da igual. Pero una vez que elijas una, síguela y cree en ella con firmeza. Si decides que lo bueno es hacer una reunión cada los lunes y jueves y que sea exactamente a las 11:43 de la mañana y que discurra de una cierta manera, entonces hazla todos los lunes y los jueves exactamente a las 11:43 y vigilando que discurra de esa forma. Si decides que en tu proceso cualquier entrega debe ir acompañada por tests de tipo X y de tipo Y, entonces haz que todas las entregas vayan acompañadas por tests de tipo X y de tipo Y. Si nadie puede acceder directamente a la BBDD de producción, que nadie pueda acceder directamente a la BBDD de producción. Si para aceptar un Pull Request debe ser aprobado por 3 personas que hagan revisión, no aceptes ni un solo Pull Request que no esté aprobado por 3 personas que lo hayan revisado.

Si no haces esto, si decides establecer unos procesos, unas metodologías y luego no te importa saltártelas “en ocasiones”, el resultado va a ser siempre el mismo: Nunca vas a seguir ese proceso. Siempre te saltarás las prácticas establecidas.

Y puedo casi oír la queja de los patanes en mi cabeza:

Hombreee… No se puede ser tan rígido. Hay que adaptarse, siempre hay excepciones… Imagina que ocurre algo… Los patanes

Sí, siempre hay excepciones. Han secuestrado a tu abuela y tus hijos y los matarán si no aceptas ese Pull Request así tal cual. ¡Acéptalo, imbécil! ¡Evidentemente! ¡Nadie quiere que maten a tu abuela y tus hijos! Pero… ¿cuántas veces te ha pasado esto en el mundo real? Yo no tengo hijos ni abuela, pero es que ni entre la gente que conozco que los tiene he sabido de un caso así en años.

Claro, si lo que quieres es tener la puerta abierta para poder decir que cualquier razón que te parezca es una buena excusa para hacer una excepción, entonces ya es otro tema. Porque entonces sí, continuamente he encontrado patanes que siempre tenían una buena excusa para saltarse un procedimiento, para no hacer una práctica, para no seguir una norma. Hay reunión de planificación, sí, pero… es que es a la hora del café. No pasan los tests en el entorno de integración, no, pero… será cosa del entorno porque mi código es bueno. No da tiempo a tenerlo para el día X, no, pero… si no hacemos pruebas, ganamos dos días más gratis (Yuhu!).

El resultado final es el anunciado: El teatro de la calidad. Haces como que lo haces bien. Tienes tus procesos, tus normas bien bonitas y aparentes, todo muy profesional y organizado de cara a la galería, mientras la realidad es que lo que sigues haciendo es trampear y chapucear como mejor te parece ese día.

Y lo peor es que terminas asumiendo que esto es bueno. Que tienes buenas normas pero que no debes cumplirlas. Y esa es tu NuevaVerdad. Te lo diré claramente para que lo entiendas: Has sido tú el que ha puesto la norma. Si no la vas a cumplir no la pongas. Es así de fácil.

El frontend es esto. Backend es eso.

Esta es una NuevaVerdad de simplificación. La realidad es que no tienes ni puñetera idea de lo que es el frontend3).

Incluso si trabajas “en el frontend”. En serio, te crees que sabes lo que es y usas esa definición como infalible. Y tu definición se centra en lo que tú quieres ver. El frontend es maquetación. La maquetación es otra cosa, no es frontend. UX es UX, diseño es diseño, frontend son programadores. Frontend no son programadores. UX sueña los sueños, frontend los hace realidad4). El trabajo de frontend es retorcerse entre el capricho de UX y la inmovilidad egocéntrica de backend5). Yo soy fullstack6).

A ver… Dentro de la programación web hay muchas cosas. Actividades, preocupaciones, productos intermedios, productos finales. Algunas personas se especializan en unas, otras en otras. Algunos en varias. Hay quien no se especializa en ninguna en concreto. Hay cosas que “ocurren” antes, otras después. Unas partes del producto se ejecutan en cliente, otras en el servidor. Hay cosas que se ejecutan en ambos sitios. Hay cosas que se ejecutan en cliente que se generan en servidor. Hay aplicaciones web que no tienen nada en servidor y las hay que no tienen nada en cliente.

Pero la industria, particularmente ciertos actores a los que les gustan las soluciones simplistas, ha decidido poner unos nombres “frontend” y “backend”. Y durante un tiempo, o en ciertos entornos, o bajo ciertas circunstancias, esos nombres más o menos aproximadamente pueden servir para representar algo más o menos específico o no tanto. Pero lo más habitual es que sea muy poco aproximado y muy poco específico.

Así que asúmelo. Tu visión de qué es el frontend, qué es backend, y si backend es aburrido, si frontend es lo que mola, si backend es donde está lo importante, si frontend es lo que marca la diferencia, si… Todo eso es estúpido. Hay muchas partes (muchas más de dos) y todas son importantes y todas son aburridas y todas marcan la diferencia y todas molan y todas son prescindibles y todas son un rollo.

La industria se mueve en las conferencias y grupos y mitaps y leches

Me río de tu conferencia llena de NuevasVerdades que no representa, ni de lejos, a la comunidad de desarrollo. Me río especialmente cuando me encuentro empresas intentando reclutar buenos programadores ahí.


Nota: Sí, claro. Muchas de estas cosas son aplicables al desarrollo en general, más allá del “desarrollo web”. Sí. Gracias por recordármelo. Qué haría yo sin ti.

1)
siempre es así, solo pegan la primera mitad de la cita
2)
Esto me costó que me despidieran de un trabajo anterior y aún así seguiré diciéndolo todas las veces que haga falta
3)
Y en realidad no la tienes porque “el frontend” no es nada, pero como esto ya es muy complicado, mejor no te voy a explicar esto, no sea que…
4)
Esta frase no es mía. Obviamente
5)
Esta sí es mía; se nota en lo insultante que es xD
6)
Esta evidentemente no es mía. Los que dicen esta frase, en su mayoría son idiotas