Wenn ich Code bekomme, den ich noch nicht gesehen habe, um ihn in einen vernünftigen Zustand umzuwandeln, behebe ich normalerweise "kosmetische" Dinge (wie zB StringTokenizers in String#split() umwandeln, vor 1.2 Kollektionen durch neuere Kollektionen ersetzen, Felder% machen co_de%, konvertiert C-artige Arrays in Java-artige Arrays, ...) während ich den Quellcode lese, mit dem ich mich vertraut machen muss.
Gibt es viele Leute, die diese Strategie benutzen (vielleicht ist es eine Art "Best Practice", die ich nicht kenne?) oder wird das als zu gefährlich angesehen, und nicht alten Code zu berühren, wenn es nicht unbedingt notwendig ist? Oder ist es häufiger, den Schritt "kosmetische Reinigung" mit dem invasiveren Schritt "General Refactoring" zu kombinieren?
Was sind die üblichen "tief hängenden Früchte" bei der "kosmetischen Reinigung" (vs. Refactoring mit invasiveren Veränderungen)?
Meiner Meinung nach ist "kosmetische Reinigung" "allgemeines Refactoring". Sie ändern nur den Code, um ihn verständlicher zu machen, ohne sein Verhalten zu ändern.
Ich refaktoriere immer zuerst, indem ich die kleinen Veränderungen zuerst angreife. Je besser Sie den Code schneller lesen können, desto einfacher wird es später, die strukturellen Änderungen vorzunehmen - insbesondere, weil Sie dadurch nach wiederholtem Code usw. suchen können.
In der Regel beginne ich mit Code, der häufig verwendet wird und häufig zuerst geändert werden muss. (Dies hat den größten Einfluss in kürzester Zeit ...) Die Variablenbenennung ist wahrscheinlich die einfachste und sicherste "niedrig hängende Frucht", die zuerst angegriffen wird, gefolgt von Framework-Aktualisierungen (Sammlungsänderungen, aktualisierte Methoden usw.). Sobald dies erledigt ist, ist das Aufbrechen großer Methoden normalerweise mein nächster Schritt, gefolgt von anderen typischen Refactorings.
Hier gibt es keine richtige oder falsche Antwort, da dies weitgehend von den Umständen abhängt.
Wenn der Code aktiv ist, funktioniert undokumentiert ist und keine Testinfrastruktur enthält, würde ich ihn nicht anfassen. Wenn jemand in der Zukunft zurückkommt und neue Funktionen möchte, werde ich versuchen, sie in den bestehenden Code zu integrieren, während ich so wenig wie möglich ändern werde.
Wenn der Code fehlerhafte, problematische, fehlende Features enthält und von einem Programmierer geschrieben wurde, der nicht mehr mit der Firma zusammenarbeitet, würde ich wahrscheinlich das Ganze neu gestalten und neu schreiben. Ich könnte immer noch den Code dieses Programmierers auf eine spezifische Lösung für ein bestimmtes Problem beziehen, aber es würde mir helfen, alles in meinem Kopf und in meiner Quelle neu zu organisieren. In dieser Situation ist das Ganze wahrscheinlich schlecht designed und könnte ein komplettes Nachdenken erfordern.
Für alles dazwischen würde ich den von Ihnen skizzierten Ansatz wählen. Ich würde damit anfangen, alles kosmetisch aufzuräumen, damit ich sehen kann, was vor sich geht. Dann fing ich an, an allem Code zu arbeiten, der am meisten Arbeit erforderte. Ich würde Dokumentation hinzufügen, wenn ich verstehe, wie es funktioniert, damit ich mich daran erinnern kann, was vor sich geht.
Denken Sie daran, dass, wenn Sie den Code jetzt pflegen, er Ihren Standards entsprechen sollte. Wo es nicht ist, sollten Sie sich die Zeit nehmen, es zu Ihren Standards zu bringen - was auch immer das braucht. Dies wird Ihnen eine Menge Zeit, Mühe und Frustration auf der Straße sparen.
Die am wenigsten hängende kosmetische Frucht ist (in Eclipse sowieso) shift-control-F. Automatische Formatierung ist dein Freund.
Zuerst versuche ich, die meisten Dinge vor der Außenwelt zu verstecken. Wenn der Code die meiste Zeit beschissen ist, wusste der Typ, der ihn implementiert hat, nicht viel über das Verstecken von Daten und Ähnliches.
Also mein Rat, zuerst was zu tun:
Verwandle so viele Mitglieder und Methoden wie so privat wie du kannst, ohne das zu brechen Zusammenstellung.
Als zweiten Schritt versuche ich die Schnittstellen zu identifizieren. Ich ersetze die konkreten Klassen durch die Schnittstellen in allen Methoden verwandter Klassen. Auf diese Weise entkoppeln Sie die Klassen ein wenig.
Weiteres Refactoring kann dann sicherer und lokal durchgeführt werden.
Sie können eine Kopie von Refactoring: Verbesserung des Designs von bestehendem Code von Martin Fowler kaufen finden Sie viele Dinge, die Sie während Ihres Refactoring-Vorgangs tun können.
Außerdem können Sie Tools verwenden, die von Ihrer IDE und anderen Codeanalysatoren wie Findbugs oder PMD , um Probleme in Ihrem Code zu erkennen.
Ressourcen:
Zum selben Thema:
Wenn Sie mit "kosmetische Reinigung" beginnen, bekommen Sie einen guten Überblick darüber, wie unordentlich der Code ist, und dies kombiniert mit besserer Lesbarkeit ist ein guter Anfang.
Ich habe immer (ja, richtig ... manchmal gibt es einen Termin, der sich mit mir anlegt), fang mit diesem Ansatz an und es hat mir bisher sehr gut getan.
Sie sind auf dem richtigen Weg. Indem Sie die kleinen Korrekturen machen, werden Sie besser mit dem Code vertraut sein und die größeren Korrekturen werden leichter mit all dem Detritus erledigt sein.
Führen Sie ein Tool wie JDepend aus, CheckStyle oder PMD auf der Quelle. Sie können automatisch viele Änderungen durchführen, die kosmetikbasiert sind, aber auf allgemeinen Refactoring-Regeln basieren.
Ich ändere alten Code nicht, außer ihn mit der IDE neu zu formatieren. Es besteht ein zu großes Risiko, einen Fehler zu verursachen - oder einen Fehler zu entfernen, von dem anderer Code jetzt abhängt ! Oder Sie führen eine Abhängigkeit ein, die nicht existiert, wie zum Beispiel den Heap anstelle des Stacks.
Über die IDE-Neuformatierung hinaus ändere ich nicht den Code, den der Chef nicht aufgefordert hat, mich zu ändern. Wenn etwas ungeheuerlich ist, frage ich den Chef, ob ich Änderungen vornehmen kann und begründen Sie, warum das für das Unternehmen gut ist.
Wenn der Chef mich bittet, einen Fehler im Code zu beheben, mache ich so wenige Änderungen wie möglich. Sagen wir der Bug ist in einer einfachen for-Schleife. Ich würde die Schleife in eine neue Methode umgestalten. Dann würde ich einen Testfall für diese Methode schreiben, um zu zeigen, dass ich den Fehler gefunden habe. Dann würde ich die neue Methode reparieren. Dann würde ich sicherstellen, dass die Testfälle bestanden werden.
Ja, ich bin ein Auftragnehmer. Contracting gibt Ihnen einen anderen Standpunkt. Ich empfehle es.
Es gibt eine Sache, die Sie beachten sollten. Der Code, mit dem Sie beginnen, wurde TESTED und genehmigt, und Ihre Änderungen bedeuten automatisch, dass dieser erneute Test durchgeführt werden muss, da Sie versehentlich ein anderes Verhalten an anderer Stelle verletzt haben.
Außerdem macht jeder Fehler. Jede nicht-triviale Änderung, die Sie vornehmen (das Ändern von StringTokenizer zum Teilen ist nicht eine automatische Funktion in zB Eclipse, also schreiben Sie es selbst) ist eine Gelegenheit für Fehler, sich einzuschleichen. Haben Sie genau das richtige Verhalten? einer bedingten, oder hast du durch einen Fehler einen ! vergessen?
Daher bedeutet Ihre Änderung erneutes Testen. Diese Arbeit kann sehr substanziell sein und die kleinen Veränderungen, die Sie gemacht haben, schwer überwältigen.
Normalerweise mache ich mir keine Mühe, alten Code auf der Suche nach Problemen durchzugehen. Aber wenn ich es lese, wie es scheint, und es mein Gehirn stört, repariere ich es.
Häufige tiefhängende Früchte für mich sind eher das Umbenennen von Klassen, Methoden, Feldern usw. und Schreiben von Verhaltensbeispielen (auch Unit-Tests genannt), wenn ich nicht sicher bin, was eine Klasse durch Inspektion macht - in der Regel den Code lesbarer zu machen, wie ich es lese. Nichts davon würde ich "invasiv" nennen, aber sie sind mehr als nur Kosmetik.
Aus Erfahrung hängt es von zwei Dingen ab: Zeit und Risiko.
Wenn Sie genügend Zeit haben, können Sie viel mehr tun, wenn nicht, dann wird der Umfang dessen, was Sie ändern, entsprechend reduziert. So sehr ich es auch tue, musste ich einige schändliche Hacks erschaffen, weil ich einfach nicht genug Zeit hatte, es richtig zu machen ...
Wenn der Code, an dem Sie arbeiten, viele Abhängigkeiten hat oder für die Anwendung von entscheidender Bedeutung ist, dann nehmen Sie so wenig Änderungen wie möglich vor - Sie wissen nie, was Ihre Korrektur möglicherweise unterbricht ...:)
Es hört sich an, als hätten Sie eine solide Vorstellung davon, wie aussehen sollte , also werde ich nicht sagen, welche Änderungen in welcher Reihenfolge vorgenommen werden müssen, weil das von Person zu Person unterschiedlich ist. Nehmen Sie zunächst kleine lokalisierte Änderungen vor, testen Sie, erweitern Sie den Umfang Ihrer Änderungen, testen Sie. Erweitern. Prüfung. Erweitern. Prüfung. Bis Sie entweder keine Zeit mehr haben oder es keinen Platz mehr für Verbesserungen gibt!
BTW Beim Testen werden Sie wahrscheinlich sehen, wo die Dinge am häufigsten liegen - erstellen Sie Testfälle für sie (JUnit oder was auch immer).
AUSNAHME: Zwei Dinge, die ich immer wieder mache, sind das Neuformatieren (STRG + SHFT + F in Eclipse) und das Kommentieren von Code, der nicht offensichtlich ist. Danach hämmere ich zuerst den offensichtlichsten Nagel ...
Tags und Links java legacy refactoring collections