JavaRush /Java-Blog /Random-DE /Robert Martin, Clean Code. Rezension des Buches „Kung-Fu-...
Artem Murk
Level 35
Днепр

Robert Martin, Clean Code. Rezension des Buches „Kung-Fu-Code“ für Entwickler

Veröffentlicht in der Gruppe Random-DE
Hallo Javarashevites! Dieser Artikel ist eine Rezension des Buches „Clean Code“ von Robert Martin. Gemeinsam schauen wir uns Möglichkeiten zur Verbesserung und Optimierung Ihres Codes an und am Ende erwartet Sie eine kleine, aber interessante Aufgabe.
„Clean Code“ von Robert Martin.  Rezension des Buches „Kung-Fu-Code“ für Entwickler – 1
Wenn wir jeden Tag Ihren Code-Editor öffnen, werden wir mit vielen Klassen, Funktionen und Variablen konfrontiert. Die beste Option ist, wenn es sich um Ihren von Grund auf neu geschriebenen Code handelt, der nur einmal geschrieben wurde, nur wenige Zeilen enthält, Sie allein daran arbeiten, keine Änderungen vorgenommen werden und keine weitere Unterstützung durch den Kunden erfolgt. ABER! Wie die Praxis zeigt, denke ich, dass Sie selbst verstehen, dass dies nicht der Fall ist. Im Grunde müssen wir irgendwie mit Mitgliedern unseres Teams interagieren, den „Hindu“-Code pflegen und Produkte in Millionen von Zeilen zerlegen. Von meinen Schulungskollegen habe ich oft Antworten wie diese gehört: „Dieser Code wurde von mir geschrieben und ich werde ihn niemandem zeigen“, aber wenn ich auf Hilfe Anfragen für Hilfe zu einem solchen Code sehe, dauert es sehr lange Zeit (manchmal wirklich lange), mich damit zu befassen und zu verstehen, was die Person mir sagen wollte, ich möchte sogar sagen: „Löschen und noch einmal umschreiben“! Schätzen Sie die Zeit und Energie von Menschen, die Ihnen helfen möchten, richtig zu schreiben, und wenn Sie nicht wissen, wie, ist es nie zu spät, es zu lernen. Das Buch von Robert Martin sticht unter Büchern dieses Formats dadurch hervor, dass es viele Beispiele in Java enthält. Dies mag eine etwas fanatische Aussage meinerseits sein, aber sie wurde im OOP-Stil geschrieben, nämlich im Schreiben von Teilen und Abschnitten. Das Buch ist leicht zu verstehen und zu lesen und lässt sich gut unterwegs oder abends vor dem Schlafengehen lesen. Clean Code ist in 3 Teile unterteilt. Im ersten Teil werden wir gebeten, die Theorie des Buches durchzugehen und etwas über Designmuster und Regeln guten Benehmens zu lernen. Der zweite Teil lädt uns ein, Refactoring und Schreiben zu üben, und der dritte Teil ist die abschließende Zusammenfassung der Code-„Gerüche“ in den Beispielen. Nun, der Autor hat viele Themen angesprochen, für die Sie hauptsächlich Kenntnisse in Java Core benötigen, aber es gibt auch Abschnitte, die sich mit JUnit-Unit-Tests, Log4j-Protokollierung und Kenntnissen über die einfachsten Muster im Design befassen (aber wie ich oben sagte, gibt es keine). viele davon, und alles Unverständliche lässt sich erfolgreich googeln, ja und im JavaRush-Kurs analysieren). Alle Kapitel des Buches stehen in keinem Zusammenhang zueinander; Sie können erfolgreich mit dem Lesen des Kapitels beginnen, das Ihnen gefällt. Eine kurze Zusammenfassung der wichtigsten Ideen, die ich aus dem Buch übernommen habe. Ich wäre dankbar für Ihre Kommentare dazu, in denen Sie Ihre eigene Sicht auf diese Aussagen mitteilen können.

1. Kommentare == böse.

In den meisten Fällen sind Kommentare Krücken, mit denen wir versuchen, unseren schlechten Code zu vertuschen. Und in einigen Fällen lügen sie auch über den Zweck von Methoden oder Variablen, wenn der Code ständig umgestaltet wird.

2. Kommentierter Code, toter Code.

Diese Codeteile in Ihrer Anwendung zu belassen, käme gleichbedeutend mit Müll. Mit der Zeit sammelt sich ungenutzter Code an und beeinträchtigt die Sauberkeit Ihrer Anwendung. Überprüfen Sie den Code von Zeit zu Zeit auf solche Module.

3. Überschriften von Methoden, Klassen und Variablen.

Es lohnt sich, dieses Thema in separaten Artikeln zu diskutieren. Seien Sie nicht faul und schreiben Sie Namen, die ihren Zweck verraten. Lernen Sie einige Standards für die Rechtschreibung von Titeln kennen. Dieses Thema ist für ein detailliertes Studium ein „Muss“.

4. Jede Methode und Variable hat ihren Platz in der Klassenhierarchie.

