🧠 Test: ¿Cuánto Sabes de Programación Intermedia? | Conceptos Clave Explicados

¿Te consideras un programador con conocimientos intermedios? Este test va más allá de la sintaxis y se adentra en los principios, buenas prácticas y la mentalidad que realmente marcan la diferencia en proyectos reales. ¡Descubre tu nivel y profundiza con explicaciones detalladas! 🚀

🔍 Instrucciones

Responde las 30 preguntas basándote en tu experiencia y conocimiento. Al final, suma tus aciertos y encuentra tu perfil.

1. ¿Qué es más importante en código que otros van a leer?

A) Rendimiento
B) Legibilidad ✅
C) Velocidad

👉 Explicación Profunda:
La célebre frase de «El código se lee más veces de las que se ejecuta» es un pilar de la ingeniería de software. Un código optimizado para ser leído por humanos reduce el tiempo de onboarding de nuevos desarrolladores, facilita las revisiones de código (code reviews), y hace que el mantenimiento y la depuración sean exponencialmente más eficientes. La legibilidad incluye: nombres significativos de variables y funciones, estructura clara, y la adherencia a convenciones del equipo. Un código ilegible, aunque funcione, se convierte en una «caja negra» que nadie quiere tocar, incrementando la deuda técnica. El rendimiento y la velocidad son importantes, pero primero debe ser correcto y claro. Optimizar prematuramente un código críptico es contraproducente.

2. En proyectos reales, ¿qué se valora más?

A) Que funcione
B) Que sea bonito
C) Que sea mantenible ✅

👉 Explicación Profunda:
El software empresarial tiene un ciclo de vida que dura años, incluso décadas. La fase de desarrollo inicial es solo un pequeño porcentaje de su vida total. Un código que simplemente «funciona» pero es un caos (spaghetti code) se vuelve una pesadilla al primer cambio de requisitos. La mantenibilidad es la cualidad que permite que el software evolucione de manera segura y eficiente. Esto implica: bajo acoplamiento, alta cohesión, tests automatizados y documentación adecuada. Un proyecto mantenible ahorra miles de horas y recursos financieros a largo plazo, mientras que uno solo «funcional» puede hundir un producto.

3. ¿Qué suele causar más problemas a largo plazo?

A) Bugs pequeños
B) Mal diseño ✅
C) Lenguaje

👉 Explicación Profunda:
Un bug pequeño es localizado y, aunque molesto, su impacto suele estar acotado. Un mal diseño arquitectónico es sistémico y corroe el proyecto desde sus cimientos. Ejemplos clásicos son: la falta de separación de responsabilidades, un acoplamiento excesivo entre módulos, o la elección de una arquitectura inadecuada para los requisitos de escalabilidad. Estos problemas generan un goteo constante de errores nuevos, hacen que cada característica nueva cueste más implementar (ley de la maleabilidad del software), y a menudo requieren refactorizaciones dolorosas y costosas. El lenguaje de programación es una herramienta; un buen diseño puede implementarse en muchos de ellos.

4. En producción, ¿qué es más peligroso?

A) Error menor
B) Código lento
C) Código confuso ✅

👉 Explicación Profunda:
Un error menor con un stack trace claro puede ser parcheado rápidamente. Un código lento se puede perfilar y optimizar. Sin embargo, el código confuso es una bomba de tiempo. Cuando ocurre un incidente en producción y nadie en el equipo entiende cómo funciona o por qué falla un módulo críptico, el tiempo de resolución (MTTR – Mean Time To Recovery) se dispara. La confusión lleva a parches tentativos que pueden empeorar la situación. Este tipo de código destruye la confianza del equipo y hace que la operación sea riesgosa. La claridad es un requisito no funcional crítico para sistemas en producción.

5. ¿Qué aporta más valor con el tiempo?

A) Comentarios
B) Tests ✅
C) Framework

👉 Explicación Profunda:
Los comentarios pueden quedar desactualizados y convertirse en desinformación. Los frameworks van y vienen con las tendencias. Pero una suite de tests automatizada robusta (unitarios, de integración, E2E) es un activo que crece en valor. Actúan como una red de seguridad que:

