Audit, Reparatur und Übernahme nach einem anderen Entwickler
Fremden Code verstehen, Grundursachen ermitteln, den kritischen Pfad reparieren und einen sicheren Plan für die Zukunft erstellen.
Was diese Arbeit umfasst
Wenn ein laufendes Projekt fragil, langsam oder verwaist ist, reproduziere ich die Probleme und behebe die Ursachen nach Priorität. Alles neu zu schreiben, ist nur dann eine Option, wenn die Fakten dafür sprechen.
Für wen es passt
- Inhaber eines Systems, das zwar funktioniert, an das man sich aber kaum heranwagt
- Unternehmen, nachdem ein Dienstleister oder Entwickler gegangen ist
- Teams, die einen zweiten Blick auf Architektur und Risiken brauchen
Fragen, die ich vor Projektbeginn beantworte
- Was funktioniert und was nicht?
- Welche Abläufe sind geschäftskritisch?
- Was ist über frühere Entscheidungen und technische Schulden bekannt?
- Welches Budget steht für eine Reparatur statt einer Neuentwicklung bereit?
Wie die Arbeit abläuft
Diagnose
System starten, Struktur prüfen und Fehler reproduzieren.
Priorisieren
Dringende Korrekturen, spätere Arbeit und Tabuzonen voneinander trennen.
Behutsam ändern
Gezielte Korrekturen vornehmen und verbundene Abläufe testen.
Übergeben
Dokumentieren, was sich geändert hat, was offen ist und wie es weitergeht.
Grenzen und Arbeitsregeln
- Neu schreiben nur, wenn es wirklich sicherer und günstiger ist
- Erst Diagnose, dann Budget
- Änderungen an echten Abläufen testen