Ultimativer Leitfaden für sauberen Code mit über 30 Java-Refactoring-Beispielen

Clean Code ist ein Schlüssel zu einem besseren, leistungsfähigeren und effizienteren Softwaresystem. Für fast alle Softwareprodukte, mit Ausnahme von sehr kleinen, wird es viel Code geben, und einige von ihnen werden tatsächlich schlechter Code sein. Im Laufe der Zeit werden sich Entwicklerteams ändern, Technologien werden sich ändern, Ansichten zu bestimmten Mustern werden sich ändern und am Ende des Tages wird manches Code schlecht sein. Es gibt also keine Möglichkeit zu garantieren, dass der Quellcode eines Softwareprodukts nur aus sauberem Code besteht. Aber es gibt einige goldene Regeln, die erfahrene Entwickler beim Codieren immer im Hinterkopf behalten sollten. In diesem Blog werde ich einige wichtige Gerüche und Heuristiken des Refactorings mit Java-Beispielen durchgehen.

Benennung

1. Verwenden Sie Namen, die die Absicht offenbaren: Der Name einer Klasse, Funktion oder Variable sollte Ihnen sagen, worum es geht
2. Fehlinformationen vermeiden: Die Namensgebung sollte nicht zu falschen Informationen führen. Eine Variable sollte nicht incomeList heißen , es sei denn, es handelt sich um eine Liste im Sinne der Informatik
3. Keine Präfixe erforderlich: zB Sie müssen Eingabeparameter nicht mit dem Präfix p* benennen
4. Vermeiden Sie mentales Mapping: Verlassen Sie sich nicht darauf, die Benutzer werden die Benennung wie Sie assoziieren. zB Variable r ist nicht immer URL für alle
5. Klassennamen sollten Nomen sein, Funktionsnamen sollten Verben sein
6. Wählen Sie ein Wort für das Konzept: Wenn Sie das Wort „ Erstellen“ für eine Aktion verwendet haben, verwenden Sie das Wort „ Erzeugen“ nicht an anderen Stellen für denselben Kontext.
7. Verwenden Sie Lösungsdomänennamen: Versuchen Sie, Begriffe aus der Informatik zu verwenden. Verwenden Sie den Klassennamen AccountFacade, wenn er dem Fassadenmuster entspricht
8. Verwenden Sie problematische Domänennamen: Wenn es keinen relevanten Informatikbegriff für den speziellen Fall gibt, siehe Domäne/Anwendungsfall
9. Verwenden Sie nicht zu lange Namensgebungen
10. Verwenden Sie Konstanten, Aufzählungen anstelle von magischen Zahlen, Abkürzungen

1. Tue eines: Funktion sollte nur eine Aufgabe haben und sie sollte sie gut machen
2. Eine Abstraktionsebene pro Funktion: Der Inhalt einer Funktion sollte sich auf derselben Abstraktionsebene befinden
3. Code von oben nach unten lesen: Funktion soll als Text lesbar sein. Lokale Variablen sollten in der Nähe ihres Verwendungsorts instanziiert werden
4. Funktionsargumente: Null Argumente zu haben ist perfekt, ein bis zwei Argumente sollten tolerierbar sein, mehr als drei Argumente sollten vermieden werden
5. Keine Nebenwirkungen: Funktion soll keine Nebenwirkungen haben, sie soll nur ihre Aufgabe erfüllen
6. Duplikate vermeiden
7. Transitive Navigation vermeiden

Gute Kommentare:

1. Rechtliche Anmerkungen: Unternehmensstandards, Copyright oder Autorenschaft müssen teilweise erwähnt werden
2. TODO-Kommentare: Dies ist, um an einige weitere Aktionen in der Zukunft zu erinnern
3. JavaDocs in öffentlicher API: Eine Erklärung einer von Dritten zu verwendenden Funktionalität sollte bereitgestellt werden, um die Verständlichkeit für diese Benutzer zu erhöhen

