Kwaliteitsstandaarden

Coderen

Statische analyse draait bij elke commit en in CI: ruff voor stijl en lintfouten, mypy voor typecontrole, bandit voor bekende beveiligingsrisico's in de code zelf. Alle drie moeten schoon zijn voordat iets wordt samengevoegd — een harde CI-poort, geen richtlijn die genegeerd kan worden.

Afhankelijkheden zijn gefixeerd via pip-compile: een .in-bestand met de bewust gekozen directe dependencies wordt gecompileerd tot een volledige, reproduceerbare lock. Het productie-image installeert alleen die lock, nooit de testtooling.

Het uiteindelijke image draait op een gehard, distroless basisimage zonder shell en zonder package manager, als niet-root gebruiker. Dat verandert hoe je debugt, maar sluit een hele klasse aanvallen af.

Achtergrond: Ruff, mypy, OWASP Cheat Sheet Series.

Testen

Unit- en integratietests zijn gescheiden en gemarkeerd, zodat een snelle set — geen database, geen externe services — los kan draaien van de volledige set. Vijf verplichte checks moeten slagen voordat een pull request kan worden samengevoegd, afgedwongen door de branch-bescherming zelf, niet door afspraak.

Testdekking in percentages meet uitvoering, niet verificatie: een regel kan binnen een test draaien zonder dat er iets over het gedrag wordt gecontroleerd. Daarom draait er ook mutation testing: bewust kleine fouten worden in de broncode geïntroduceerd — een vergelijking omgedraaid, een randgeval verschoven — en gecontroleerd of een test faalt. Een mutant die overleeft, betekent dat die coderegel wel wordt uitgevoerd, maar door niets wordt gecontroleerd. Op de kern-beveiligings- en isolatiemodules ligt hier elke nacht een minimumscore op.

Achtergrond: Martin Fowler over de testpiramide, mutmut.

Documenteren

Wijzigingen staan in een changelog volgens Keep a Changelog, met Semantic Versioning voor versienummers. Grote architecturale keuzes staan apart, als kort genummerd besluit met context en consequenties — niet verspreid door commit-messages en gesprekken die niemand meer terugvindt.

Documentatie leeft in de repository zelf, naast de code die ze beschrijft, in plaats van in een los wiki dat kan wegdrijven van de werkelijkheid. Bij elke release wordt gecontroleerd of de documentatie nog klopt met wat de code werkelijk doet — een claim die niet overeenkomt met de code, telt als bug.

Achtergrond: Keep a Changelog, Semantic Versioning, Michael Nygard's voorstel voor Architecture Decision Records.

Lessons learned

Naast de changelog — wat er veranderde — bestaat er een apart document dat reconstrueert waárom: een chronologisch verslag, opgebouwd uit de git-geschiedenis, met verwijzing naar de commits waarop elke conclusie steunt. Recente hoofdstukken zijn uitgebreider dan oude, niet omdat ze belangrijker waren, maar omdat ze zijn opgeschreven toen de gebeurtenis nog vers was — een vertekening die het document over zichzelf ook expliciet benoemt.

Achtergrond: het bredere idee van blameless postmortems, zoals beschreven in Google's SRE-boek.

Data-integriteit: het Clark-Wilson-model

Voor alle persistente data geldt één regel: geen enkele operatie mag data achterlaten in een staat die een integriteitscontrole niet doorstaat. In de praktijk: rijen die door andere data worden aangehaald — documenten, gesprekken, gebruikers, workspaces — worden nooit hard verwijderd. Verwijderen zet een tijdstempel; een permanente purge is een aparte, expliciet geautoriseerde operatie met een voorwaarde: er mogen geen actieve verwijzingen meer bestaan. "Intrekken" en "vernietigen" zijn daarmee nooit dezelfde actie.

Achtergrond: Clark & Wilson, "A Comparison of Commercial and Military Computer Security Policies" (1987).

De twaalf factoren, toegepast waar ze passen

