Es gibt nicht die einzig glücklichmachende Methode, aber man kann es wohl einmal in seine eigene Psychologie-Aspekte kategorisieren und einmal, wenn du tatsächlich Änderungen am Code machen musst
1. Freuen, dass derjenige keinen Scala-Code benutzt hat
2. Nicht versuchen, alles gleich gut verstehen zu wollen, sondern den Fokus auf den Bereich (Klasse/Methode) legen, die man untersuchen möchte, sofern man diese schon gefunden hat. Vieles hängt natürlich davon ab, wie gut derjenige vorher programmiert hat und kohärent alles abstrahiert hat, d.h. ob Klassen wirklich in sich stimmig sind und nicht zu viel mit anderen kommunizieren. => Versuchen auf einen Teil-Bereich zu fokussieren und alles andere erst einmal ausblenden und darauf vertrauen, dass die Klassen auch wirklich das machen, was sie sollen.
Eventuell:
3. Nicht dauernd über den schlechten Stil/Coding/API-Design Fehler fluchen, es ändert nichts. Einige "Java"-Programmierer haben eher einen C-Stil, andere haben wiederum einen guten OO-Stil, jedoch ändert es nichts, wenn es 100 Klassen gibt, die alle öffentliche Felder haben und dazu noch statisch sind und alle miteinander fröhlich auf direkte Felder zugreifen und womöglich verändern. Ist da zu viel Spaghetti-Code muss man entscheiden, ob es wirklich Sinn macht, oder nicht.
Falls du Änderungen machen willst:
4. Eventuell Test-Cases um den Code bauen. M.Feathers schreibt sinngemäß: jeglicher Code, der nicht in Test-Cases ist, ist automatisch legacy code.
Ansonsten, wenn du öfters mit legacy-code zu tun hast, empfiehlt sich das Buch: "Working Effectively with Legacy Code" von M. Feathers.
