Was ist Code Refactoring? Wie Refactoring technische Schulden löst

Was ist Code Refactoring? Wie Refactoring technische Schulden löst

  • ITOps & DevOps
6 Minuten Lesezeit Aktualisiert Dec 16, 2024

Auf einen Blick: Code-Refactoring verbessert die Lesbarkeit und Wartbarkeit des Codes, ohne dessen Funktionalität zu verändern, wodurch technische Belastungen behoben werden. Es verwandelt "schmutzigen Code" in sauberen Code, was die zukünftige Softwareentwicklung erleichtert.

  • Refactoring verbessert das Verständnis und vereinfacht die Code-Wartung.
  • Regelmäßiges Refactoring hilft, technische Schulden zu vermeiden und steigert die Softwarequalität.

Wir alle kennen das schon: Es ist Zeit, für die nächste Version noch eine letzte Funktion in das Programm einzubauen, aber du hast nicht die Zeit, sie genau richtig zu gestalten – organisiert, gut strukturiert und mit dem Rest des Codes abzustimmen. Stattdessen musst du die Funktionalität auf eine etwas willkürliche Weise hinzufügen, nur um sie fertigzustellen, also tust du es. Zum Glück läuft die Veröffentlichung gut, die Funktion wird reibungslos hinzugefügt und es geht zum nächsten Sprint. Aber was passiert mit dem Code, der nicht der sauberste, klarste oder beste ist, der er sein kann? Wir haben in früheren Artikeln über technische Schulden gesprochen – die Idee, dass bestimmte Arbeiten während der Softwareentwicklung verzögert werden, um pünktlich geliefert zu werden. Eine solche kurzfristige Lösung funktioniert vorerst, ist aber langfristig nicht die beste für die Software. Diese Arbeit wird dann zu "Schulden", weil sie irgendwann bearbeitet werden muss. In diesem Artikel betrachten wir Code-Refactoring als Möglichkeit, technische Schulden zu reduzieren.

Bedeutung von Code-Refaktorisierung

Code-Refaktorierung ist definiert als der Prozess der Restrukturierung von Computercode, ohne dessen externes Verhalten und seine Funktionalität zu verändern oder zu erweitern. Es gibt viele Möglichkeiten, Refactoring anzugehen, aber meist besteht es darin, eine Reihe standardisierter, grundlegender Aktionen anzuwenden, die manchmal als Mikro-Refaktorierungen bekannt sind. Die Änderungen im bestehenden Quellcode bewahren das Verhalten und die Funktionalität der Software, da die Änderungen so winzig sind, dass sie wahrscheinlich keine neuen Fehler verursachen oder einführen.

Die Bedeutung der Code-Refaktorisierung

Anfangs mag sein Zweck etwas überflüssig erscheinen – klar, Code-Refaktorierung verbessert die nicht-funktionalen Eigenschaften der Software, was schön ist, aber was bringt das, wenn es der Gesamtfunktionalität nicht hilft? Experten sagen , dass das Ziel des Code-Refaktorings darin besteht, schmutzigen Code in sauberen Code zu verwandeln, was die gesamte technische Schuld eines Projekts reduziert. Schmutziger Code ist ein informeller Begriff, der sich auf jeden Code bezieht, der schwer zu warten und zu aktualisieren ist und noch schwerer zu verstehen und zu übersetzen. Schmutziger Code ist typischerweise das Ergebnis von Fristen, die während der Entwicklung auftreten – die Notwendigkeit, Funktionen nach Bedarf hinzuzufügen oder zu aktualisieren, auch wenn sein Backend-Erscheinungsbild nicht so ist, wie es sein könnte oder sollte. Man findet schmutzigen Code oft sozusagen an seinem Code-Geruch. Das ist die Idee hinter technischer Schulden: Wenn Code so sauber wie möglich ist, ist es viel einfacher, ihn in späteren Iterationen zu ändern und zu verbessern – damit dein zukünftiges Ich und andere zukünftige Programmierer, die mit dem Code arbeiten, seine Organisation zu schätzen wissen. Wenn schmutziger Code nicht beseitigt wird, kann er sich eskalieren und zukünftige Verbesserungen verlangsamen, weil Entwickler mehr Zeit investieren müssen, den Code zu verstehen und zu verfolgen, bevor sie ihn ändern können. Einige Arten von schmutzigem Code sind:

  • Codes, Methoden oder Klassen, die so vergrößert sind, dass sie zu unhandlich sind, um sie leicht zu manipulieren
  • Die unvollständige oder falsche Anwendung objektorientierter Programmierprinzipien
  • Überflüssige Kopplung
  • Bereiche im Code, die wiederholte Codeänderungen in mehreren Bereichen erfordern, damit die gewünschten Änderungen angemessen funktionieren
  • Jeglicher Code, der unnötig ist, und dessen Entfernung der Gesamtfunktionalität nicht schadet

