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.
Top comments (1)
ÂżPor que?