Frankenstein en programación — qué es, causas y prevención

Qué es Frankenstein en programación

Frankenstein (código Frankenstein, patrón Frankenstein) es un antipatrón donde un sistema de software se ensambla a partir de partes no diseñadas para trabajar juntas. Como el monstruo de Frankenstein, ese código puede funcionar, pero es feo, impredecible y peligroso ante el más mínimo cambio.

El término proviene de la literatura: en la novela de Mary Shelley “Frankenstein o el moderno Prometeo” (1818), un científico creó un ser vivo a partir de fragmentos de cuerpos de diferentes personas muertas. En programación, la analogía es exacta: los desarrolladores toman fragmentos de diferentes frameworks, bibliotecas, idiomas y los pegan “en vivo”, obteniendo un resultado funcional pero monstruoso.

La diferencia entre Frankenstein y el código espagueti está en la escala y la naturaleza. El código espagueti es una estructura enredada dentro de un mismo stack tecnológico. Frankenstein es eclecticismo a nivel de arquitectura: diferentes tecnologías, paradigmas incompatibles, enfoques conflictivos dentro del mismo sistema.

Frankenstein vs Microservicios

La arquitectura de microservicios permite usar diferentes tecnologías para diferentes servicios, pero con límites claros y protocolos de interacción estandarizados. Frankenstein es una mezcla caótica sin límites: REST y GraphQL en un mismo controlador, dos ORM en un mismo módulo, SQL y NoSQL para una misma entidad.

Por qué surge el síndrome de Frankenstein

La falta de un líder técnico o arquitecto es la causa raíz. Cuando no hay una persona responsable de la integridad arquitectónica, cada desarrollador elige herramientas “para sí mismo”. A uno le gusta Spring, a otro Guice, un tercero usa un DI casero. El resultado es una mezcolanza arquitectónica.

La fusión de proyectos es la segunda causa común. Dos equipos desarrollaron sus módulos de forma independiente, usando stacks diferentes. Cuando los módulos deben combinarse en una sola aplicación, simplemente se “pegan” con adaptadores y capas intermedias. El resultado es Frankenstein.

Las adquisiciones corporativas son el tercer escenario. La empresa A compró la empresa B y quiere integrar su producto en el suyo. En lugar de reescribir — pegar mediante APIs, bases de datos compartidas y parches. Al cabo de un año, el sistema se convierte en un monstruo que nadie entiende.

El factor “creatividad”

Los desarrolladores experimentados que quieren probar nuevas tecnologías en producción a menudo se convierten en la fuente de Frankenstein. En lugar de limitar los experimentos a un módulo aislado, introducen código experimental en partes críticas del sistema.

Ejemplos de Frankenstein en proyectos reales

Un ejemplo clásico es el uso de múltiples ORM en una misma aplicación. Algunos módulos usan Hibernate, otros MyBatis, y otros consultas JDBC directas. Las transacciones se vuelven inmanejables, la caché inconsistente, y un nuevo desarrollador no sabe qué enfoque usar para una nueva funcionalidad.

Un segundo ejemplo es la mezcla de estilos arquitectónicos. En un controlador REST API, encuentras llamadas a servicios SOAP, consultas SQL directas, acceso al sistema de archivos y generación de HTML. Una aplicación así es imposible de probar, ampliar o documentar.

Un tercer ejemplo es un stack tecnológico donde Python se usa para el backend, Node.js para un microservicio, C# para un cliente de escritorio y Java para una app Android, mientras toda la lógica de negocio está dispersa entre ellos sin una clara separación de responsabilidades.

// frankenstein — mixed styles and technologies
// callbacks, Promises, and async/await combined

// callbacks
db.query("SELECT * FROM users", function(err, rows) {
  if (err) handleError(err);
  // Promise inside callback
  fetch("/api/data").then(function(data) {
    // async/await inside then
    (async () => {
      const result = await processData(data);
      sendResponse(result);
    })();
  });
});

// clean code — unified async/await style
async function getUserData(userId) {
  const user = await db.query("SELECT * FROM users WHERE id = ?", [userId]);
  const data = await fetch("/api/data/" + userId);
  return await processData(user, data);
}

Frankenstein a nivel de datos

Una misma base de datos se usa simultáneamente como SQL relacional (con normalización) y como NoSQL orientada a documentos (con columnas JSON). Algunas consultas van a través de ORM, otras mediante procedimientos almacenados, otras mediante SQL directo desde el código. El esquema de la BD no está documentado, las migraciones entran en conflicto.

Consecuencias del código Frankenstein

La complejidad de la incorporación es la primera consecuencia. Un nuevo desarrollador debe conocer 5 idiomas, 3 frameworks, 2 estilos arquitectónicos para entender cómo funciona el sistema. La incorporación se alarga de semanas a meses. Según LinkedIn (2023), los proyectos con eclecticismo tecnológico pierden nuevos empleados 2 veces más a menudo.

La impredecibilidad del comportamiento es la segunda consecuencia. Un cambio en el microservicio de Python puede romper inesperadamente el módulo de Java porque comparten una base de datos sin contratos claros. Depurar estos problemas requiere conocimiento simultáneo de todas las tecnologías del stack.