1. Redundante, irreführende, alte Kommentare: Diese Art von Kommentaren sollte immer vermieden werden, da sie keinen Mehrwert für den Quellcode haben
2. Auskommentierter Code: Wenn es einen auskommentierten Code gibt, für den keine weitere Erklärung erforderlich ist, warum er auskommentiert wird, ob er in Zukunft verwendet wird oder nicht, sollte er entfernt werden. Sofern es keine zusätzlichen Informationen gibt, warum sie auskommentiert sind.
3. Zu viele Informationen: Kommentare sollten präzise und minimal sein

Wir werden hier keine Formatierungsrichtlinien besprechen, da es fast in allen IDEs Plugins von Drittanbietern für die Formatierung gibt (zB Prettier in VS Code).

Objekt- und Datenstrukturen

Objekte verbergen ihre Daten hinter Abstraktionen und legen Funktionen offen, die mit diesen Daten arbeiten. Datenstruktur legen ihre Daten offen und haben keine sinnvollen Funktionen.

Die Quintessenz einer Datenstruktur ist eine Klasse mit öffentlichen Variablen und ohne Funktionen. Dies wird manchmal als Datenübertragungsobjekt oder DTO bezeichnet.

Nun, aus Sicht des Clean Coding sollte Ihre Datenstruktur nur private Eigenschaften mit öffentlichen Gettern und Settern und keine Geschäftslogik haben. Andererseits sollten Objekte nur eine Geschäftslogik mit Verbindung zu Datenstrukturen über Abstraktionen haben.

1. Aber anstatt private Eigenschaften und öffentliche Getter-Setter zu haben, ist es der bessere Weg, es in Form von Schnittstellen zu haben, die weder Eigenschaften noch Methodenimplementierungen offenlegen.
2. Verwenden Sie DTOs zum Protokollieren und Übertragen von Rohdaten

1. Verwenden Sie Ausnahmen, anstatt Code zurückzugeben: Geben Sie kein Fehlerflag oder Fehlercode zurück, sondern arbeiten Sie immer mit Ausnahmen, wenn die Programmiersprache dies zulässt
2. Try-Catch-Finally-Anweisungen: Verwenden Sie try-catch-Anweisungen in allen Abschnitten, von denen Sie glauben, dass sie nicht gut laufen. Schließlich sollte Scope verwendet werden, wenn Sie nicht sicher sind, ob catch Scope die Situation richtig handhabt
3. Kontext bereitstellen: Geben Sie detaillierte Informationen zu Ausnahmen an, bleiben Sie jedoch minimalistisch
4. Nicht null zurückgeben, null nicht übergeben

1. Eine Behauptung pro Test: Vermeiden Sie chaotische Tests, die mehrere Funktionalitäten prüfen
2. Einzelnes Konzept pro Test: Vermeiden Sie das Testen mehrerer Konzepte in einem einzigen Test
3. Testgetriebene Entwicklung anwenden

1. Klassen sollten klein sein: Vermeide Monsterklassen oder Götterklassen, die mehrere Aufgaben erledigen. Große Klassen bedeuten häufige Änderungen und Volatilität
2. Prinzip der Einzelverantwortung: Wenden Sie SRP auf Klassen an. Jede Klasse sollte nur für eine Aufgabe verantwortlich sein
3. Zusammenhalt: Die Klassen sollten einen hohen Zusammenhalt aufweisen. Zusammenhalt wird eure Klassen klein machen
4. Importe organisieren: Organisieren Sie den Import von Abhängigkeiten zu Klassen. Gute Praxis ist das Importieren in der folgenden Reihenfolge: Systemabhängigkeiten, Abhängigkeiten von anderen Plugins, Abhängigkeiten vom selben Plugin, Abhängigkeiten vom selben Paket
5. Für Veränderungen organisieren / Von Veränderungen isolieren: Klassen sollten so organisiert werden, dass volatile Klassen von Klassen getrennt werden, die stabil bleiben sollen
6. Die Basisklasse sollte nicht von ihren Derivaten abhängen

PS Sie können sich mit mir auf Twitter oder Linkedin verbinden .