Sauberer Code hingegen ist viel leichter zu lesen, zu verstehen und zu warten, was die zukünftige Softwareentwicklung erleichtert und die Wahrscheinlichkeit eines qualitativ hochwertigen Produkts in kürzerer Zeit erhöht.

Wann man refaktorisieren sollte

Den richtigen Zeitpunkt zum Refactoring zu kennen, ist nicht allzu schwierig. Wenn du der Entwickler bist, weißt du bereits, wo du in deinem Code Abstriche gemacht hast, um die benötigte Funktionalität zu erstellen. Wenn du Teil eines Teams bist, das ein Projekt teilt, kann es schwieriger sein, Refactoring zu priorisieren, daher hier ein paar Tipps:

  • Refaktorisieren gemäß der Regel der 3:
    • Beim ersten Mal machst du etwas, mach es einfach, auch wenn es mit schmutzigem Code ist, damit die Software nach Bedarf funktioniert.
    • Beim zweiten Mal, wenn du eine ähnliche Änderung machst, kannst du es auf dieselbe Weise wiederholen – du kennst es etwas besser, also bist du vielleicht schneller, aber der Code ist trotzdem nicht perfekt sauber.
    • Wenn du diese Veränderung zum dritten Mal bemerkst, fang mit dem Refaktorieren an.
  • Refaktorisieren Sie während der Code-Überprüfung. Dies ist die letzte Gelegenheit, Code zu bereinigen, bevor er live geht. Versuchen Sie eine Zwei-Personen-Überprüfung, damit Sie schnelle, leicht zugängliche Früchte beheben und dann besser einschätzen können, welche schwierigen Codeänderungsbereiche den Aufwand.
  • Refaktorieren Sie in regelmäßigen Intervallen. Das muss nicht bedeuten, einen ganzen Tag dafür zu widmen, sondern es in Ihre Routine einzubauen – also die letzte Stunde eines Arbeitstages mit Refactoring zu verbringen. (Bonus: Proaktives Refactoring bedeutet, dass Ihr Manager und Ihr Team keine zusätzliche Zeit dafür einplanen müssen.)

Einige Refactoring-Puristen behaupten , dass Refactoring nicht stattfinden sollte, während man Fehler behebt, da der Zweck des Refaktorings nicht darin besteht, die Funktionalität zu verbessern. Aber saubererer Code bedeutet von Natur aus weniger Bugs, da Bugs oft das Ergebnis von schmutzigem Code sind. Indem du Code bereinigst – sei es durch die Widmung von Refactoring-Sitzungen oder bei der Behebung von Fehlern – minderst du Bugs, bevor sie zu Problemen werden.

Möglichkeiten der Refaktorisierung von Code

