Clean Code: Kurzen+ Performanten Code schreiben (Teil 3)

Clean Code soll nicht nur schön aussehen und gut lesbar sein, sondern dient dazu, die …

• Performance zu erhöhen
• Speicherverbrauch zu senken
• Umfang des Codes zu reduzieren

Der dritte Teil des dreiteiligen Clean-Code-Tutorials soll Dir dabei helfen, wie Du Deinen Code am besten bearbeiten kannst.

Dynamischer Code und Clean Code

Liebe die For-Schleifen!

Warum?

Clean Code ist möglichst dynamisch. Vermeide im Programmcode, keine festen Zahlen z. B. für die Länge des Arrays, sondern ermittele diese per Funktion .size(). Manchmal geht das nicht, dann schreibst Du alle Deinen festen Zahlen und Strings in eine YAML / TOML, welche eine Liste an allen Konstanten in Deinem Projekt sind (ähnlich wie bei einer Datenbank).

Dazu iterierst Du über einen Array stückweise weg und gibst Element für Element aus.

💣Coding Horror – So nicht!

Vermeide „hart“ codierte Abschnitte.

document.write("afdaf");
document.write("afdaf");
document.write("afdaf");
document.write("afdaf");
document.write("afdaf");

👌 Clean Code – So sollte Dein Code aussehen

for, foreach oder while sind die Besten!

for(let iterativeCoutner  = 0; iterativeCoutner  < orderList.length; iterativeCoutner ++){
    document.write(orderList[iterativeCoutner]);
}

Clean Code rekursiv oder iterativ

Um Code zu wiederholen, kannst Du iterativ oder rekursiv den Code ausführen. Ich empfehle Dir den iterativen Ansatz zu wählen, da die meisten Programmierer iterativ intuitiv verstehen.

function recursive(i){
    // Anker
    if(i = 0) return 0;
    // Anker 2
    if(i = 1) return 1;
    
    if(i > 1) {
        return this.recursive(i-1);
    }
}

Wenn Dein Code in rekursiver Form die iterative Version in Performance und Kürze deutlich schlägt, solltest Du auf eine beschreibende Benennung achten und rekursiv codieren. Füge zu der Rekursion einen aussagekräftigen Kommentar hinzu, der begründet, warum die Rekursion in diesem Abschnitt besser ist.

Verwende Rekursion nur, wenn Du mit sehr großen Datenmengen arbeiten musst. Beim Programmieren eines Frontends ist das nicht notwendig.

3 Strategien für mehr Qualität

• Code Review: Wenn Du Deinen Code fertiggestellt hast, kannst Du einem Kollegen Deinen Code vorstellen. Dazu scrollst Du durch den wesentlichsten Code und erklärst, was Du gemacht hast. Dein Kollege sollte Dich auf mögliche Bugs hinweisen, bei Schwachstellen meckern und unsauberen Code kritisieren. Dein Kollege hat eine andere Perspektive auf den Deinen Code.
• Pair Programming: Der etwas zeitaufwendiger Weg bietet eine hohe Codequalität. Der eine tippt, der andere denkt mit und weist den Tippenden an. Die Rolle wechselst Du jede Stunde durch. Diese Art von Programmierung vermeidet grobe Bugs und schlechten Spagetti Code.
• Unit-Tests: Mit Unit-Tests kannst Du überprüfen, ob Dein Programm die korrekten Ergebnisse errechnet. Unit-Tests sind Probedurchläufe mit einfachen Demo-Situationen, der die Ergebnisse der aktuellen Ausführung Deines Codes (IST-Status), mit den zu erwartenden Ergebnisse (SOLL-Status) vergleicht.
• Scanner: Formatierung, einfache Bugs, Null-Pointer und anderen ungewünschten Mist findet Software wie SonarQube bei jedem Commit. Du einigst Dich auf einen Standard im Unternehmen. Lege eine Test-Coverage fest – Wie viel vom neuen Code, muss von Unit-Tests gedeckt sein? Welche Formatierung soll der Code haben?

Guter Code braucht hartes Feedback von anderen!

Mit Clean Code zu mehr Performance

Wenn Du Deinen Code performanter machen möchtest, brauchst Du eine Clean-Code-Grundlage, um den Code überblicken und verbessern zu können. Verwende dazu Clean Code erster Teil und zweiter Teil. Beim Refactoring fallen Dir (bestimmt) Codeabschnitte auf, die sich in einer dreifachen For-Schleife befinden. Mit einem break; an der richtigen Stelle kannst Du viele unnötige Iterationen sparen.

Lerne alles über die 0-Notation und Laufzeitanalysen

Nicht ÜBER-Optimieren

Beispiel: Im User Interface Design möchtest Du einen Like-Button platzieren.

Mit dynamischem Code könntest Du eine JSON-Datei als Datengrundlage verwenden und diesen mit einer For-Schleife ausgeben. Der große Nachteil des dynamischen Codes ist, dass dieser unübersichtlicher ist, weil man sich die Daten zusammen suchen muss.

Deshalb kannst Du einzelne Komponenten „hart“ coden. Ist in absehbarer Zeit eine Erweiterung mit vielen weiteren Buttons realistisch, dann solltest Du beim dynamischen Code bleiben.

Guter Code ist trocken (DRY)

DRY – Don’t Repeat Yourself – Bevor Du beginnst Code zu schreiben, solltest Du Dir Gedanken, über die Architektur Deines Projekts machen. Trenne stricken die Datenhaltung, Interface und Funktionsschicht (Backend-Code) ab, weil …

• Die Moden im Interface sich jedes Jahr ändern können
• Datenhaltung von Anfang an immer gleich bleiben soll
• Kein Programmierer eine App neu builden will, weil nur eine Variable angepasst werden soll

Keine festen Datensätze im Code vermeidet Daten Redundanzen;

• Verwende eine Programmier-Bibliothek, um keine Zeit zu verlieren.
• Versuche Muster im Code zu erkennen, um diese Funktionen zu extrahieren.
• Verwende diese Funktion immer wieder

Wiederhole Dich nicht! (DRY – Don’t Repeat Yourself)

Je generischer Dein Code ist, desto weniger Zeilen Code brauchst Du. Messe Deine Produktivität nicht an Zielen an Code, sondern an funktionierenden und stabilen Funktionen, die Deine Software auszeichnen.

Learnings für diesen Teil

• Du solltest For-Schleifen lieben!
• Lerne alles über die 0-Notation und Laufzeitanalysen.
• Die beste Optimierung ist keine Optimierung.
• Verwende Array-Strukturen, statt Hard-Code!
• Rekursion nur verwenden, wenn dieser DEUTLICH besser ist!
• Guter Code braucht hartes Feedback von anderen!
• Wiederhole Dich nicht! (DRY – Don’t Repeat Yourself)