Also die Aussage von DerWissende bezüglich Projekt löschen und neu erstellen halte ich für sehr übertrieben. Das mag nicht ganz ernst gemeint sein, aber das ist ein Punkt, der so natürlich nicht aufrecht zu halten ist.
Es mag Fälle geben, bei denen ein Neuanfang sinnvoll scheint. Das hängt aber vom Zustand des ganzen Projektes ab. Der Wunsch, eine Klasse zu splitten in Zwei Klassen muss kein Zeichen für ein generell schlechten Zustand eines Projektes sein! Zumal so ein Refactoring sehr einfach sein kann. Code duplizieren und dann in der jeweiligen Klasse die unerwünschten Teile löschen. Dann den aufrufenden Code fixen und fertig könnte man schon sein.
Da ist also ein Neuanfang nicht wirklich etwas, das mir in den Sinn kommt. Wenn das ganze Projekt aber totaler Schrott ist und viele Dinge einfach nicht gegeben sein (Also hier kommen Punkte wie: Vernünftige Analyse, Unit Tests, Dokumentation, ...) dann ist ein neuer Anfang evtl vorzuziehen. Also ohne tiefe Analyse der Anforderungen ist keine Änderung an einem Projekt möglich (Man weiss dann ja nicht, was erfüllt sein muss). Ebenso sind keine Änderungen möglich, wenn es keine Unit Tests gibt (Man merkt dann nicht, wenn man bei Änderungen vorne mit dem Hintern etwas einreisst). Aber auch da ist es möglich, die Analyse mit Dokumentation erst einmal durchzuführen um dann zu prüfen, was gegeben ist. Oder Unit Tests lassen sich evtl. noch nachpflegen.
Weiterhin ist eine wichtige Frage, was die Anforderung ist. Wieso wird der Code angepasst und wieso will man da etwas aufsplitten? In der Praxis gibt es halt Zwänge wie Kosten und Zeiten. Wenn eine einfache Änderung gefordert ist und man nur 4 Wochen Zeit hat, etwas abzugeben, dann kann man keine 8 oder 12 Wochen Neuentwicklung fordern. Oder wenn es ein klare Kostenbegrenzung gibt, dann ist die Frage: Will man die Kohle haben und evtl. an unschönem Code herum basteln oder will man den Auftrag ausschlagen (Dann macht es eben jemand anderes und evtl. ist der Kunde dann auch ganz weg).
Hier ist nur wichtig, dass man offen kommuniziert und transparent bleibt. So weist man klar Risiken und Probleme aus. Und evtl. zahlt ein Kunde dann 10 Mal 4 Wochen anstatt 1 mal 10 Wochen + dann noch 9 mal 1 Woche oder so. Aber evtl. ist das so notwendig aus Sicht des Kunden, denn die Zwischenschritte waren alle so extrem wichtig und eine Verzögerung von 6 Wochen hätten ein vielfaches gekostet von dem, was denn nun die verlängerten Entwicklungszyklen gekostet haben.
Also die Welt ist um ein vielfaches komplizierter als es hier im Forum manchmal scheint.