Best Practice Vorgehensweise bestehenden Code/Programm verschönern

[Fab1]

Hallo Zusammen,

wie ich im Titel bereits versucht habe zu erklären, geht es um das verschönern von Code. Mir liegt ein Programm vor, welches mit der Zeit immer und immer wieder erweitert wurde, mit dem Ziel das es weiterhin läuft. Das heißt es wurde nicht viel Wert auf Kommentare, Übersichtlichkeit, Wiederverwendbarkeit, Erweiterbarkeit o.ä. gelegt.

Nun wurde, bzw. werde ich darauf angesetzt, mir das ganze doch mal anzuschauen und es besser zu machen.

Bisher hab ich nicht viel Erfahrung im mit dem Lesen von fremden Code und würde mich deswegen über ein paar Tipps zur Vorgehensweise freuen. Eventuell gibt es hier ja ein paar Schritte, mit denen man erstmal anfangen sollte.
Beispielsweise erstmal alles kommentieren oder erstmal die wichtigsten Klassen kommentieren usw. Ich denke ihr wisst was ich meine, ansonsten lasst es mich wissen.

Vielen Dank und schöne Grüße

Fabi

 

[SlaterB]

der wichtigste Fehler/ Unschönheit, der mir immer und überall begegnet, ist doppelter Code,
z.B. eine 20zeilige Methode kopiert um in der neuen Variante 2 Zeilen einzufügen statt alternativ ein Parameter, und sei es ein boolean, mit if-Block,

muss man irgendwann den Code ändern, ist alles doppelt zu machen (oder schlimmer: zur Hälfte vergessen),
kommen noch mehr Varianten, werden aus 2 Methoden vielleicht schon 4 usw.

Parameter/ Unterscheidungen sind selber auch nicht unbedenklich, können in Massen schlimm sein,
aber darauf treffe ich persönlich wiederum selten

 

[Gast2]

Eine undankbare Aufgabe...

1) Als allererstes würde ich die Testabdeckung untersuchen... Wenn du irgendetwas änderst solltest du auch garantieren können dass die Änderungen nichts kaputt gemacht haben.

2) Dokumentieren der Architektur, Pakete, Klassen und öffentlichen Methoden ist nie falsch. Ich würde bei der High Level Architektur anfangen und mich dann runter arbeiten.

3) Rein kosmetische Änderungen würde ich gar nicht machen, imho reine Zeitverschwendung.

4) Vor einem Review solltest du dir Standardliteratur zu Clean Code und Refactoring anschauen. Tips dazu: ("Robert C. Martin: Clean Code"; "Steve McConnell: Code Complete", "Martin Fowler: Refactoring")

5) Lass den Rechner Vorarbeit leisten: Benutze Static Code Analyzer wie Checkstyle oder PMT.

6) "Joshua Bloch: Effective Java" hat viele gute Tips um Code zu verbessern. Leider sind viele Dinge nicht ohne größere Designänderungen machenbar, aber einiges wie final Parameter, mutuable/immutable usw ist meist schon recht einfach machbar

 

[turtle]

[EDIT]Wie bereits richtig erwähnt musst du zunächst entsprechende Tests schreiben, damit du sicher bist, das dein neuerer, "schönerer" Code immer noch das tut, was der alte tat!![/EDIT]
Das ist eine undankbare und teilweise aufwendige Aufgabe und häufig hat kein Mensch/Chef dafür Verständnis diesen Aufwand zu bezahlen.

Wenn das nach den Tests durch ist, kannst du beliebig den Code refactoren bis du bei einem Zustand bist, das du (oder deine Teammitglieder) zufrieden sind.

Natürlich gibt es eine Menge an Best-practices, worin sich guter Code auszeichnet und es wurden schon einige erwähnt (DRY-don't-repeat-yourself). Es existiert auch eine Fülle an Büchern, die auch erwähnt wurden, möchte aber noch auf das PDF_Dokument Clean Code hinweisen.

 

[Spacerat]

Also praktischerweise kann man grössere Programmabschnitte möglicherweise ja erst mal in kleinere übersichtlichere Methoden und deren Aufrufe unterteilen (so löst sich SlateB's Sorge um doppelten Code auch relativ schnell in Rauch auf ). Als nächstes schaut man, ob man von den neu entstandenen Methoden einige utilisieren kann, dass wäre genau dann der Fall, wenn sich das von SlaterB angesprochene Problem über X-Klassen und Y-Pakete zieht. Was man dabei, sofern man in einem Team arbeitet, nicht vergessen darf: Jede neu entstandene Methode unabhängig von ihrer Sichtbarkeit gnadenlos dokumentieren.
Wenn dann alles soweit läuft und nun auch viel übersichtlicher ist, kann man sich um die evtl. verloren gegangene (die z.B. dadurch entsteht, wenn man in den neu implementierten Methoden öfters als zuvor neue Instanzen irgendwelcher Objekte zurückgeben muss) oder einer besseren Performance kümmern.