La seguridad es la tercera consecuencia. Cada tecnología del stack requiere su propia configuración de seguridad, sus propios parches, su propio monitoreo. Mantener la seguridad a un nivel aceptable para 5-6 tecnologías heterogéneas es prácticamente imposible. Una de ellas inevitablemente resultará vulnerable.

Deuda técnica de Frankenstein

SonarQube puede medir la deuda técnica, pero no puede medir la “deuda arquitectónica” — la incompatibilidad de componentes. Esta deuda se manifiesta no en advertencias del linter, sino en la imposibilidad de añadir una nueva función sin modificar tres módulos diferentes escritos en tecnologías distintas.

Cómo evitar crear un monstruo

El primer y principal paso es nombrar un arquitecto o tech lead responsable de la integridad del stack tecnológico. Esta persona tiene poder de veto sobre la introducción de nuevas tecnologías sin revisión arquitectónica. No democracia, sino decisión responsable única sobre tecnologías clave.

El segundo paso es implementar el proceso de Architecture Decision Record (ADR). Cualquier decisión arquitectónica significativa (elección de BD, framework, protocolo) se documenta como un texto corto: contexto, alternativas consideradas, decisión tomada, consecuencias. Los ADR se almacenan en el repositorio y están disponibles para todo el equipo.

El tercer paso es establecer el principio de “una tarea — una herramienta”. Para solicitudes HTTP — un cliente. Para ORM — una biblioteca. Para registro — un framework. Las excepciones solo se permiten mediante ADR con justificación. Si el proyecto ya tiene Axios — no agregues fetch, si tiene SLF4J — no escribas mediante System.out.

• Arquitecto con derecho a veto sobre nuevas tecnologías
• Architecture Decision Records para cada elección significativa
• Stack unificado para cada tarea — un cliente HTTP, un ORM
• RFC para cambios importantes con discusión de todo el equipo
• Radar tecnológico para rastrear qué se puede adoptar

Política de tecnologías experimentales

Los experimentos están permitidos, pero en un entorno aislado. Asigna un módulo o servicio que pueda reescribirse con una nueva tecnología sin afectar al resto del sistema. Si el experimento tiene éxito — estandarízalo mediante ADR. Si no — elimínalo sin consecuencias.

Cómo refactorizar un Frankenstein existente

Inventario — el primer paso. Crea un mapa completo del stack tecnológico: qué frameworks, bibliotecas, idiomas, protocolos se usan, en qué módulos y para qué tareas. Verás la magnitud del problema: duplicación de herramientas, tecnologías conflictivas, dependencias no utilizadas.

Estandarización — el segundo paso. Elige una herramienta para cada tarea. Por ejemplo: solo Hibernate para ORM, solo SLF4J + Logback para registro, solo REST para API. Documenta el estándar en ADR. Comienza a reemplazar desde los módulos donde el eclecticismo causa más problemas.

Estrategia Parallel Run — el tercer paso. Las herramientas vieja y nueva funcionan en paralelo hasta que la nueva demuestre su fiabilidad. Por ejemplo, el cliente HTTP viejo y el nuevo funcionan simultáneamente, pero el nuevo solo maneja parte de las solicitudes. Tras un período de estabilización, el viejo se elimina.

// frankenstein — three HTTP approaches in one project
// Module A: OkHttp
OkHttpClient client = new OkHttpClient().newCall(request);

// Module B: RestTemplate (Spring)
restTemplate.getForObject(url, String.class);

// Module C: java.net.HttpURLConnection
HttpURLConnection conn = (HttpURLConnection) new URL(url).openConnection();

// unified approach: RestTemplate for sync, WebClient for reactive
@Autowired
private RestTemplate restTemplate;

public String callApi(String url) {
    return restTemplate.getForObject(url, String.class);
}

El rol del líder técnico en la prevención

Un líder técnico es la principal herramienta para combatir Frankenstein. No un gerente, no un arquitecto en una torre de marfil, sino un desarrollador en ejercicio que escribe código, revisa PR y toma decisiones arquitectónicas. Sin esa persona, el proyecto inevitablemente cae en el eclecticismo tecnológico.

RFC (Request for Comments) es un proceso tomado de las comunidades de código abierto. Antes de introducir cualquier tecnología significativa, el autor escribe un RFC: problema, solución propuesta, alternativas, plan de implementación. El equipo discute, vota, acepta o rechaza. RFC crea transparencia y evita decisiones arquitectónicas “silenciosas”.

El Radar Tecnológico (ThoughtWorks Technology Radar) es una herramienta de categorización: Adopt, Trial, Assess, Hold. El equipo revisa periódicamente el radar y actualiza los estados. Esto ayuda a distinguir lo “moderno” de lo “útil” y evitar la introducción de tecnologías no probadas en código crítico.

El principio de coherencia

La cualidad más importante de la arquitectura es la coherencia (consistency). Incluso una herramienta no tan buena utilizada en todo el proyecto es mejor que la mejor herramienta utilizada solo en un módulo. La coherencia reduce la carga cognitiva, simplifica la incorporación y hace que el código sea predecible.