Tarea arquitectónica para entrevista para Go y Java

Desafío de entrevista arquitectónica: Evaluar el pensamiento de diseño del desarrollador

Esta tarea evalúa la comprensión de los principios SOLID, SRP y la flexibilidad del sistema. A los candidatos se les pide ampliar una estructura (o clase) existente para calcular salarios de empleados que también genera un informe PDF, ahora para incluir a los gerentes. Las restricciones clave: porcentajes de KPI y bonos iguales respecto al salario base, pero los gerentes tienen un salario base más alto. El sistema debe soportar cambios futuros con mínima interrupción.

Para Go, esto significa crear una estructura; para lenguajes basados en clases, una clase. Aunque parezca sencillo a primera vista, la tarea prueba la capacidad de detectar violaciones de diseño y construir una arquitectura escalable.

Errores comunes y solución impulsada por IA

La mayoría de los candidatos ignoran las violaciones de SRP: la estructura original mezcla cálculo de salario y generación de informes. La solución correcta es separar responsabilidades.

La solución con IA utiliza composición e interfaces:

• Una estructura base Empleado con campos compartidos (tasa, % de KPI, % de bono) y métodos (CalcularBase, CalcularKPI, CalcularBonos).
• Una interfaz CalculadorSalario con un método CalcularSalario() *Informe.
• Gerente compone Empleado y aplica un multiplicador para aumentar el salario base.
• Un GeneradorInforme dedicado acepta cualquier CalculadorSalario.
• Los constructores NuevoEmpleado y NuevoGerente manejan la inicialización.

Problema: un generador de informes no puede anticipar diferencias futuras (por ejemplo, número de reportes directos, horarios de KPI variables). Esto obliga a lógica condicional o reescritura, lo que viola OCP.

Retos ocultos en el enunciado

El planteamiento contiene intencionalmente trampas:

• Violación de SRP: "una clase que calcula salario... y crea un informe". Los candidatos deberían proponer una separación.
• Generalización falsa: "mismos porcentajes de KPI y bono". Las fórmulas podrían evolucionar independientemente por rol.
• Simplificación del rol: "solo difiere el salario base". Los gerentes son entidades empresariales distintas con KPIs y zonas de responsabilidad únicas.

Los candidatos fuertes hacen preguntas aclaratorias: ¿cómo cambian las fórmulas? ¿Qué datos van en el informe? ¿Se prevén nuevos roles?

Criterios de evaluación del candidato

La evaluación se centra en el pensamiento, no en el código:

• Preguntas realizadas: Clarifican requisitos y descubren supuestos ocultos.
• Justificación: Explica las decisiones de diseño (SOLID, composición vs herencia).
• Flexibilidad: Planea la evolución del sistema (añadir roles, formatos de informe).
• Análisis de pros y contras: Autoevaluación de la solución propuesta.
• Testabilidad: Componentes diseñados para aislamiento y pruebas unitarias.

Arquitectura recomendada

Una solución viable (estilo Go, adaptable a lenguajes orientados a objetos):

• Interfaces:

- CalculadorSalario: métodos para calcular base, KPI, bono, total.

- ProveedorDatosInforme: proporciona datos para el informe (salario, campos adicionales).

- PlantillaInforme: Generar(ProveedorDatosInforme) PDF.

• Implementaciones:

- SalarioEmpleado y SalarioGerente implementan CalculadorSalario.

- InformeEmpleado y InformeGerente implementan PlantillaInforme, cada uno con referencia a su CalculadorSalario correspondiente.

• Fábrica: NuevoInforme(tipoPlantilla string, calc CalculadorSalario) PlantillaInforme.

Beneficios:

• Fácil añadir nuevos roles (por ejemplo, SalarioDirector + InformeDirector).
• Sin lógica condicional en el generador de informes.
• La composición permite reutilizar componentes.

Conclusiones clave

• Aplicación de SRP: Cálculo y reporte son preocupaciones separadas.
• Cumplimiento de OCP: Nuevos roles se añaden sin modificar código existente.
• Composición sobre herencia: Permite adaptabilidad a largo plazo.
• Fábricas para encapsulación: Ocultan la complejidad de creación.
• Preguntas del candidato: Indican análisis profundo y reflexivo.

— Editorial Team