Saber Pro Diseño de Software common mistakes
Saber Pro Diseño de Software · Understand the traps and how to avoid them.
Responder preguntas de diseño eligiendo la opción que describe la solución tecnológicamente más avanzada (microservicios, eventos, caché distribuida) sin comparar con los requisitos de calidad y restricciones del enunciado.
El candidato asocia 'buen diseño' con modernidad y complejidad, y no con la satisfacción de atributos de calidad concretos; el enunciado suele describir un sistema pequeño con requisitos de simplicidad, costo o tiempo de entrega que hacen inadecuada la solución sofisticada.
What to do instead
Antes de mirar las opciones, extraer del enunciado los requisitos funcionales y los atributos de calidad con su prioridad (por ejemplo, mantenibilidad sobre escalabilidad). Descartar toda opción que no pueda justificarse con un requisito explícito y preferir la alternativa más simple que los cumpla (principio KISS/YAGNI).
Confundir patrones de diseño entre sí y seleccionar el patrón por su nombre popular: aplicar Singleton donde se pedía inyección de dependencias, Factory Method donde se pedía Abstract Factory, o Strategy donde el comportamiento varía por combinación de dos dimensiones y correspondía Bridge.
Se memorizan nombres y ejemplos canónicos sin entender la intención y la estructura de cada patrón; los enunciados describen el problema en lenguaje de negocio y no mencionan el patrón, por lo que la asociación superficial falla.
What to do instead
Estudiar cada patrón con tres elementos: problema que resuelve, diagrama de clases mínimo y consecuencia (qué se puede cambiar sin tocar qué). Practicar la clasificación por intención (creacional, estructural, de comportamiento) y resolver ejercicios donde se deba justificar por qué otro patrón cercano no aplica.
Elegir opciones que violan principios SOLID sin detectarlo, por ejemplo una clase que hereda de otra solo para reutilizar código aunque no sea sustituible (violación de LSP), o una interfaz con métodos que algunas implementaciones dejan vacíos (violación de ISP).
Los principios se estudian como definiciones aisladas y no como criterios de evaluación de un diseño dado; el candidato no traza el efecto de la violación sobre el mantenimiento o las pruebas.
What to do instead
Practicar la lectura crítica de diagramas de clases: para cada relación de herencia preguntar si la subclase puede usarse en todo lugar donde se usa la superclase; para cada interfaz, contar cuántas implementaciones necesitan todos sus métodos. Relacionar cada violación con un síntoma concreto (cambios en cascada, pruebas frágiles, condicionales por tipo).
No distinguir requisito funcional de atributo de calidad y, en consecuencia, proponer tácticas arquitectónicas (réplica, caché, cola) para problemas que en realidad son reglas de negocio mal modeladas.
Los enunciados mezclan ambos tipos y el candidato lee 'el sistema debe responder en menos de 2 segundos' como una funcionalidad más; también ocurre lo contrario, tratar una regla de negocio como problema de rendimiento.
What to do instead
Clasificar cada frase del enunciado en funcional, restricción o atributo de calidad, y anotar la métrica cuando exista. Solo después seleccionar la táctica correspondiente; si no hay métrica, la opción que promete una mejora cuantitativa no verificable suele ser incorrecta.
Interpretar diagramas UML de forma incorrecta: leer la multiplicidad al revés, confundir agregación con composición, tomar una flecha de dependencia como herencia o ignorar la notación de interfaz frente a clase.
Se estudia UML como vocabulario gráfico sin practicar la lectura de diagramas completos bajo presión de tiempo; la dirección de la asociación y el rombo lleno o vacío se confunden con facilidad.
What to do instead
Repasar la notación mínima (multiplicidad en ambos extremos, rombo relleno = composición con ciclo de vida dependiente, línea punteada = dependencia, triángulo hueco = generalización) y resolver ejercicios que pidan traducir un diagrama a código o a una frase en lenguaje natural y viceversa.
Responder sobre metodología o proceso (Scrum, iteraciones, roles) cuando la pregunta evalúa una decisión de diseño técnico, o atribuir a una metodología ágil propiedades que no tiene, como que elimina la necesidad de documentar decisiones arquitectónicas.
El candidato arrastra conocimiento general de gestión de proyectos y lo aplica como comodín; además, existe la creencia de que 'ágil' implica ausencia de diseño previo.
What to do instead
Identificar primero qué evalúa la pregunta: artefacto de diseño (diagrama, contrato de interfaz, decisión arquitectónica) o práctica de proceso. Recordar que en enfoques iterativos el diseño es emergente pero las decisiones estructurales significativas siguen registrándose y validándose con prototipos o spikes.
Ignorar el contexto de despliegue y las restricciones no funcionales del enunciado (por ejemplo, equipo de dos personas, presupuesto limitado, sistema legado, requisito de operar sin conexión) y proponer una arquitectura que exige infraestructura u operación que el escenario no permite.
El candidato se concentra en el problema técnico y descarta las restricciones como texto de relleno; las opciones de arquitectura suelen diferir precisamente en el costo operativo y la complejidad organizacional.
What to do instead
Subrayar en cada enunciado las restricciones de equipo, presupuesto, legado y entorno de ejecución, y descartar opciones que las contradigan aunque sean técnicamente elegantes. Justificar la elección indicando qué restricción respeta.
Confundir el nivel de abstracción de los artefactos: poner detalles de implementación en un diagrama de componentes o de despliegue, o incluir clases de infraestructura en un diagrama de dominio, y luego elegir la opción que 'parece más completa'.
No se tiene claro el propósito de cada vista del modelo; se cree que un diagrama con más elementos es mejor, cuando el criterio es que responda a la pregunta que esa vista debe contestar.
What to do instead
Asociar cada vista con su pregunta: dominio (conceptos y reglas), clases de diseño (estructura de software), componentes (unidades desplegables y sus contratos), despliegue (nodos físicos o de infraestructura), secuencia (interacción en el tiempo). Evaluar si cada elemento del diagrama pertenece a ese nivel.
En preguntas sobre refactorización o deuda técnica, elegir la opción que reescribe todo el sistema desde cero en lugar de la que aplica cambios pequeños y verificables con pruebas, o viceversa, sin analizar el riesgo descrito.
Se asocia 'mejorar el diseño' con una gran reescritura; también se subestima el papel de la suite de pruebas como red de seguridad que hace viable la refactorización incremental.
What to do instead
Recordar que refactorizar es cambiar la estructura preservando el comportamiento observable, lo que exige pruebas automatizadas y pasos pequeños. Comparar opciones por riesgo, reversibilidad y tiempo hasta obtener valor; la reescritura total solo se justifica cuando el enunciado indica que el costo de mantener supera claramente el de reemplazar.
Administrar mal el tiempo: quedarse demasiado en preguntas de cálculo o de diagrama complejo y llegar al final sin responder preguntas conceptuales que se resuelven en segundos, o cambiar respuestas correctas por dudas de última hora sin una razón concreta.
La prueba combina preguntas de distinta dificultad y no penaliza de forma equivalente el tiempo invertido; la ansiedad lleva a revisar sin criterio y a modificar respuestas fundamentadas.
What to do instead
Hacer una primera pasada respondiendo lo seguro y marcando lo dudoso, con un límite de tiempo por pregunta; en la segunda pasada volver solo a las marcadas. Cambiar una respuesta únicamente si se identifica un error concreto en el razonamiento, no por sensación de inseguridad.