Ich möchte Ihnen einige Fragen zu Dirty Code stellen. Es gibt einige Anfänger, die ein mittleres Projekt programmiert haben. Der Code ist eine sehr große Schlammkugel. Sie sind keine fortgeschrittenen Programmierer. Sie wissen nur, wie man mit der Tastatur umgeht und ein wenig über Java. Sie haben gerade Code mit 12 000 Zeilen in ihrer Hauptklasse geschrieben, doch 6 000 Zeilen gehören zu NetBeans.

Meine Aufgabe ist es, den Code zu analysieren und eine gute Möglichkeit zur Pflege des Codes vorzuschlagen. Meine Idee ist, das Projekt zu verschrotten und ein neues mit OOP-Methodik zu beginnen. Vor kurzem habe ich einige Notizen und Ideen zum Problem von dieser und einigen anderen Websites gesammelt.

Jetzt habe ich folgende Fragen:

1. Sollten wir den Code reparieren und in eine OOP ändern? Wir debuggen es jetzt.
2. Der Code enthält keine Kommentare, keine Dokumentation, keinen bestimmten Programmierstil und so weiter. Das Ändern ist sehr teuer und zeitaufwändig. Was können wir dagegen tun?
3. Wie kann ich ihnen beibringen, alle Regeln zu befolgen (Kommentieren, OOP, gute Codequalität usw.)?
4. Der Code ist fehlerhaft und fehleranfällig. Was können wir tun? Testen? Wir schreiben fast zwei oder drei A4-Papiere zur Korrektur, aber es scheint endlos.

Ich muss sagen, dass ich neu bei ihnen bin. Ich glaube, ich habe auch die Regeln über das zu späte Hinzufügen von Personen zum Projekt gebrochen. Glaubst du, ich muss sie verlassen?

Schritt 0: Backup auf SCM

Denn, wie von JBRWilkinson in den Kommentaren angedeutet, ist die Versionskontrolle Ihre erste Verteidigungslinie gegen (irreversible) Katastrophen.

Erstellen Sie auch Sicherungskopien der Softwarekonfigurationsdetails, Verfahren zum Erstellen von Ergebnissen usw.

Schritt 1: Zuerst testen

Beginnen Sie dann mit dem Schreiben von Tests :

• für was funktioniert,
• und wofür scheitert.

Egal für was Sie sich entscheiden, Sie sind abgesichert. Sie können jetzt entweder:

• Start von Grund auf neu und neu zu schreiben ,
• oder beheben Sie es.

Mein Rat wäre, die allgemeine Architektur von vorne zu beginnen , aber die Teile, die Checkpoints validieren , aus dem Chaos herauszuholen und diese nach Belieben umzugestalten.

Schritt 2: Überprüfen und Überwachen

Richten Sie ein Continuous Integration- System ein (als Ergänzung zu Schritt 0 und Schritt 1 ) UND ein Continuous Inspection- System (als Vorbereitung auf Schritt 4 ).

Schritt 3: Stellen Sie sich auf die Schultern der Riesen

(wie du immer solltest ...)

• Refactoring zu Patterns
• Refactoring: Verbessern Sie das Design des vorhandenen Codes .
• Effektiv mit Legacy-Code arbeiten (wie von Jason Baker empfohlen )
• Refactoring

Schritt 4: Reinigen

Das ist selbstverständlich, aber anstatt den Code selbst zu überfliegen, können Sie einfach Linters / Static Analyzer und andere Tools auf der defekten Codebasis ausführen, um Fehler im Design und in der Implementierung zu finden.

Dann möchten Sie vielleicht auch einen Code-Formatierer ausführen, der Ihnen schon beim Housekeeping hilft.

Schritt 5: Überprüfen

Es ist einfach, kleine Bugs einzuführen, indem man Dinge umgestaltet oder aufräumt. Es ist nur eine falsche Auswahl und ein schneller Tastendruck erforderlich, und Sie können etwas ziemlich Wichtiges löschen, ohne es zuerst zu merken. Und manchmal tritt der Effekt erst Monate später auf. Natürlich helfen Ihnen die obigen Schritte, dies zu vermeiden (insbesondere durch die Implementierung eines starken Testgeschirrs), aber Sie wissen nie, was passieren kann und wird. Stellen Sie also sicher, dass Ihre Refactorings von mindestens einem anderen dedizierten Augapfelpaar (und vorzugsweise von mehr als diesem) überprüft werden.

Schritt 6: Zukunftssicherer Entwicklungsprozess

Nehmen Sie all das oben Genannte und machen Sie es zu einem inhärenten Bestandteil Ihres üblichen Entwicklungsprozesses, falls dies nicht bereits der Fall ist. Lassen Sie dies auf Ihrer Uhr nicht noch einmal geschehen, und arbeiten Sie mit Ihrem Team zusammen, um Schutzmaßnahmen in Ihrem Prozess zu implementieren und dies (sofern dies überhaupt möglich ist) in Ihren Richtlinien durchzusetzen. Machen Sie die Erstellung von Clean Code zu einer Priorität.

Aber wirklich testen . Viel .