1. Evita regresiones: Permite refactorizar con confianza.
2. Documenta el comportamiento: Los tests bien nombrados muestran cómo se supone que debe usarse el código.
3. Facilita la integración continua: Permiten desplegar con mayor frecuencia y menor riesgo.
   Los tests protegen la inversión en el código a lo largo del tiempo, algo que ni los comentarios ni el framework de moda pueden hacer por sí solos.

6. ¿Qué se intenta evitar en código limpio?

A) Muchas clases
B) Muchas funciones
C) Magia ✅

👉 Explicación Profunda:
La «magia» en programación se refiere a comportamientos implícitos, efectos secundarios no obvios, metaprogramación excesiva o frameworks que hacen «cosas detrás de la cortina» de forma opaca. Esto viola el Principio de Menor Sorpresa. El código debe ser predecible y explícito. Si al leer una función no puedes razonar sobre lo que hará sin conocer los detalles internos de un framework o una librería, estás ante código mágico. Esto aumenta drásticamente la curva de aprendizaje, dificulta la depuración y crea dependencias ocultas. Muchas clases o funciones pequeñas y bien nombradas son preferibles a una «poción mágica» que lo hace todo pero nadie entiende.

7. ¿Qué describe mejor la deuda técnica?

A) Código rápido
B) Código descuidado ✅
C) Código antiguo

👉 Explicación Profunda:
La deuda técnica es una metáfora acuñada por Ward Cunningham. Es el costo adicional de rework que surge cuando se opta por una solución rápida o fácil (código descuidado) en lugar de un enfoque bien diseñado que tomaría más tiempo. Como una deuda financiera, acumula intereses: cada nueva funcionalidad construida sobre ese código descuidado será más costosa y propensa a errores. El código antiguo no es necesariamente deuda técnica si está bien diseñado. El código rápido podría ser deuda si el atajo compromete la calidad. La esencia es el descuidado deliberado a cambio de un beneficio inmediato, que se paga caro después.

8. ¿Qué se recomienda para la mayoría de proyectos?

A) Microservicios
B) Monolito simple ✅
C) Código mezclado

👉 Explicación Profunda:
Los microservicios añaden una enorme complejidad operacional (orquestación, redes, resiliencia, monitorización distribuida). Son excelentes para equipos muy grandes y sistemas que realmente necesitan escalar componentes de forma independiente. Sin embargo, para la gran mayoría de proyectos (especialmente al inicio), un monolito bien estructurado es la opción más sensata. Es más simple de desarrollar, probar, desplegar y debuggear. La clave es mantenerlo modular por dentro (arquitectura hexagonal, clean architecture) para que, si el día de mañana se requiere, sea más fácil extraer servicios. Empezar con microservicios sin necesidad es un caso clásico de sobreingeniería.

9. ¿Qué genera más conflictos en equipos de desarrollo?

A) Lenguaje usado
B) Estilos distintos ✅
C) Editor

👉 Explicación Profunda:
La inconsistencia es el enemigo de la productividad en equipo. Si cada desarrollador usa una convención de nombres diferente, un estilo de indentación distinto, o patrones de diseño opuestos para problemas similares, el código base se convierte en un mosaico impredecible. Esto frena las revisiones de código (que se centran en el estilo y no en la lógica), dificulta la movilidad de desarrolladores entre módulos y genera fricción. La solución es establecer y hacer cumplir guías de estilo (con herramientas como linters y formateadores automáticos) y convenciones de equipo desde el día uno. Un lenguaje o editor se puede estandarizar fácilmente; un estilo desorganizado es más difícil de corregir.

10. ¿Qué NO asegura calidad de código?

A) Tener tests
B) Años trabajando
C) Framework famoso ✅

