Hvordan går du til værks med at forstå en stor, udokumenteret codebase, du lige har arvet?

Question

Accepted Answer

Når du arver en udokumenteret codebase, skal du modstå fristelsen til at læse hver fil fra top til bund eller refaktorere det, der ser grimt ud. Du forstår det ikke endnu, og tidlige refaktoreringer af misforståede kode er sådan, du skaber driftsforstyrrelser. Målet er at bygge en nøjagtig mentalt model hurtigt baseret på faktisk adfærd snarere end gæt.

## En praktisk tilgang

- **Kør det lokalt først.** At få det til at bygge og køre lærer dig stacken, afhængighederne og setup-smertepunkterne, før du læser en linje logik.
- **Spor én ægte brugerflow end-to-end.** Vælg noget konkret (login, checkout, en rapport) og følg det fra indgangspunkt til database og tilbage. Én flow forstået grundigt slår ti overfladisk gennemskuede.
- **Læs datamodellen.** Skemaet og kerneobjekterne afslører hvad systemet faktisk gør og hvordan koncepter er relateret, ofte mere ærligt end koden.
- **Find indgangspunkterne.** Routes, controllers, message consumers, cron jobs, main-funktionen. Det er dørene ind i systemet.
- **Brug tests og logging til at bekræfte adfærd.** Tilføj en log-linje eller et breakpoint og se virkeligheden i stedet for at antage. Eksisterende tests dokumenterer tilsigtet adfærd.
- **Tal med mennesker, der kender det.** Tredive minutter med nogen, der har levet gennem beslutningerne, sparer dage med arkæologi. Spørg *hvorfor*, ikke bare *hvad*.
- **Skriv et kort op, mens du går.** Et løbende dokument med moduler, flows og gotchas gør din indsats til noget, næste person og dit fremtidigt selv kan genbruge.

## Hvad du skal undgå

Refaktorér ikke, før du forstår. Stol ikke på kommentarer frem for adfærd. Prøv ikke at holde hele systemet i dit hoved på én gang; dybde på de dele, der betyder noget, slår overfladisk bredde overalt.

## Hvorfor det betyder noget

Det meste ingeniørarbejde sker i kode, som nogen anden skrev. En tech lead, der hurtigt og sikkert kan bygge en mentalt model af ukendte systemer, frigivet hele teamet, fastsætter arbejde præcist og undgår den dyre fejl at ændre ting, de endnu ikke forstår.