Hoe benader je het begrijpen van een grote, niet-gedocumenteerde codebase die je zojuist hebt overgenomen?

Question

Accepted Answer

Wanneer je een niet-gedocumenteerde codebase overneemt, weerstaan de neiging om elk bestand van boven naar beneden te lezen of te refactoren wat er lelijk uitziet. Je begrijpt het nog niet, en vroege refactors op onbegrepen code zijn hoe je storingen creëert. Het doel is om snel een nauwkeurig mentaal model op te bouwen, gebaseerd op echt gedrag in plaats van gissingen.

## Aanpak in de praktijk

- **Voer het eerst lokaal uit.** Het aan de gang krijgen en laten draaien leert je de stack, de dependencies en de setup-pijnpunten voordat je een regel logica leest.
- **Volg één echte gebruikersstroom van begin tot eind.** Kies iets concreets (inloggen, checkout, een rapport) en volg het van ingangspunt tot database en terug. Één stroom diep begrepen is beter dan tien oppervlakkig doorgenomen.
- **Lees het datamodel.** Het schema en de kerndomeinobjecten onthullen wat het systeem werkelijk doet en hoe concepten gerelateerd zijn, vaak eerlijker dan de code.
- **Vind de ingangspunten.** Routes, controllers, message consumers, cron jobs, de main function. Dit zijn de deuren naar het systeem.
- **Gebruik tests en logging om gedrag te bevestigen.** Voeg een logwegel of een breakpoint toe en kijk naar de werkelijkheid in plaats van aan te nemen. Bestaande tests documenteren het beoogde gedrag.
- **Praat met mensen die het kennen.** Dertig minuten met iemand die door de beslissingen heen heeft geleefd, bespaart dagen archeologie. Vraag *waarom*, niet alleen *wat*.
- **Schrijf onderweg een kaart op.** Een voortdurend document van modules, flows en valkuilen verandert je inspanning in iets dat de volgende persoon en je toekomstige zelf kunnen hergebruiken.

## Wat moet je vermijden

Refactor niet voordat je begrijpt. Vertrouw niet op opmerkingen boven gedrag. Probeer niet het hele systeem tegelijk in je hoofd te houden; diepte in de delen die ertoe doen is beter dan oppervlakkige breedte overal.

## Waarom het belangrijk is

De meeste engineeringwerk gebeurt in code die iemand anders heeft geschreven. Een tech lead die snel en veilig een mentaal model van onbekende systemen kan opbouwen, ontgrendelt het hele team, bepaalt het werkbereik nauwkeurig en vermijdt de dure fout van het veranderen van dingen die hij nog niet begrijpt.