👉 Explicación Profunda:
Esta pregunta desmitifica una idea común. Un framework (React, Spring, Django) proporciona una estructura y herramientas, pero no escribe el código por ti. Se puede escribir código espagueti, acoplado y difícil de testear dentro del framework más moderno. La calidad del código depende de las decisiones del desarrollador: cómo estructura la lógica de negocio, gestiona el estado, separa responsabilidades y escribe tests. Un framework es solo el andamio; el edificio (la calidad) lo construye el equipo. Confiar ciegamente en que un framework garantiza calidad es un error peligroso.

11. ¿Cuándo hablamos de sobreingeniería?

A) Demasiados patrones ✅
B) Buen diseño
C) Tests

👉 Explicación Profunda:
La sobreingeniería ocurre cuando se introduce complejidad innecesaria para resolver un problema simple o anticipando requisitos futuros que pueden nunca materializarse («You Ain’t Gonna Need It» – YAGNI). Usar 5 patrones de diseño, un bus de eventos y 10 capas de abstracción para un CRUD simple es un ejemplo clásico. El buen diseño busca la solución más simple que satisfaga los requisitos actuales y sea razonablemente modificable. La sobreingeniería aumenta la carga cognitiva, ralentiza el desarrollo inicial y hace que el sistema sea más rígido, no más flexible.

12. ¿Qué suele optimizarse primero cuando hay problemas?

A) Código
B) Algoritmo ✅
C) Servidor

👉 Explicación Profunda:
Es la aplicación del principio de la complejidad algorítmica. Un algoritmo ineficiente (ej: O(n²)) no se arregla lanzando más hardware (escalamiento horizontal/vertical) o micro-optimizando líneas de código. El costo computacional crece de forma inmanejable con la entrada de datos. Lo primero es revisar y elegir el algoritmo y la estructura de datos adecuados (ej: cambiar una búsqueda lineal por una búsqueda binaria O(log n), o usar un hash map para acceso O(1)). Después de tener un algoritmo óptimo, se puede perfilar el código para optimizaciones específicas. Empezar por el servidor es tapar el sol con un dedo.

13. ¿Qué se considera una mala práctica común?

A) Variables globales ✅
B) Clases
C) Funciones

👉 Explicación Profunda:
Las variables globales (o estados globales mutables) crean acoplamiento oculto y efectos secundarios impredecibles. Cualquier parte del código puede leer o modificar una variable global, haciendo que sea extremadamente difícil razonar sobre el flujo del programa, probar las funciones de forma aislada (unit testing) y depurar errores. Rompen la encapsulación y son la antítesis del diseño modular. En su lugar, se debe favorecer la inyección de dependencias y el paso explícito de parámetros. Son un vestigio de la programación antigua que persiste como un anti-patrón peligroso.

14. ¿Qué suele causar más problemas que beneficios?

A) Código claro
B) Código limpio
C) Optimización prematura ✅

👉 Explicación Profunda:
Donald Knuth lo dijo mejor: «La optimización prematura es la raíz de todo mal». Optimizar antes de tener un código funcional, claro y medido con un profiler, lleva a:

1. Código más complejo y difícil de mantener.
2. Puede introducir bugs sutiles.
3. Frecuentemente, se optimiza lo que no es un cuello de botella real, desperdiciando esfuerzo.
   Primero, hazlo funcionar correctamente. Luego, hazlo claro y mantenible. Finalmente, mide el rendimiento para identificar los cuellos de botella reales (regla del 90/10) y optimiza solo esas partes críticas. La claridad y corrección son siempre prioridad.

15. ¿Qué factor introduce más errores?

A) Complejidad ✅
B) Tamaño
C) Lenguaje

👉 Explicación Profunda:
La complejidad ciclomática (una métrica que mide la cantidad de caminos independientes en un programa) está directamente correlacionada con la cantidad de bugs. Un código complejo, con muchos condicionales anidados, bucles profundos y estados mutables, es difícil de analizar mentalmente, de testear exhaustivamente y de modificar sin efectos colaterales. Un código grande pero bien modularizado (dividido en componentes simples) puede ser muy robusto. El lenguaje influye en la expresividad, pero un mal diseño puede ser complejo en cualquier lenguaje. Reducir la complejidad es el objetivo central del diseño de software.

16. En un equipo, ¿qué es más importante?