Persönlich würde ich dieses Projekt erst starten, wenn ich eine Kopie von Working Effectively with Legacy Code zur Hand habe. Im Ernst, es wurde für genau diese Art von Dingen geschrieben. Es steckt voller Strategien für den Umgang mit kniffligem Code und geht viel detaillierter vor, als ich Ihnen hier geben kann.

Ich war schon mehrere Male dort. Meine Regel lautet: Wenn die Software nicht trivial ist (mehr als 1 Woche Arbeit für die Ressource, die Sie haben) und sie funktioniert, behalten Sie sie und fahren Sie mit inkrementellem Refactoring fort.

Wenn die Software nicht wirklich funktioniert (sehr viele Fehler, unklare Anforderungen usw.), ist es besser, sie von Grund auf neu zu schreiben. Das gleiche, wenn es ziemlich klein ist.

Der Punkt beim Refactoring (wie in Fowlers Buch und Kerievskys http://www.industriallogic.com/xp/refactoring/ ) ist, dass es das System am Laufen hält. Vielleicht dauert das Refactoring das Doppelte, aber die Risiken sind Null.

Das Umschreiben von Grund auf kann viele Risiken mit sich bringen, vom Missverständnis der Anforderungen bis zur falschen Implementierung (schließlich wird der größte Teil des Teams derselbe sein).

Ich habe tatsächlich gesehen, dass eine komplexe Prozedur zweimal von Grund auf neu geschrieben wurde und immer noch nicht wie erwartet funktioniert.

Ich würde es komplett neu schreiben. Manchmal ist es unmöglich, einen solchen Code zu reparieren. Eine andere Möglichkeit ist, es zum Laufen zu bringen, ohne neue Funktionen hinzuzufügen. Wenn Sie dem Team beibringen möchten, guten Code zu schreiben (gut entworfen, dokumentiert, mit Tests), lassen Sie es den Code reparieren, den Sie jetzt haben. Lassen Sie alle Fehler beheben / den Code anderer Entwickler überprüfen, nicht ihren / seinen Teil. Nach einigen Versuchen werden sie verstehen, dass es fast unmöglich ist, solche Codes zu überprüfen / zu reparieren.

Das Hinzufügen von Personen zu späten Projekten hilft sehr selten. Normalerweise bricht es Fristen. Sie sollten alles tun, um das Projekt erfolgreich abzuschließen, und dann darüber nachdenken, das Projekt zu verlassen.

Mein Rat wird sein, nicht den gesamten Code zu verschrotten. Dies ist das alltägliche Problem, dem sich jedes Entwicklungsteam gegenübersieht. Greife jeweils einen Teil des Codes an. Reparieren, säubern, dokumentieren. Und dann weiter zum anderen Teil. Hauptsache, Sie haben immer einen Code zur Hand. Wenn Sie den gesamten Code von Grund auf neu schreiben, wird die bisher aufgewendete Zeit in Anspruch genommen, und es gibt keine Garantie dafür, dass der Code besser als der aktuelle ist.
Aber auch die Leute sollten es vermeiden, den Code auf diese Weise zu schreiben. Verbringen Sie mehr Zeit mit Code-Überprüfungen. Passen Sie sich an einen einheitlichen Codierungsstil an. Besprechen Sie zuerst das Design und schreiben Sie dann den Code. Solche einfachen Dinge werden große Veränderungen bewirken.

Netter Blog, der erklärt, warum Netscape locker ist

Wenn es funktioniert, überarbeiten Sie es. Es gibt Tools, die Ihnen dabei helfen. Wenn es nicht funktioniert, verwenden Sie den Befehl zur Verbesserung des magischen Codes, z deltree. rm -rfunter Linux.

Sollten wir den Code reparieren und in eine OOP ändern? Wir debuggen es jetzt. [... enthält Fehler, keine Dokumentation ...]

Ich war dort, Sie haben mein Mitgefühl. Ich habe sogar einen Artikel darüber geschrieben, der Ihnen helfen könnte, eine Perspektive zu bekommen. Aber kurz gesagt:

Wenn der Code viele Duplikate enthält , sollten Sie ihn umschreiben. Wenn es keine erkennbare Struktur gibt (keine klaren Schnittstellen, Spaghetti), schlägt das Refactoring fehl und Sie sollten es wahrscheinlich neu schreiben.

Wie kann ich ihnen beibringen, alle Regeln zu befolgen?

Beginnen Sie damit, zu erklären, warum sie das tun möchten, indem Sie ihnen zeigen, was sie persönlich davon profitieren können. Wenn sie damit einverstanden sind und bereit sind zu lernen, fangen Sie an, ihnen Shuhari beizubringen .

Mein Vorschlag ist eine Kombination der Antworten von @ duros & @Manoj R.

Fangen Sie von vorne an und denken Sie daran, dass Sie dieses Mal guten Code / OOP / commented / etc erstellen, indem Sie Ihren alten Code kopieren und einfügen. Wenn Sie auf die schlechten Teile Ihres alten Codes stoßen, schreiben Sie sie um bzw. überarbeiten Sie sie.

Wenn Ihre Entwickler nicht gut geschult sind, ist es meiner Meinung nach gut, sie für Kurse zu schicken. Es ist wichtig für die regelmäßige Umschulung in der sich schnell verändernden IT-Branche