This content originally appeared on DEV Community and was authored by AzuNico
Un poco de contexto
En un contexto en el que la inteligencia artificial gana cada vez más terreno, si queremos destacarnos como desarrolladores —y que la IA sea un potenciador de nuestras habilidades y no “algo que nos va a quitar el trabajo”— es fundamental que dominemos las bases y fundamentos del diseño de software.
En paralelo, vivimos una época de gran accesibilidad al desarrollo frontend, lo cual es algo positivo. Cada vez más personas ingresan al mundo del código gracias a bootcamps, cursos acelerados y plataformas accesibles.
Pero esa misma accesibilidad también tiene un efecto colateral: muchas veces se aprende primero a usar un framework sin comprender las bases que sostienen un software bien diseñado. Y eso genera código que funciona… pero es difícil de mantener, escalar o probar.
No es una crítica a quienes están empezando —todos arrancamos sin saber mucho, y eso está bien—, sino una invitación a ir más allá del “cómo se hace” y empezar a entender el “por qué se hace así”, y desarrollar criterio propio a la hora de programar.
Como dice el dicho: “Si todo lo que tenés es un martillo, todo te parece un clavo.”
Y eso es justamente lo que pasa cuando lo único que conocemos son herramientas, como useEffect, Context o Redux: intentamos resolver todo desde la UI, aunque no siempre sea el mejor lugar.
Aunque el frontend se ubica en los extremos del sistema, es el punto de contacto crítico con el usuario. Una interacción fallida —como un botón que no responde— puede hacer irrelevante toda la lógica del backend. Esto no solo afecta la experiencia, sino que compromete la percepción de calidad del producto, generando pérdida de tiempo, dinero y confianza.
Por eso es tan importante escribir código que no solo funcione, sino que pueda crecer, adaptarse y sostenerse a largo plazo. Conocer los principios que hacen que un software sea mantenible no es opcional: es parte del oficio.
Mi recorrido personal
Después de varios años desarrollando aplicaciones frontend con React y React Native, me di cuenta de algo: cada vez que tenía que mantener una base de código antigua —incluso una que había escrito yo mismo meses atrás— me preguntaba:
¿Por qué este código tiene que ser tan complicado? ¿Qué hice? ¿Qué significa “data”? ¿Será que esta carrera es para mí?
En mis comienzos como desarrollador frontend, me he encontrado con componentes con varias líneas de código, difíciles de entender y seguir. Cuando entregaba una nueva versión al equipo de QA con una nueva funcionalidad o fixes, siempre volvía a mí con nuevos bugs o “muertos vivos” que creía solucionados, pero que —por alguna extraña razón— reaparecían.
Cansado de esa situación, pensé que tenía que haber una forma mejor de hacer las cosas. Intuía que debía haber una manera de escribir código con menos fricción. Fue entonces cuando comencé a buscar y descubrí un mundo de libros y conceptos como Patrones de Diseño, principios SOLID, Arquitectura Limpia y Tests Unitarios (¿y esto último con qué se come?).
Entré al mundo de la informática sin una formación académica tradicional —sin carrera universitaria, más bien gracias a cursos, bootcamps y mucha perseverancia— y sentía que me faltaban ciertas bases. Pensaba que esas cosas “se enseñaban en la universidad”, y que por no haber pasado por ahí, me estaba perdiendo algo fundamental.
Con el tiempo entendí que no era tan así. Muchos de esos contenidos no están tan presentes en el ámbito académico, sino que hay que buscarlos por cuenta propia.
Leí libros como Clean Architecture de Robert C. Martin, y me sumergí en Domain-Driven Design de Eric Evans. Aunque me abrieron la cabeza, también me dejaron con muchas preguntas:
- ¿Cómo aplico estos principios en una app frontend?
- ¿Qué sentido tiene hablar de entidades o casos de uso dentro de un componente de React?
- ¿Dónde termina el dominio y empieza la UI?
- ¿A qué llaman dominio?
- ¿Qué significa diseño de software?
- ¿Qué es un modelo y para qué sirve el modelado?
Hace casi dos años decidí estudiar una tecnicatura en programación para cerrar esa etapa personal y sacarme el síndrome del impostor. La universidad me enseñó muchas cosas y me abrió aún más la mente, pero incluso al borde de graduarme, veo que estos temas específicos que quiero compartir con ustedes siguen sin divulgarse lo suficiente.
Por eso, esta serie es mi intento de acercarles, a mi manera y con lo que fui aprendiendo durante estos años, esos conceptos que considero clave para escribir mejor código en el frontend. No pretendo mostrar “la forma correcta”, sino divulgar ideas que puedan ser aplicadas según el contexto, y no por dogma.
¿Te pasó esto?
- El código funciona, pero nadie quiere tocarlo.
- Un feature nuevo termina rompiendo otros sin que te des cuenta.
- Tenés lógica duplicada en distintos lugares de la app.
- No sabés dónde poner cierta lógica, así que termina en
helpers.jsoutils.ts. - Funciones con muchos
ifsoswitchesque se vuelven difíciles de seguir. - Querés aplicar pruebas unitarias, pero el código está tan acoplado que parece imposible.
- No sabés cómo diseñar una app ni por dónde empezar.
A mí también. Por eso, en esta serie de artículos que iré publicando, mi objetivo es acercarte conceptos que fui aprendiendo a lo largo de mi camino como desarrollador. Tal vez te sirvan y sumes herramientas a tu repertorio.
Conclusión
¿Por qué deberías aprender diseño de software en el frontend?
Porque dominar el diseño de software te convierte en un mejor desarrollador. Te permite tomar decisiones más sólidas, escribir código que escala, colaborar mejor con tu equipo y aprovechar la IA como una verdadera extensión de tu capacidad técnica. No se trata solo de escribir código que funciona, sino de construir soluciones que perduran.
Gracias por estar acá
Si te interesa el tema, o te sentís identificado con lo que conté, te invito a seguir la serie.
This content originally appeared on DEV Community and was authored by AzuNico