Frankenstein in programmeren — wat het is, oorzaken en preventie

Wat is Frankenstein in programmeren

Frankenstein (Frankenstein code, Frankenstein pattern) is een antipatroon waarbij een softwaresysteem wordt samengesteld uit delen die niet bedoeld zijn om samen te werken. Net als het monster van Frankenstein kan dergelijke code functioneren, maar het is lelijk, onvoorspelbaar en gevaarlijk bij de kleinste veranderingen.

De term komt uit de literatuur: in de roman Mary Shelley „Frankenstein, of de moderne Prometheus” (1818) creëerde een wetenschapper een levend wezen uit fragmenten van lichamen van verschillende overleden mensen. In programmeren is de analogie treffend — ontwikkelaars nemen stukken van verschillende frameworks, bibliotheken, talen en lijmen ze aan elkaar, met een werkend maar monsterachtig resultaat.

Het verschil tussen Frankenstein en spaghetticode zit in de schaal en aard van het probleem. Spaghetticode is een verwarde structuur binnen één technologiestack. Frankenstein is eclecticisme op architectuurniveau: verschillende technologieën, incompatibele paradigma's, conflicterende benaderingen binnen één systeem.

Frankenstein vs microservices

Microservice architectuur staat het gebruik van verschillende technologieën voor verschillende services toe, maar onder voorwaarde van duidelijke grenzen en gestandaardiseerde communicatieprotocollen. Frankenstein is chaotische vermenging zonder grenzen: REST en GraphQL in één controller, twee ORM's in één module, SQL en NoSQL voor dezelfde entiteit.

Waarom het Frankenstein-syndroom ontstaat

Afwezigheid van een technisch leider of architect is de hoofdoorzaak. Wanneer er in een project niemand verantwoordelijk is voor de integriteit van de architectuur, kiest elke ontwikkelaar instrumenten „voor zichzelf”. De één houdt van Spring, de tweede van Guice, de derde van een eigen DI. Het resultaat is een architecturale mix.

Samenvoeging van projecten is de tweede veelvoorkomende oorzaak. Twee teams ontwikkelden onafhankelijk hun modules met verschillende stacks. Wanneer de modules moeten worden samengevoegd tot één applicatie, worden ze gewoon „aan elkaar gelijmd” met adapters en tussenlagen. Het resultaat is Frankenstein.

Bedrijfsovernames zijn het derde scenario. Bedrijf A koopt bedrijf B en wil diens product integreren in het eigen product. In plaats van herschrijven — lijmen via API, gedeelde databases en workarounds. Binnen een jaar verandert het systeem in een monster dat niemand begrijpt.

De „creativiteitsfactor”

Ervaren ontwikkelaars die nieuwe technologieën in productie willen proberen, worden vaak een bron van Frankenstein. In plaats van experimenten te beperken tot een geïsoleerde module, introduceren ze experimentele code in een kritisch deel van het systeem.

Voorbeelden van Frankenstein in echte projecten

Een klassiek voorbeeld is het gebruik van meerdere ORM's in één applicatie. Sommige modules gebruiken Hibernate, andere MyBatis en weer andere directe JDBC-query's. Transacties worden onbeheersbaar, cache raakt inconsistent en een nieuwe ontwikkelaar weet niet welke aanpak te kiezen voor een nieuwe functie.

Een tweede voorbeeld is het mengen van architecturale stijlen. In een REST API-controller komen SOAP-service-aanroepen, directe SQL-query's, bestandssysteemtoegang en HTML-generatie voor. Zo'n applicatie is onmogelijk te testen, uit te breiden of te documenteren.

Een derde voorbeeld is een technologiestack waarbij Python voor de backend wordt gebruikt, Node.js voor een microservice, C# voor een desktopclient en Java voor een Android-app, terwijl alle bedrijfslogica verspreid is zonder duidelijke verantwoordelijkheidsverdeling.

// frankenstein — gemengde stijlen en technologieën
// callbacks, Promises en async/await gecombineerd

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

// schone code — uniforme async/await-stijl
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 op dataniveau

Eén database wordt tegelijkertijd gebruikt als SQL-relationeel (met normalisatie) en als NoSQL-documentgeoriënteerd (met JSON-kolommen). Een deel van de query's gaat via ORM, een deel via opgeslagen procedures, een deel via directe SQL uit de code. Het databaseschema is niet gedocumenteerd, migraties conflicteren.

Gevolgen van Frankenstein-code

Complexiteit van onboarding is het eerste gevolg. Een nieuwe ontwikkelaar moet 5 talen, 3 frameworks en 2 architecturale stijlen kennen om te begrijpen hoe het systeem werkt. Onboarding duurt in plaats van weken maanden. Volgens LinkedIn (2023) verliezen projecten met technologische eclecticisme 2 keer vaker nieuwe medewerkers.

Onvoorspelbaarheid van gedrag is het tweede gevolg. Een wijziging in een Python-microservice kan onverwacht een Java-module breken omdat ze een gedeelde database gebruiken zonder duidelijke contracten. Het debuggen van dergelijke problemen vereist gelijktijdige kennis van alle technologieën in de stack.

