Is "clean code" altijd de tijd waard, of is "goed genoeg" soms prima?

Question

Accepted Answer

**Het hangt af van de levensduur van de code en de impact bij fouten.** Clean code loont zich enorm voor code die langere tijd bestaat en verandert; "goed genoeg" is de juiste keuze voor wegwerp-, prototype-, of zelden aangerakte code. Het vaardigheid is het matchen van je investering aan de situatie — zowel slordigheid als overkill vermijden.

## Het principe: pas inspanning aan aan de levensduur van de code

Codekwaliteit is een **investering**, en zoals elke investering hangt het rendement af van tijd en blootstelling. Twee vragen om jezelf te stellen:

- **Hoe lang zal deze code leven?** Code die jaren lang gelezen en gewijzigd wordt verdient helderheid; een eenmalig script niet.
- **Wat is de impact bij fouten?** Een kernmodule die door veel mensen wordt aangepast en kritieke paden ondersteunt verdient zorg; een geïsoleerd hoekje dat zelden verandert niet.

## Wanneer clean code duidelijk wint

- Code die **vaak verandert** — helderheid wordt terugbetaald elke keer dat iemand het leest of aanpast.
- **Gedeelde, centrale, of langlevende** code — de kosten van verwarring vermenigvuldigen zich over mensen en tijd.
- Alles waar een **bug duur is** — betalingen, authenticatie, data-integriteit.

## Wanneer "goed genoeg" de juiste keuze is

- **Wegwerpcode** — spikes, experimenten, eenmalige migraties, een script dat je morgen verwijdert.
- **Prototypes** bedoeld om een idee te valideren, niet om te overleven.
- **Zelden aangeraakt, laag-risico** code waar poetsen weinig oplevert.

## De twee foutmodi

| Fout | Ziet eruit als | Kosten |
|---|---|---|
| **Slordigheid** | rommel in code die zal blijven bestaan | trage toekomstige wijzigingen, bugs, erosie |
| **Overkill** | over-engineering code die niet belangrijk zal zijn | verspilde tijd, voortijdige abstractie |

Beiden zijn echte verspilling. "Goed genoeg" is een *doelbewuste, contextuele* keuze — niet een excuus voor slorddigheid, en niet een vergunning om voor altijd te blijven poetsen.

## Waarom het belangrijk is

Deze vraag scheidt ingenieurs die kwaliteit **dogmatisch** toepassen van degenen die het **economisch** toepassen. Clean code als religie behandelen verspilt moeite op wegwerpcode; het als optioneel behandelen rot de systemen waarop je vertrouwt. Senior oordeel is weten *welke soort code je vasthoudt* en dienovereenkomstig investeren — en in staat zijn dat afweging uit te leggen is precies het soort pragmatisch denken dat teams willen zien.

Fout	Ziet eruit als	Kosten
Slordigheid	rommel in code die zal blijven bestaan	trage toekomstige wijzigingen, bugs, erosie
Overkill	over-engineering code die niet belangrijk zal zijn	verspilde tijd, voortijdige abstractie