The Twelve-Factor App beschrijft twaalf richtlijnen voor draagbare, schaalbare webapplicaties: configuratie via omgevingsvariabelen, poortbinding zonder externe webserver, snelle opstart en nette afsluiting, logs als event-stream. Een deel volgen we letterlijk: alle geheimen en instellingen komen uit de omgeving, nooit uit code; het proces bindt zelf zijn poort; het draait als PID 1, zodat stop- en herstartsignalen het direct bereiken in plaats van via een tussenlaag.

Een deel volgen we bewust niet volledig, en dat staat ook zo vastgelegd: het proces houdt in-memory state aan in plaats van volledig stateless te zijn, en de databaselaag is synchroon in plaats van async. Dat is een expliciete keuze voor een single-node toepassing voor een klein team, geen vergeten hoofdstuk — inclusief het moment waarop die keuze zou moeten worden herzien.

Achtergrond: The Twelve-Factor App (Adam Wiggins, Heroku, 2011).

Wanneer iets "productierijp" heet

"Productierijp" is geen gevoel maar een lijst van acht meetbare criteria: faalveilig opstarten, autorisatie standaard aan, een geteste hersteloperatie, een reproduceerbare release, en meer. Pas als alle acht groen zijn, mag die claim in de documentatie staan. Zelfs toen dat het geval was, bleef de daadwerkelijke vrijgave nog enkele dagen liggen — het lichten van die poort is bewust een menselijke beslissing, geen automatische afvinklijst.

Achtergrond: het bredere idee van release readiness reviews, eveneens uit Google's SRE-boek.

Richtinggevende artikelen in IT

Sommige artikelen hebben blijvend bepaald hoe software wordt gebouwd. Een kleine, persoonlijke selectie — drie ervan komen hierboven al terug in de praktijk.

A Comparison of Commercial and Military Computer Security Policies

Clark & Wilson, 1987 — legde de basis voor het integriteitsmodel dat hierboven wordt toegepast op alle persistente data. Origineel paper.

MapReduce: Simplified Data Processing on Large Clusters

Dean & Ghemawat, Google, OSDI 2004 — het model waarmee grote hoeveelheden data over duizenden machines verwerkt konden worden zonder dat elke ontwikkelaar zelf distributie, uitval en herstart hoefde te programmeren. Legde de basis voor Hadoop en een hele generatie dataverwerkingssystemen erna. Origineel paper.

Attention Is All You Need

Vaswani et al., Google, NeurIPS 2017 — introduceerde de transformer-architectuur en het attention-mechanisme (query, key, value — waar het Solbyco-logo naar verwijst), en ligt aan de basis van vrijwel elk taalmodel dat sindsdien is gebouwd, inclusief de modellen die LocalChat lokaal draait. Origineel paper.

The Twelve-Factor App

Adam Wiggins, Heroku, 2011 — geen wetenschappelijk paper maar net zo invloedrijk: een compacte set regels voor cloud-native applicaties die jaren later nog steeds de standaardtaal is voor hoe teams over deployment praten. Volledige tekst.

Documenting Architecture Decisions

Michael Nygard, 2011 — het simpele idee dat een architecturale keuze evenveel waard is als de reden erachter, vastgelegd naast de code in plaats van in een vergadering die niemand meer terugvindt. Origineel blogpost.

Vibe coding

Andrej Karpathy, X, 2 februari 2025 — muntte de term in een terloopse tweet: je geeft je "volledig over aan de vibes ... en vergeet dat de code zelfs bestaat." Een jaar later trok hij de grens zelf scherper: vibe coding verhoogt de vloer (snel een eerste versie), agentic engineering verhoogt het plafond (betrouwbaar, onderhoudbaar, controleerbaar) — en dat zijn geen synoniemen voor hetzelfde werk.

Wel: gebruiken voor verkenning, wegwerpprototypes en het eerste ontwerp van een aanpak, waar "het werkt" het enige criterium is; de mens blijft de laatste stap — reviewen vóordat het wordt samengevoegd.

Niet: gegenereerde code mergen die niemand heeft gelezen, of aannemen dat "het draait" hetzelfde is als "het klopt" — precies het onderscheid dat hierboven bij Testen al wordt gemaakt tussen dekking en verificatie.

Achtergrond: Karpathy's oorspronkelijke bericht (2 februari 2025).