A) Nivel técnico
B) Comunicación ✅
C) Framework

👉 Explicación Profunda:
Un equipo de «rockstars» que no se comunican, no comparten conocimiento y no alinean su visión, está condenado al fracaso. La comunicación efectiva (reuniones técnicas claras, documentación viva, revisiones de código constructivas, transparencia sobre problemas) es el lubricante que permite que el talento técnico individual se convierta en valor de equipo. Permite identificar dependencias, unificar criterios de diseño, y crear un código coherente y colectivo. Un equipo B+ que se comunica excelentemente, superará a un equipo A+ de islas técnicas. El framework es, nuevamente, solo una herramienta.

17. ¿Qué suele fallar primero en producción?

A) Servidor
B) Código sin tests ✅
C) Base de datos

👉 Explicación Profunda:
Los servidores y las bases de datos suelen tener mecanismos de redundancia, réplicas y backups. El eslabón más débil suele ser el código nuevo o modificado que se despliega sin una red de seguridad de pruebas automatizadas. Un error de lógica, un caso límite no considerado, o un cambio que rompe una funcionalidad existente pasan desapercibidos y llegan directamente a los usuarios. Los tests actúan como el primer y más importante filtro de calidad. Un despliegue sin tests confiables es como caminar sobre una cuerda floja sin red: puede que llegues, pero el riesgo es enorme e innecesario.

18. En una revisión de código, ¿qué se prefiere?

A) Que funcione
B) Claro y simple ✅
C) Muy corto

👉 Explicación Profunda:
El objetivo de una code review no es solo verificar que el código funciona (eso lo deberían hacer los tests), sino elevar la calidad colectiva del código base y compartir conocimiento. Un código claro y simple es más fácil de revisar, de entender para futuros mantenedores y de refactorizar. La simplicidad (no confundir con simplismo) es un signo de maestría. Un código corto pero críptico (ej: one-liners complejos) o «funcional» pero desordenado, no supera una buena revisión. Se prefiere un código un poco más largo pero legible, sobre uno corto e incomprensible.

19. ¿Qué problema aparece al crecer un sistema?

A) El código
B) La arquitectura ✅
C) El lenguaje

👉 Explicación Profunda:
Al inicio, un sistema pequeño puede funcionar con una arquitectura ad-hoc o incluso sin arquitectura definida. El problema surge al escalar: más funcionalidades, más desarrolladores, más tráfico. Si la arquitectura no fue pensada para ese crecimiento (ej: no es modular, no define límites claros entre componentes, no considera la escalabilidad de datos o concurrencia), el sistema se vuelve un «big ball of mud». Cada cambio se vuelve costoso e impredecible. El código y el lenguaje son detalles de implementación dentro de un marco arquitectónico. Una buena arquitectura permite que el código crezca de manera ordenada y el sistema evolucione.

20. ¿Cuál es un anti-patrón común?

A) Singleton mal usado
B) God Object ✅
C) MVC

👉 Explicación Profunda:
El «God Object» (Objeto Dios) es un anti-patrón que viola el Principio de Responsabilidad Única (SRP) de manera extrema. Es una clase o módulo que «sabe y hace demasiado»: controla numerosas funcionalidades no relacionadas, tiene miles de líneas de código y un alto acoplamiento con el resto del sistema. Se convierte en un punto de cambio constante, es muy difícil de testear y es un cuello de botella para el desarrollo paralelo. MVC es un patrón arquitectónico válido. El Singleton puede ser un anti-patrón si se usa mal, pero el God Object es casi siempre una mala decisión de diseño.

21. ¿Qué práctica suele ser mala señal?

A) Refactorizar
B) Copiar código ✅
C) Documentar

👉 Explicación Profunda:
Copiar y pegar código (Copy-Paste Programming) es uno de los mayores generadores de deuda técnica. Duplica no solo líneas de código, sino también bugs. Si se encuentra un error en la lógica copiada, hay que corregirlo en todos los lugares, algo que es fácil de olvidar. Además, indica una falta de abstracción: si una funcionalidad se usa en múltiples lugares, probablemente deba estar encapsulada en una función, clase o módulo reutilizable. El refactorizar es una práctica saludable para mejorar el diseño. Documentar, aunque a veces subestimado, es necesario.

