Sein an einem Projekt wirklich verlockend wie Sie beschreiben, alten Code zu werfen und neu zu schreiben, aber es ist fast immer ein Fehler (siehe http://en.wikipedia.org/wiki/Second-system_effect. Links am Ende in Bezug auf Neufassungen sind von unschätzbarem Wert, vor allem http://chadfowler.com/2006/12/27/the-big-rewrite).
Ich nehme an, Sie haben keine echte Testsuite, oder es wäre einfacher, Probleme aufzuspüren, und Sie würden wahrscheinlich ein kleineres Projekt haben, da getestete Projekte in der Regel gut durchdacht sind (obwohl nicht immer). Das wird es sehr schwierig machen, es neu zu implementieren, und Sie haben die Gewissheit, dass Sie alle Funktionen repliziert haben und dass alle Abhängigkeiten gut mit dem "neuen und verbesserten" Code funktionieren.
Und wenn Ihre Benutzer fehlerhafte Ergebnisse erhalten, würde ich sagen, dass Sie nicht wirklich wissen, was das Problem ist, also wird eine Neufassung das nicht beheben.
Wenn ich ein Projekt wie dieses übernehme, ist Schritt eins, eine Reihe von Charakterisierungstests zu schreiben, die dokumentieren, wie ich denke, dass das System zur Zeit funktionieren soll. Oft entdecken Sie dabei einen Teil der Funktionalität, der keinen Sinn ergibt oder nicht mit dem Rest des Systems in Einklang steht - das könnte Ihr Problem sein. Sobald wir diese Phase durchschritten haben, können wir anfangen, die hässlichen Teile zu refactorisieren, Ansichten aufzuräumen, Logik an einen Ort zu verschieben, toten Code zu entfernen usw. Aber diese Tests sind wirklich wichtig, wenn Sie das System am Laufen halten wollen.
Schließlich setzen Sie vernünftige Erwartungen für sich. Projekte wie diese werden nicht über Nacht in Unordnung gebracht - Sie können sie auch nicht über Nacht reparieren.
Suchst du jemanden? Haben Sie spezielle Fragen? – Austin
Ich wünschte, ich kann dich einstellen, aber mein Chef sucht einen festen Mitarbeiter für mich. Ich glaube, er erstellt eine Klonmaschine, damit er mich kopieren kann. – fujisan