Es gibt mehrere Möglichkeiten, Code zu refaktorisieren, aber der beste Ansatz ist, Schritt für Schritt zu gehen und nach jeder Änderung zu testen. Testen stellt sicher, dass die Schlüsselfunktion erhalten bleibt, aber der Code vorhersehbar und sicher verbessert wird – sodass während der Restrukturierung des Codes keine Fehler auftreten. Refactoring war früher ein manueller Prozess, aber neue Refactoring-Tools für gängige Sprachen ermöglichen es, den Prozess etwas zu beschleunigen. Dennoch kann es hilfreich sein zu verstehen, was das Tool tatsächlich macht, und wenn Sie eine weniger gebräuchliche Sprache verwenden, gibt es möglicherweise keine guten Refactoring-Tools. Welche Techniken Sie anwenden sollten, hängt oft von den Problemen in Ihrem Code ab. Hier sind einige gängige Refactoring-Techniken:

  • Korrektur Ihrer Schreibmethoden, um Duplikater zu vereinfachen, Duplikater zu vermeiden und zukünftige Änderungen im Code deutlich zu erleichtern.
  • Vereinfachung bedingter Ausdrücke, die mit der Zeit unnötig komplex werden, sowie Methodenaufrufe, damit sie leichter verständlich sind, verbessert Schnittstellen für Klasseninteraktion.
  • Das Verschieben von Funktionen zwischen Objekten, um die Funktionalität besser zwischen den Klassen zu verteilen. Dies kann das sichere Verschieben von Funktionalität, das Erstellen neuer Klassen und das Ausblenden von Implementierungsdetails umfassen.
  • Datenorganisation zur Verbesserung der Handhabung und Klassenverknüpfungen, sodass die Klassen recycelbar und portabel sind.
  • Verbesserung der Verallgemeinerung.

Code-Refactoring-Checkliste

Was ist ein guter Stopppunkt für sauberen Code? Diese Checkliste kann Ihnen helfen zu bestimmen, wann Ihr Code sauber ist:

  • Für andere Programmierer ist das offensichtlich. Das kann so einfach sein wie klarere Strukturen für Benennung, Klassen und Methoden zu erstellen oder ausgefeiltere Algorithmen zu verbessern.
  • Es enthält keine Duplikationen. Die Wahrscheinlichkeit menschlicher Fehler steigt jedes Mal, wenn man Änderungen doppelt machen muss.
  • Es enthält minimale bewegliche Teile, wie die Anzahl der Klassen. Weniger zu merken bedeutet weniger Wartung und weniger Aufräumen.
  • Er besteht alle Tests. Code ist schmutzig, selbst wenn der Großteil davon die Tests besteht.
  • Sie ist leichter zu pflegen. Sie werden weniger Zeit für zukünftige Verbesserungen aufwenden.

Die Vorteile des Refaktorierens

Der Hauptvorteil von Refactoring besteht darin, schmutzigen Code zu bereinigen, um technische Schulden zu reduzieren. Sauberer Code ist leichter zu lesen – sowohl für den ursprünglichen Entwickler als auch für andere Entwickler, die später daran arbeiten könnten, damit er leichter zu warten und Features hinzuzufügen ist. Weniger komplizierter Code kann auch zu einer verbesserten Quellcode-Wartung führen, sodass die interne Architektur ausdrucksstärker ist. Sauberer Code bedeutet auch, dass Designelemente und Codemodule wiederverwendet werden können – wenn Code gut funktioniert und sauber ist, kann er zur Grundlage für Code anderswo werden. Refactoring kann Entwicklern auch helfen, Code und Designentscheidungen besser zu verstehen. Sowohl Anfänger als auch fortgeschrittene Programmierer profitieren davon, zu sehen, wie andere im Inneren gearbeitet und den Code aufgebaut haben, während sich die Softwarefunktionalität erweitert und verändert hat. Dies kann das Gefühl kollektiver Eigenverantwortung fördern – dass ein Entwickler nicht den Code besitzt, sondern das gesamte Team dafür verantwortlich ist. Das Refactoring – das Ändern kleiner Codeabschnitte ohne Frontend-Zweck – mag im Vergleich zu Aufgaben mit höherer Priorität unwichtig erscheinen. Doch die kumulative Wirkung solcher Veränderungen ist erheblich und kann zu einem besser funktionierenden Team und einem besser funktionierenden Programmierungsansatz führen.

Diese Beiträge sind meine eigenen und spiegeln nicht unbedingt die Position, Strategien oder Meinung von BMC wider.

Mehr aus ITOps & DevOps

Abonnieren Sie The Brief

Mit der Registrierung für dieses Angebot bestätigen Sie, dass Sie die Datenschutzrichtlinie von BMC gelesen und zugestimmt haben.

Danke

Sie haben The Brief abonniert
Das Briefing umfasst die Mainframe- und Enterprise-Orchestrierung – BMC AMI und Control-M – sowie die Analystenforschung, Kundeneinsätze und Events in beiden Bereichen.