22. ¿Qué puede ocultar errores graves?

A) Try/Catch vacío ✅
B) Logs
C) Tests

👉 Explicación Profunda:
Un bloque try { ... } catch (Exception e) {} (vacío o que solo imprime un log genérico) es como poner cinta adhesiva sobre la luz del «check engine» del coche. El error sigue ocurriendo, pero el sistema pierde la capacidad de notificarlo o manejarlo apropiadamente. Esto puede ocultar fallos de conexión a bases de datos, errores de lógica, o problemas de permisos, que se manifiestan después como datos corruptos o comportamientos inesperados muy difíciles de rastrear. El manejo de excepciones debe ser deliberado: relanzar, convertir, o manejar con una lógica de recuperación clara. Nunca silenciarlas.

23. ¿Qué es más difícil de mantener?

A) Código largo
B) Código acoplado ✅
C) Código viejo

👉 Explicación Profunda:
El alto acoplamiento significa que los módulos del sistema dependen demasiado de los detalles internos de otros módulos. Esto crea un «efecto dominó»: un cambio aparentemente inocuo en el módulo A puede romper inesperadamente los módulos B, C y D. Hace que cada modificación requiera un análisis exhaustivo de impacto, aumenta el riesgo de los despliegues y frena la innovación. Un código largo pero con bajo acoplamiento (ej: una función larga pero autónoma) es más manejable. La clave del diseño es crear módulos cohesionados y débilmente acoplados.

24. ¿Qué debería versionarse siempre?

A) Código
B) Configuración
C) Todo ✅

👉 Explicación Profunda:
En el desarrollo moderno, se sigue la filosofía «Everything as Code» (IaC – Infrastructure as Code, config as code). El sistema de control de versiones (Git) debe contener no solo el código fuente, sino también:

• Scripts de construcción y despliegue (Dockerfile, CI/CD pipelines).
• Configuraciones de infraestructura (Terraform, CloudFormation).
• Configuraciones de la aplicación (por entorno).
• Documentación.
  Esto garantiza reproducibilidad, trazabilidad y la capacidad de restaurar o recrear cualquier versión del sistema completo de manera fiable. Versionar solo el código deja fuera piezas críticas.

25. ¿Qué suele ser subestimado por programadores?

A) Documentación ✅
B) Framework
C) Lenguaje

👉 Explicación Profunda:
La documentación (especialmente la técnica: READMEs, ADRs – Architecture Decision Records, comentarios de «por qué» y no «qué») es vista a menudo como una tarea burocrática. Sin embargo, es un regalo para el «yo del futuro» y para los compañeros de equipo. Responde preguntas como: ¿Por qué se eligió esta solución y no otra? ¿Cómo se despliega este servicio? ¿Cuáles son las dependencias clave? Una buena documentación reduce el tiempo de incorporación de nuevos miembros, evita que se repitan debates ya resueltos y preserva el conocimiento institucional cuando alguien deja el equipo.

26. ¿Qué NO indica buen código?

A) Funciona
B) Escala
C) Es difícil de leer ✅

👉 Explicación Profunda:
Esta es una verdad fundamental: «Buen código» es, ante todo, código que se puede leer y entender fácilmente por otros desarrolladores (o por ti mismo en 6 meses). Si un código funciona pero es críptico, no es buen código, es un artefacto frágil. La capacidad de escalar es deseable, pero no a costa de la legibilidad. Atributos como la mantenibilidad, la testabilidad y la claridad son indicadores de calidad mucho más importantes que la mera funcionalidad. Un código difícil de leer es una carga, no un logro.

27. En empresas, ¿qué se prioriza más?

A) Velocidad
B) Estabilidad ✅
C) Innovación

