Wie beeinflussen zu große Controller die Einarbeitungszeit für neue Entwickler in einem Projekt?

Zu große Controller (oft als „Fat Controller“ oder „God Objects“ bezeichnet) sind eines der häufigsten technischen Hindernisse bei der Einarbeitung (Onboarding) neuer Entwickler. Sie verlängern die Zeit, bis ein neuer Mitarbeiter produktiv eingreifen kann, erheblich.

Hier sind die spezifischen Auswirkungen auf die Einarbeitungszeit im Detail:

1. Erhöhte kognitive Belastung (Cognitive Load)

Ein menschliches Gehirn kann nur eine begrenzte Menge an Informationen gleichzeitig verarbeiten. Wenn ein Controller 2.000 Zeilen Code umfasst und 20 verschiedene Aufgaben erledigt, muss ein neuer Entwickler:

• Sich durch hunderte Zeilen Code wühlen, um den relevanten Teil für eine Aufgabe zu finden.
• Die Zusammenhänge zwischen unzusammenhängenden Methoden verstehen, die nur zufällig in derselben Klasse liegen.
• Folge: Der Entwickler ist schneller mental erschöpft und braucht länger, um das „Gesamtbild“ zu erfassen.

2. Schwierigkeit, die Geschäftslogik zu finden

In einer sauberen Architektur dienen Controller nur als „Verkehrspolizisten“ (Routing, Input-Validierung). Wenn sie jedoch zu groß sind, enthalten sie oft die eigentliche Geschäftslogik.

• Ein neuer Entwickler weiß nicht: „Ist diese Logik im Service-Layer, im Model oder im Controller versteckt?“
• Die Suche nach der „Source of Truth“ (dem Ort, an dem eine Entscheidung getroffen wird) wird zur Detektivarbeit.
• Folge: Die Orientierungsphase im Projekt dauert Wochen statt Tage.

3. Angst vor Seiteneffekten (Fragilität)

Große Controller haben oft viele Abhängigkeiten und teilen sich einen internen Zustand oder private Hilfsmethoden.

• Ein neuer Entwickler hat Angst, eine kleine Änderung an Methode A vorzunehmen, weil er nicht absehen kann, ob dies Methode B (die 1.500 Zeilen weiter unten steht) beeinflusst.
• Folge: Der Entwickler arbeitet extrem vorsichtig und langsam oder produziert Fehler, die wiederum Zeit für Bugfixes und Code-Reviews fressen.

4. Erschwerte Testbarkeit

Große Controller sind meist schwer isoliert zu testen, da sie zu viele Abhängigkeiten (Mocks) benötigen.

• Ein neuer Entwickler lernt das System oft über die Unit-Tests kennen. Wenn diese Tests aber 500 Zeilen Setup-Code benötigen, um einen einzigen Controller-Endpunkt zu testen, wirkt das abschreckend und unverständlich.
• Folge: Der Entwickler schreibt selbst keine oder nur schlechte Tests, was die technische Schuld weiter erhöht.

5. Fehlende Vorbildfunktion (Broken Windows Theory)

Die Codebasis ist der Lehrer des neuen Entwicklers.

• Wenn der Controller zeigt: „Hier werfen wir alles rein“, wird der neue Entwickler dieses Muster kopieren (da es der etablierte Standard im Projekt zu sein scheint).
• Folge: Die Einarbeitungszeit wird nicht nur verlängert, sondern der neue Entwickler lernt direkt schlechte Praktiken, was die Qualität des gesamten Projekts langfristig senkt.

6. Ineffektive Code-Reviews

Da die Änderungen in großen Controllern oft unübersichtlich sind, dauern die Code-Reviews länger.

• Der Senior-Entwickler muss viel Zeit investieren, um dem Junior zu erklären, warum eine Änderung an Stelle X im Riesen-Controller problematisch ist.
• Folge: Der Feedback-Zyklus verlangsamt sich, was den Lernprozess des neuen Entwicklers bremst.

Zusammenfassung der Auswirkungen

Fazit: Zu große Controller wirken wie eine „Einstiegshürde“. Sie verwandeln das Onboarding von einem strukturierten Prozess in ein Durchkämpfen durch einen „Code-Dschungel“. Projekte mit kleinen, spezialisierten Klassen (Single Responsibility Principle) ermöglichen es neuen Entwicklern hingegen, isolierte Teile des Systems schnell zu verstehen und erste Erfolge zu feiern.