Normalerweise kann eine Klasse über Variablen und Methoden (statisch und nicht statisch), einen Konstruktor, verschachtelte und innere Klassen sowie Aufzählungen verfügen. Kurz gesagt, es gibt viele Informationen und es ist notwendig, den Platz jedes Einzelnen in der Klasse zu bestimmen. Wenn Sie sich die Java-Kernklassen ansehen, werden Sie feststellen, dass die Struktur klar strukturiert ist. Wir können jeden Teil an seinem Platz sehen. Natürlich kann es sich in Ihren Projekten innerhalb des Projekts ändern, aber nicht in jeder Klasse. Für mich selbst habe ich folgende Konstruktionsstruktur definiert: Am Anfang der Klasse habe ich statische Variablen, dann Objektvariablen + Enums, falls vorhanden. Nach den Variablen definiere ich die Klassenkonstruktoren. Dann schreibe ich Methoden für die Arbeit mit der Klasse. Nach den Methoden schreibe ich Getter und Setter. Und ganz am Ende habe ich innere Klassen. Sie können meine Struktur verwenden oder Ihre eigene in den Kommentaren schreiben.

5. Abstraktionsebenen von Methoden.

Für mich war das die Entdeckung Nr. 1. Jede Methode enthält Operatoren nur auf einer Abstraktionsebene. Sie sollten mehrstufige Vorgänge nicht miteinander vermischen.

6. Fehlerbehandlung.

Geprüfte oder ungeprüfte Ausnahmen, was ist besser im Projekt zu verwenden (was denken Sie?, Kommentare schreiben)? Ich bin ein Befürworter von „checked“, aber das Buch hilft dabei, ungeprüfte Ausnahmen von außen zu betrachten. Tatsächlich entstellt eine nicht aktivierte Ausnahme die Methodensignatur nicht, insbesondere wenn man bedenkt, dass Ausnahmen mehrere Ebenen gleichzeitig „durchdringen“. Die Unannehmlichkeiten der kleinsten Änderung führen dazu, dass die gesamte Methodenkette neu definiert wird, bevor sie erfasst wird, was in vielen Fällen für die Entwicklung äußerst unpraktisch ist.

7. Codeformatierung.

Richtig formatierter Code ist nicht nur klar, sondern auch gut lesbar. Man bekommt sofort einen Eindruck von den Klammern und den darin enthaltenen Aktionen. Am Beispiel der Bedingungen in den if, else-Konstrukten sollte man nicht alles in eine Zeile schreiben, sondern lieber lange Ketten verschieben.

8. Verneinungen in der Bedingung.

Versuchen Sie, Verleugnung unter bestimmten Bedingungen zu vermeiden, das ist eher ein psychologischer Faktor, unser Gehirn nimmt Verleugnung nicht gut wahr, und ja! bevor der Ausdruck möglicherweise nicht bemerkt wird. Wenn Sie beispielsweise if (!condition.isTrue) negieren, ist es besser, die Methode neu zu schreiben. Dadurch wird es viel einfacher (condition.isFalse).

9. Funktionen müssen eine Operation ausführen.

Wenn Ihre Methode viele Operationen ausführt, teilen Sie diese in Einzeloperationsmethoden auf. Diese Methoden sind sehr einfach zu unterstützen, einfach zu testen und bei Bedarf zu ersetzen oder zu entfernen.

10. Wiederholen Sie sich nicht.

Wiederholen Sie den Code nicht DRY (Wiederholen Sie sich nicht). Dies ist eine der grundlegenden Regeln, die Ihren Code erheblich reduzieren wird. Denken Sie daran. Versuchen Sie, alle sich wiederholenden Codeteile in einer separaten Funktion unterzubringen. Natürlich können wir noch viel mehr über DRY, KISS (Keep it simple Stupid), SOLID , YAGNI reden. Diese Begriffe sind für das Verständnis und die Gestaltung unerlässlich. Sie sind einen eigenen Artikel wert, vielleicht werde ich noch einmal darüber schreiben, da dieser Artikel einer Rezension des Buches „Clean Code“ gewidmet ist.
„Clean Code“ von Robert Martin.  Rezension des Buches „Kung-Fu-Code“ für Entwickler – 2
Wie versprochen eine kleine und einfache Aufgabe für Sie. Das Programm muss den Adipositas-Index anhand der angegebenen Daten berechnen. Schreiben Sie in die Kommentare die Anzahl der Fehler und Korrekturen im Code. P.S. Der Code funktioniert und erfüllt seine Funktion, wenn er richtig verwendet wird.
//Weight in kg.
//Height in metres.
public class sample {
    public static void main (String[] args) {
        humanIMB humanIMB = new humanIMB(80,1.52);
        System.out.println(humanIMB.Result());
    }
}
class humanIMB {
    public double W; //Weight Human
    public double H; // Height Human
    private static double imb;
    public humanIMB(double w, double h) {
        W = w;
        H = h;
        imb = W / (H * H);
    }
    public double takeW() {
        return W;
    }
    public void putW(double w) {
        W = w;
        imb = W / (H * H);
    }
    public double takeH() {
        return H;
    }
    public void putH(double h) {
        H = h;
        imb = W / (H * H);
    }
    public static double takeImt() {
        return imb;
    }
    public static String Result() {
        String  string = null;
        if (imb >=18.5 & imb <25) {
            string ="Норма, ты в форме!";
        }
        if (imb >=25 & imb <30) {
            string ="Предожирение. Эй, поосторожнее с пирожными ";
        }
        if (imb >=30) {
            string ="Ожирение. SCHWEINE! Хватит жрать, иди на треню!";
        }
        if (imb <18.5) {
            string ="Дефицит массы тела. В модели решил переквалифицироваться?";
        }
        return string;
    }
}
Kommentare
TO VIEW ALL COMMENTS OR TO MAKE A COMMENT,
GO TO FULL VERSION