Organisieren Sie unkommentierten, unsauberen Code?

22

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?

project-management code-quality Salivan
quelle
Dies muss in zwei oder drei Fragen aufgeteilt werden, es ist im Moment viel zu umfassend.
Jon Hopkins
2
Befindet sich dieses Projekt unter Versionskontrolle?
JBRWilkinson
2
Ist der aktuelle Code in Produktion?
JeffO
Ja, Jeff. Es ist eine Produktion, ein Managementprojekt zur Verwaltung eines finanziellen Problems!
Salivan
Tut mir leid, JBR, von so etwas haben sie nichts gehört. Nur ein Coupé von Copy-Paste-Codes auf der gesamten Festplatte zu erstellen, ist ihre Technik, um die Versionskontrolle durchzuführen.
Salivan

Antworten:

36

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 ...)

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 .

Haylem
quelle
Ein großartiger Vorschlag - egal welchen Schaden Sie anrichten, wenn Sie Tests haben, die die Probleme beheben können. Natürlich gehen wir alle davon aus, dass sie bereits Versionskontrolle haben.
JBRWilkinson
@ JBRWilkinson: Guter Punkt eigentlich! In der Tat völlig davon ausgegangen, dass sie es taten.
Haylem
2
Starten Sie zuerst die Versionskontrolle. besser spät als nie.
JeffO
@ Jeff O: Ja, es ist bereits das, was ich zur Antwort hinzugefügt habe.
Haylem
Umschreiben, um nach der Bearbeitung klarer zu werden. Linke Zuschreibungen :)
Haylem
15

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.

Jason Baker
quelle
1
+1 für die Verwendung umfangreicher externer Verweise, die alles aussagen.
Haylem
Leider haben die Leute hier keine Ahnung, wie man Bücher liest. Sie brauchen nur ein Projekt zu entwickeln, das funktioniert. Ich fing an, das von Ihnen erwähnte Buch und auch CODE COMPLETE 2 zu lesen. Lassen Sie mich sagen, dass sie wunderbar geschrieben sind.
Salivan
1
@Salivan - Vielleicht hat sie noch niemand davon überzeugen lassen, dass solche Bücher lesenswert sind. Wenn es nur eine Person gäbe, die mit ihnen zusammenarbeitet, die daran interessiert ist, solche Bücher zu lesen ...
Jason Baker
1
@Salivan - das Wichtigste ist, einen oder zwei schnelle Gewinne zu erzielen. Tun Sie etwas, das sich fast sofort auszahlt. Wie bei der Versionskontrolle, wenn also das nächste Mal jemand sagt "Wie ist das passiert?", Können Sie es nachschlagen. Führen Sie sie dann in einige Vorschläge aus Ihrer Lektüre Ihres WELC-Exemplars ein. Werfen Sie nicht einfach das Buch auf sie.
2
@Salivan Sie können die Bücher für sie lesen und den Inhalt als Rat an sie weitergeben. Du könntest der Teamguru werden.
MarkJ
8

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.

Uberto
quelle
Ich würde auch vorschlagen, Unit-Tests für geeignete Methoden zu schreiben, wenn dies möglich ist. Sie helfen dabei, klar zu definieren, was der Code eigentlich tun soll, was den Refactoring-Prozess erleichtert.
Michael K
2
Es versteht sich von selbst ... Ich halte TDD für eine Voraussetzung für einen guten Code (auch bekannt als der neue).
Uberto
Schreiben von Anfang an ist eine sehr gute Idee. Aber zuerst müssen Sie einige Diagramme der Arbeit haben. Aber was machen Sie, wenn Sie den Code analysieren müssen, um die Relationen zu extrahieren? Außerdem macht es die Größe des Projekts unmöglich, oder wir werden andere Programmierer einstellen.
Salivan
Test Driven Development wird geschätzt!
Salivan
"Aber was werden Sie tun, wenn Sie den Code analysieren müssen, um die Beziehungen zu extrahieren?" -> Wenn dies der Fall ist, bedeutet dies, dass das Projekt weder winzig noch zerbrochen ist. Aka, ich werde anfangen, ein Stück nach dem anderen umzugestalten. Siehe auch die Mikado-Methode. danielbrolund.wordpress.com/2009/03/28/…
Uberto
2

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.

Duros
quelle
Wie viel würde es kosten, es komplett neu zu schreiben oder iterativ zu verbessern? Welcher Ansatz würde am schnellsten zu Ergebnissen führen?
JBRWilkinson
@ JBRWilkinson Es kommt darauf an. Der iterative Ansatz ist gut, wenn Sie über Arbeitscode verfügen.
Duros
1
@duros, für kaputten Code, ja. Dieser Code wird in der Produktion ausgeführt.
2

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

Manoj R
quelle
2
Wenn Sie ein neues Projekt starten und in der Zwischenzeit die alte Version aktualisieren / debuggen (und Sie können dies nicht vermeiden, also träumen Sie nicht davon), wird versucht, auf mehrere sich bewegende Ziele zu schießen.
JeffO
"Greife jeweils einen Teil des Codes an" funktionierte nicht, Manjo. Mit großer Trauer enthält der Code viele Fehler. Es dreht sich immer um etwas anderes. Wir sollten einen Teil des Codes angreifen und zerstören und ihn dann konstruieren. Ich habe dem Manager diesen Gedanken einmal vorgeschlagen, aber die Programmierer müssen keine neuen Codes schreiben.
Salivan
@Salivan ... müssen keine neuen Codes schreiben . Ich bin sicher, das Management sagt das. Aber das erste, was Sie tun müssen, wenn Sie sich in einem Loch befinden, ist, mit dem Graben aufzuhören (machen Sie nicht die gleichen Fehler). Wenn Sie unter diesen Bedingungen mehr schaffen möchten, müssen Sie das Loch weiter ausheben. Der schwierige Teil ist, das Management und die Programmierer dazu zu bringen, die Probleme zu verstehen.
SeraM
1

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.

user281377
quelle
2
Der Vorschlag, den gesamten Code vollständig zu löschen, ist besonders wenig hilfreich. Haben Sie eine konstruktivere Antwort?
JBRWilkinson
LOL. Ich stimme dir voll und ganz zu, ammoQ!
Salivan
JBRWilkinson: Ein Neustart ist höchstwahrscheinlich besser als der Versuch, das Chaos zum Laufen zu bringen und sauber zu machen. Eine Firma, für die ich gearbeitet habe, hat das ausprobiert und Jahr für Jahr viele Ressourcen verschwendet und absolut nichts erreicht.
User281377
@ammoQ, du brauchst den alten Code, um zu sehen, was er tatsächlich getan hat, wenn du etwas falsch gemacht hast.
1
Thorbjörn: Wir sprechen von Code, der nicht funktioniert , oder? Die Analyse von unkommentiertem, unsauberem Code, der nicht das Richtige tut, sagt mir mehr über den mentalen Zustand seiner Schöpfer als über alles andere.
user281377
1

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 .

Martin Wickman
quelle
Vielen Dank, Martin. "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, beginnen Sie, ihnen Shuhari beizubringen."
Salivan
0

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

Jiew Meng
quelle