Beveiliging is het derde gevolg. Elke technologie in de stack vereist eigen beveiligingsconfiguratie, eigen patches en eigen monitoring. Het is praktisch onmogelijk om beveiliging op een acceptabel niveau te houden voor 5–6 verschillende technologieën. Eén ervan zal onvermijdelijk kwetsbaar blijken.

Technische schuld van Frankenstein

SonarQube kan technische schuld meten, maar kan „architectuurschuld” niet meten — de incompatibiliteit van componenten. Deze schuld manifesteert zich niet in linterwaarschuwingen, maar in de onmogelijkheid om een nieuwe functie toe te voegen zonder drie verschillende modules te wijzigen die in verschillende technologieën zijn geschreven.

Hoe voorkom je het creëren van een monster

De eerste en belangrijkste stap is het aanstellen van een architect of tech lead die verantwoordelijk is voor de integriteit van de technologiestack. Deze persoon heeft veto over de introductie van nieuwe technologieën zonder architecturale review. Geen democratie, maar een verantwoordelijke eenhoofdige beslissing over sleuteltechnologieën.

De tweede — implementeer het Architecture Decision Record (ADR)-proces. Elke significantere architecturale beslissing (keuze van database, framework, protocol) wordt gedocumenteerd als een korte tekst: context, overwogen alternatieven, genomen beslissing, gevolgen. ADR's worden in de repository opgeslagen en zijn beschikbaar voor het hele team.

De derde — stel het principe „één taak — één instrument” in. Voor HTTP-verzoeken — één client. Voor ORM — één bibliotheek. Voor loggen — één framework. Uitzonderingen zijn alleen toegestaan via ADR met onderbouwing. Als Axios al in het project zit — voeg geen fetch toe, als SLF4J er is — schrijf niet via System.out.

• Architect met vetorecht over nieuwe technologieën
• Architecture Decision Records voor elke belangrijke keuze
• Uniforme stack voor elke taak — één HTTP-client, één ORM
• RFC voor grote wijzigingen met teamdiscussie
• Technologieradar om bij te houden wat geïntroduceerd kan worden

Beleid voor experimentele technologieën

Experimenten zijn toegestaan, maar in een geïsoleerde omgeving. Wijs een module of service aan die herschreven kan worden met nieuwe technologie zonder invloed op de rest van het systeem. Als het experiment slaagt — standaardiseer het via ADR. Zo niet — verwijder het zonder gevolgen.

Hoe bestaande Frankenstein te refactoren

Inventarisatie is de eerste stap. Maak een complete kaart van de technologiestack: welke frameworks, bibliotheken, talen, protocollen worden gebruikt, in welke modules en voor welke taken. Je zult de omvang van het probleem zien: dubbele instrumenten, conflicterende technologieën, ongebruikte afhankelijkheden.

Standaardisatie is de tweede stap. Kies één instrument voor elke taak. Bijvoorbeeld: alleen Hibernate voor ORM, alleen SLF4J + Logback voor loggen, alleen REST voor API. Documenteer de standaard in ADR. Begin met vervangen in modules waar eclecticisme de meeste problemen veroorzaakt.

Parallel Run-strategie is de derde stap. Oude en nieuwe instrumenten werken parallel totdat de nieuwe zijn betrouwbaarheid bewijst. Bijvoorbeeld, de oude HTTP-client en de nieuwe werken gelijktijdig, maar de nieuwe alleen voor een deel van de verzoeken. Na een stabilisatieperiode wordt de oude verwijderd.

// frankenstein — drie HTTP-benaderingen in één 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();

// uniforme benadering: RestTemplate voor sync, WebClient voor reactive
@Autowired
private RestTemplate restTemplate;

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

De rol van de technisch leider bij preventie

De technisch leider is het belangrijkste instrument in de strijd tegen Frankenstein. Geen manager, geen architect in een ivoren toren, maar een praktiserend ontwikkelaar die code schrijft, PR's reviewt en architecturale beslissingen neemt. Zonder zo iemand glijdt een project onvermijdelijk af naar technologisch eclecticisme.

RFC (Request for Comments) is een proces dat is overgenomen uit Open Source-gemeenschappen. Vóór de introductie van een significante technologie schrijft de auteur een RFC: probleem, voorgestelde oplossing, alternatieven, implementatieplan. Het team bespreekt, stemt, accepteert of wijst af. RFC creëert transparantie en voorkomt „stille” architecturale beslissingen.

De technologieradar (Technology Radar van ThoughtWorks) is een instrument voor het categoriseren van technologieën: Adopt, Trial, Assess, Hold. Het team herziet regelmatig de radar en werkt statussen bij. Dit helpt om „modieus” van „nuttig” te onderscheiden en introductie van onbewezen technologieën in kritische code te voorkomen.

Het principe van consistentie

De belangrijkste kwaliteit van architectuur is consistentie. Zelfs een niet-optimaal instrument dat in het hele project wordt gebruikt, is beter dan het beste instrument dat slechts in één module wordt gebruikt. Consistentie vermindert cognitieve belasting, vereenvoudigt onboarding en maakt code voorspelbaar.