👉 Explicación Profunda:
En un entorno empresarial (especialmente con sistemas de misión crítica o que generan ingresos directos), la estabilidad y confiabilidad son primordiales. Una caída o un error grave puede costar millones, dañar la reputación de la marca y erosionar la confianza del cliente. Se valora la velocidad de entrega (entrega continua), pero nunca a costa de la estabilidad. La innovación es importante para crecer, pero se realiza en entornos controlados (feature toggles, canary releases). La mentalidad es: «Mueve rápido, pero no rompas cosas». En producción, no romper cosas es la prioridad #1.

28. ¿Qué se debe evitar en producción?

A) Debug
B) Logs
C) Print() ✅

👉 Explicación Profunda:
Usar print(), console.log(), o System.out.println() como mecanismo de logging en producción es una práctica amateur y peligrosa. Estos mensajes:

1. No tienen niveles de severidad (INFO, ERROR, DEBUG).
2. Son difíciles de filtrar o redirigir.
3. Pueden saturar las salidas estándar y afectar el rendimiento.
4. No suelen incluir metadatos críticos (timestamp, thread ID, request ID).
   En producción, se debe usar un sistema de logging estructurado (ej: con librerías como Log4j, Winston, Serilog) que integre con sistemas de agregación de logs (ELK, Datadog, CloudWatch). Los logs son esenciales; los print() son un parche desordenado.

29. ¿Qué suele fallar más al iniciar en programación?

A) Sintaxis
B) Lógica
C) Diseño ✅

👉 Explicación Profunda:
Los principiantes se enfocan en superar las barreras de la sintaxis del lenguaje y en hacer que sus programas funcionen para casos específicos. El diseño del software—cómo estructurar el código en módulos, cómo manejar el estado, cómo planificar para el cambio—es una habilidad de nivel superior que se desarrolla con la experiencia y el estudio de principios (SOLID, patrones de diseño). Es común ver proyectos de principiantes donde todo el código está en un solo archivo, con funciones gigantes y variables globales. No piensan en la estructura porque están resolviendo el problema inmediato, no construyendo un sistema mantenible.

30. ¿Qué diferencia a un buen programador?

A) Lenguaje
B) Años
C) Decisiones ✅

👉 Explicación Profunda:
Cualquiera puede aprender la sintaxis de un lenguaje (A). La experiencia (B) ayuda, pero no garantiza buenas decisiones. Lo que separa a los buenos programadores es la calidad de sus decisiones técnicas:

• ¿Cuándo es el momento de refactorizar?
• ¿Qué patrón aplicar a este problema?
• ¿Cómo equilibrar entre perfección y tiempo de entrega?
• ¿Dónde invertir en tests?
• ¿Cuándo decir «no» a un requisito mal definido?
  Estas decisiones, tomadas constantemente, definen la trayectoria de un proyecto y el valor que un programador aporta al equipo. Es la diferencia entre escribir código y hacer ingeniería de software.

📊 Calcula Tu Puntuación y Descubre Tu Perfil

Cuenta cuántas respuestas correctas marcaste (las que tienen ✅).

• 0 – 10 Aciertos: 🐣 Modo Aprendiz. Estás dominando los fundamentos. ¡Sigue así! Profundiza en los conceptos de este test; te darán una ventaja enorme.
• 11 – 20 Aciertos: 🔧 En Construcción. Tienes buena base y experiencia práctica. Ahora es el momento de reflexionar sobre las decisiones de diseño y arquitectura que tomas día a día.
• 21 – 26 Aciertos: 🚀 Buen Flow. Entiendes los principios clave del software en el mundo real. Eres un activo valioso para cualquier equipo que busque construir cosas que duren.
• 27 – 30 Aciertos: 🧠 Mente Técnica. Tu conocimiento va más allá de escribir código. Piensas en sistemas, en equipos y en el largo plazo. Probablemente tengas un rol de liderazgo técnico o estés listo para asumirlo.

💬 ¿Cómo te fue? ¡Cuéntanos tu resultado y comparte este test con tus compañeros para ver cómo les va!
🔗 #TestProgramación #DesarrolloSoftware #BuenasPrácticas #IngenieríaDeSoftware #CódigoLimpio