Tausende Codezeilen verstehen – aber wie?

Nach 7 Wochen Zwangsurlaub (siehe unten) bin ich wieder back to life: mit einem halbwegs neuen Bein (mit Titaneinlagen und Schlitzschrauben ­čśë ), in einer neuen Stadt mit 100%-er Snowcoverage, in einem neuen Job – nach einem Monat Versp├Ątung.

Das letzte Mal, als ich bei einer Firma den Code verstehen musste, ging es um ASP-Classic. Die Abh├Ąngigkeiten waren ├╝berschaubar, das Debugen ging mit Response.Write-Zeilen ;). Aber wie macht man das heute, wie versteht man den bestehende Code, der in vielen Jahren aus den flei├čigen Fingern der Programmierern herausgeflossen ist? Und das im Web, in einer unglaublich flexiblen E-Commerce-Anwendung…

Die L├Âsung war einfach: mit Unit-Tests ! Ich musste nicht erkl├Ąrt bekommen haben, WAS der Code tut, nur welche Aufrufe zu welchen Ergebnissen f├╝hren. Immer, wenn ich ein Szenario verstanden habe, wurden daf├╝r Tests geschrieben und das Ergebnis besprochen. Der Begriff unit wurde teilweise nat├╝rlich ausgedehnt, aber das hat nichts an der Tatsachen ge├Ąndert, dass am Ende

  1. ich den Code verstanden habe
  2. die meisten analysierten Zeilen durch einen Test abgedeckt wurden
  3. die Diskussionen ├╝ber den Testnamen dazugef├╝hrt haben, dass manch unn├Âtige Zeilen (lese “Szenarien”) entfernt wurden, also der Code besser geworden ist