This content originally appeared on DEV Community and was authored by AzuNico
Nota: Esta entrada forma parte de una serie de artículos sobre diseño de software en el frontend que estaré publicando próximamente.
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.
🎯 ¿Qué te vas a llevar de esta serie?
Mi objetivo no es enseñarte la única forma correcta de hacer las cosas (porque no existe), sino mostrar lo que fui aprendiendo con la práctica y la lectura de ciertos libros y cursos que me abrieron la mente.
Voy a intentar traducir conceptos como entidades, casos de uso, inyección de dependencias y separación de capas al contexto de una app móvil. Dejando por momentos de lado los detalles (frameworks, librerías, etc.), sin exagerar con la teoría, y sobre todo: con ejemplos concretos.
Aclaración
Si bien los ejemplos estarán orientados al frontend móvil, los conceptos pueden ser trasladados a otros tipos de aplicación, ya sea web o backend.
⚛️ ¿Por qué con React Native CLI y TypeScript?
Elegí React Native CLI porque es la herramienta con la que más experiencia tengo y me siento más cómodo. Además, usaré TypeScript para aprovechar sus ventajas en tipado estático, lo que ayuda a escribir código más seguro y mantenible.
Noto que hay poco material en español sobre temas profundos de React Native combinados con TypeScript, y este es mi pequeño aporte.
¿Qué App desarrollaremos?
Para darle un enfoque más didáctico y divertido, decidí usar como ejemplo una App Pokémon para desarrollar.
🧢 App de entrenador Pokémon (modo entrenador, no Pokédex)
Requisitos de la app: Domina la lógica de captura, mochila, guardería, equipo (máx. 6 Pokémon), tipo de Pokébolas.
🧭 Índice de la serie
- 🤔 ¿Por qué debes aprender diseño de software en el frontend? ✅
Próximamente:
- 🧩 Diseño y Modelado: ¿son lo mismo?
- 🧠 Paradigmas de programación aplicados al diseño
- 🛠️ Principios de diseño vs patrones de diseño
- ☢️ Code Smells en el frontend
- 🧱 Principios SOLID con ejemplos prácticos en React Native
- 📦 Introducción a Domain-Driven Design (DDD)
- 🏗️ Arquitectura Limpia en React Native
- 🔷 Arquitectura Hexagonal en React Native
- ✔️ Introducción a Test Driven Design (TDD)
- 📊 Diagramas UML: ¿Valen la pena?
- 🧪 Tests más robustos con el patrón Test API en React Native
🙌 Gracias por estar acá
Si te interesa el tema, o te sentís identificado con lo que conté, te invito a seguir la serie.
Y si te sirve, compartilo con alguien más: capaz también está buscando una forma de trabajar con más claridad y menos frustración.
This content originally appeared on DEV Community and was authored by AzuNico
AzuNico | Sciencx (2025-07-28T00:52:46+00:00) ¿Por qué debes aprender diseño de software en el frontend?. Retrieved from https://www.scien.cx/2025/07/28/por-que-debes-aprender-diseno-de-software-en-el-frontend/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.