Clausen Five Lines of Code

Clean Code durch gezieltes Refactoring
1. Auflage 2022
ISBN: 978-3-8362-9226-9
Verlag: Rheinwerk
Format: EPUB
Kopierschutz: 0 - No protection

E-Book, Deutsch, 388 Seiten

Reihe: Rheinwerk Computing

Refactoring ist die Kunst, bestehenden Code so zu verbessern, dass der Wert von Software langfristig erhalten bleibt. Das Ergebnis des Vorgangs ist als Clean Code bekannt - aber wie kommen Sie dahin? Christian Clausen legt hier eine ganz neuartige Schule des Refactorings vor, die Sie Schritt für Schritt anleitet. Das Vorgehen eignet sich für alle OOP-Sprachen. Die gut lesbaren Beispiele in TypeScript sind in einem Stil gehalten, der insbesondere Java- und C#- Entwickler*innen vertraut sein dürfte. Ein zweispaltiges Vorher-Nachher-Layout mit zeilengenauen Codekommentaren macht jeden Arbeitsschritt hervorragend nachvollziehbar. So gelingt Ihr Refactoring sicher!

Aus dem Inhalt:

• Anzeichen für Verbesserungsbedarf im Code
• Code in sicheren Schritten verbessern - auch, wenn Sie ihn nicht verstehen
• Optimierungen und Wiederverwendbarkeit sinnvoll abwägen
• Gute Compiler-Praxis
• Viele Patterns und Methoden für das konkrete Vorgehen
• Wie man Code schreibt, der ohne Kommentare auskommt
• Best Practices aus realen Projekten

Autoren/Hrsg.

Clausen, Christian

Inhaltsverzeichnis

Materialien zum Buch ... 16  Vorwort ... 17  Einführung ... 19  Danksagungen ... 23  Der Autor ... 25  Der Übersetzer ... 25  1.  Refactorings für Refactoring ... 27  1.1 ... Was ist Refactoring? ... 28  1.2 ... Fähigkeiten: Was sollte ich refactorn? ... 29  1.3 ... Kultur: Wann sollte ich refactorn? ... 31  1.4 ... Werkzeuge: Wie sollte ich (sicher) refactorn? ... 33  1.5 ... Werkzeuge für den Anfang ... 34  1.6 ... Das durchgehende Beispiel: ein 2D-Rätselspiel ... 36  1.7 ... Ein Wort zu Software aus der echten Welt ... 38  1.8 ... Zusammenfassung ... 39  2.  Ein Blick unter die Haube ... 41  2.1 ... Lesbarkeit und Wartbarkeit verbessern ... 41  2.2 ... Geschwindigkeit, Flexibilität und Stabilität gewinnen ... 45  2.3 ... Refactoring und die tägliche Arbeit ... 47  2.4 ... Die Domäne einer Software definieren ... 48  2.5 ... Zusammenfassung ... 49

TEIL I.  Das Refactoring eines Computerspiels als Lernbeispiel ... 51  3.  Lange Funktionen zerschlagen ... 53  3.1 ... Unsere erste Regel: Warum fünf Zeilen? ... 54  3.2 ... Ein Refactoring, um Funktionen aufzubrechen ... 57  3.3 ... Funktionen teilen, um Abstraktionsebenen zu trennen ... 66  3.4 ... Eigenschaften eines guten Funktionsnamens ... 69  3.5 ... Funktionen aufbrechen, die zu viel tun ... 72  3.6 ... Zusammenfassung ... 76  4.  Typen richtig nutzen ... 77  4.1 ... Refactoring einer einfachen if-Anweisung ... 77  4.2 ... Refactoring einer großen »if«-Anweisung ... 98  4.3 ... Mit doppeltem Code umgehen ... 114  4.4 ... Refactoring von zwei komplexen »if«-Anweisungen ... 118  4.5 ... Toten Code entfernen ... 122  4.6 ... Zusammenfassung ... 124  5.  Ähnlichen Code zusammenführen ... 127  5.1 ... Ähnliche Klassen zusammenführen ... 128  5.2 ... Einfache Bedingungen zusammenführen ... 145  5.3 ... Komplexe Bedingungen zusammenführen ... 150  5.4 ... Code in verschiedenen Klassen zusammenführen ... 156  5.5 ... Ähnliche Funktionen zusammenführen ... 178  5.6 ... Ähnlichen Code zusammenführen ... 182  5.7 ... Zusammenfassung ... 187  6.  Die Daten verteidigen ... 189  6.1 ... Kapselung ohne Getter ... 189  6.2 ... Einfache Daten kapseln ... 201  6.3 ... Komplexe Daten kapseln ... 214  6.4 ... Invariante Reihenfolgen entfernen ... 222  6.5 ... Ein anderes Vorgehen, um Enums zu löschen ... 226  6.6 ... Zusammenfassung ... 232

TEIL II.  Das Gelernte in die Praxis übertragen ... 233  7.  Mit dem Compiler zusammenarbeiten ... 235  7.1 ... Den Compiler kennenlernen ... 236  7.2 ... Den Compiler benutzen ... 245  7.3 ... Vertraue dem Compiler ... 255  7.4 ... Vertraue nur dem Compiler ... 258  7.5 ... Zusammenfassung ... 259  8.  Finger weg von Kommentaren ... 261  8.1 ... Veraltete Kommentare löschen ... 263  8.2 ... Auskommentierten Code löschen ... 263  8.3 ... Überflüssige Kommentare löschen ... 264  8.4 ... Kommentare in Methodennamen umsetzen ... 265  8.5 ... Kommentare behalten, die Invarianten dokumentieren ... 266  8.6 ... Zusammenfassung ... 267  9.  Lerne, das Löschen zu lieben ... 269  9.1 ... Code löschen: das nächste Abenteuer ... 270  9.2 ... Code löschen, um anfallende Komplexitätzu reduzieren ... 271  9.3 ... Code nach Vertrautheit kategorisieren ... 274  9.4 ... Code in einem Legacy-System löschen ... 275  9.5 ... Code aus einem eingefrorenen Projekt löschen ... 278  9.6 ... Branches aus der Versionskontrolle löschen ... 280  9.7 ... Codedokumentation löschen ... 282  9.8 ... Testcode löschen ... 284  9.9 ... Konfigurationscode löschen ... 286  9.10 ... Code löschen, um Bibliotheken loszuwerden ... 288  9.11 ... Code aus funktionierenden Features entfernen ... 291  9.12 ... Zusammenfassung ... 292

10.  Keine Angst vor neuem Code ... 293  10.1 ... Unsicherheit akzeptieren: In die Gefahr eintreten ... 294  10.2 ... Prototypen: gegen die Angst, das Falsche zu entwickeln ... 294  10.3 ... Verhältnismäßige Arbeit: gegen die Angst vor Verschwendung und Risiko ... 296  10.4 ... Schrittweise Verbesserung: gegen die Angst vor Imperfektion ... 297  10.5 ... Wie Copy & Paste unsere Geschwindigkeit beeinflusst ... 298  10.6 ... Verändern durch Hinzufügen: geplante Erweiterbarkeit ... 299  10.7 ... Verändern durch Hinzufügen erlaubt Abwärtskompatibilität ... 300  10.8 ... Verändern durch Hinzufügen mit Featureschaltern ... 302  10.9 ... Verändern durch Hinzufügen mit Verzweigung durch Abstraktion ... 306  10.10 ... Zusammenfassung ... 309

11.  Folge der Struktur im Code ... 311  11.1 ... Strukturen einteilen nach Wirkungsbereich und Herkunft ... 311  11.2 ... Drei Arten, wie Code Verhalten spiegelt ... 313  11.3 ... Code hinzufügen, um Struktur zu betonen ... 321  11.4 ... Beobachten statt vorhersagen -- empirische Techniken einsetzen ... 322  11.5 ... Sicherheit gewinnen, ohne den Code zu verstehen ... 323  11.6 ... Ungenutzte Strukturen finden ... 324  11.7 ... Zusammenfassung ... 333

12.  Vermeide Optimierung und Generalität ... 335  12.1 ... Nach Einfachheit streben ... 336  12.2 ... Verallgemeinern -- wann und wie ... 338  12.3 ... Optimieren -- wann und wie ... 340  12.4 ... Zusammenfassung ... 352

13.  Schlechter Code soll schlecht aussehen ... 353  13.1 ... Auf Prozessprobleme mit schlechtem Code aufmerksam machen ... 353  13.2 ... Trennung in sauberen und problematischen Code ... 355  13.3 ... Ansätze, schlechten Code zu definieren ... 356  13.4 ... Regeln für sicheren Vandalismus ... 359  13.5 ... Methoden für sicheren Vandalismus ... 359  13.6 ... Zusammenfassung ... 369

14.  Zum Abschluss ... 371  14.1 ... Ein Rückblick auf die Reise in diesem Buch ... 371  14.2 ... Die Philosophie dahinter ... 372  14.3 ... Wie mache ich weiter? ... 377  14.4 ... Zusammenfassung ... 378  A.  Die Werkzeuge für Teil I installieren ... 381  A.1 ... Node.js ... 381  A.2 ... TypeScript ... 381  A.3 ... Visual Studio Code ... 381  A.4 ... Git ... 382  A.5 ... Das TypeScript-Projekt einrichten ... 382  A.6 ... Das TypeScript-Projekt bauen ... 382  A.7 ... Wie du den Level änderst ... 383  Index ... 385

Leseproben

Einführung

In sehr jungen Jahren schon brachte mir mein Vater bei zu programmieren. Ich habe über Strukturen nachgedacht, solange ich denken kann. Meine Motivation war es immer, Menschen zu helfen. Dafür stehe ich morgens auf. Lehrberufe haben mich deshalb schon immer gereizt. Als mir an der Universität eine Stelle als Lehrassistent angeboten wurde, habe ich sofort zugegriffen. Und ich hatte einige dieser Stellen. Dann jedoch hatte ich Pech, und in einem Semester gab es nichts, was ich lehren konnte.

Unternehmerisch wie ich bin, gründete ich eine Organisation, in der Studierende andere Studierende unterrichten sollten. Jede und jeder war als Sprecher*in oder Zuhörer*in willkommen, und die Themen reichten von Lektionen, die man aus Hobbyprojekten gelernt hatte, bis zu fortgeschrittenen Themen, die über den Lehrplan der Universität hinausgingen. Ich dachte, so könne ich unterrichten. Ich hatte nicht Unrecht. Wie sich herausstellte, sind Informatikerinnen und Informatiker ein scheues Völkchen, und ich musste fast sechzig Wochen in Folge sprechen, um meine Organisation zum Laufen zu bringen. Ich habe in dieser Zeit viel gelernt, sowohl über meine Themen als auch über das Lehren. Außerdem habe ich mit diesen Vorträgen eine Gemeinschaft von Neugierigen geschaffen. Mit einigen von ihnen sind engste Freundschaften entstanden.

Einige Zeit, nachdem ich die Universität verlassen hatte, traf ich mich mit einem dieser Freunde. Aus Langeweile fragte er mich, ob ich einen Vortrag improvisieren könne, nachdem ich so viele gehalten hatte. »Probieren wir’s aus« war meine Antwort. Wir klappten einen Laptop auf, und ohne eine einzige Pause schrieb ich auf, was zum Beispiel der gesamte erste Teil dieses Buches werden sollte.

Als ich die Finger von der Tastatur nahm, war Ehrfurcht im Blick meines Freundes. Er dachte, das sei meine Demonstration gewesen. Doch ich hatte etwas anderes vor: Ich wollte ihm Refactoring beibringen.

Mein Ziel war ambitioniert. Nach einer Stunde sollte er programmieren können wie ein Meister-Refactorer. Codequalität und Refactoring sind verzwickte Themen. Es war klar, dass wir das nötige Wissen vortäuschen mussten. Ich betrachtete meinen Code und versuchte, Regeln zu finden, deren Befolgen ihn dazu bringen würde, das Richtige zu tun, die aber gleichzeitig einfach zu merken waren. Obwohl er das Fachwissen so nur vortäuschte, machte mein Freund während des Experiments echte Verbesserungen an meinem Code. Das Ergebnis war vielversprechend, und er lernte so schnell dazu, dass ich noch am selben Abend alles aufschrieb, was wir behandelt hatten. Wenn wir an meinem Arbeitsplatz unerfahrene Programmierer anstellten, wiederholte ich die Übung mit ihnen, und langsam sammelte und baute ich die Regeln und Muster für dieses Buch.

Das Ziel: die ausgewählten Regeln und Refactorings

Perfektion ist nicht dann erreicht, wenn es nichts mehr hinzuzufügen gibt, sondern wenn man nichts mehr weglassen kann

– Antoine de Saint-Exupéry

Auf der Welt gibt es Hunderte von Refactorings. Ich habe für dieses Buch nur dreizehn ausgewählt, weil ich glaube, dass tiefgehendes Wissen wertvoller ist als breite, aber oberflächliche Kenntnisse. Außerdem wollte ich eine zusammenhängende Geschichte erzählen, weil das Thema auf diese Weise mental einfacher zu organisieren ist. Dieselben Argumente gelten für die Auswahl der Regeln.

Es gibt nichts Neues unter der Sonne

– Prediger 1, 9

Ich behaupte gar nicht, mir für dieses Buch viel Neues überlegt zu haben, aber ich denke, ich habe vorhandene Dinge auf eine vorteilhafte Art neu kombiniert. Viele der Regeln sind aus Robert C. Martins Clean Code (Pearson, 2008) abgeleitet, aber angepasst, um sie leichter verstehen und anwenden zu können. Viele Refactorings stammen aus Martin Fowlers Refactoring (Addison-Wesley Professional, 1999), wurden aber angepasst, um die Prüfungen des Compilers zu nutzen anstelle einer umfangreichen Testsuite.

Das Publikum und der Weg

Dieses Buch besteht aus zwei sehr unterschiedlichen Teilen. Der erste bietet ein solides Grundwissen über Refactoring und richtet sich an einzelne Programmierende. Das Ziel ist nicht Umfang, sondern Verständlichkeit. Dieser Teil ist für Leserinnen und Leser, die noch an ihrem Grundverständnis von Refactoring arbeiten: Studierende, Berufseinsteigerinnen und -einsteiger und alle, die als Hobby programmieren. Wenn du den Beispielcode anschaust und denkst, dass er leicht zu verbessern ist, dann ist Teil I nichts für dich.

In Teil II konzentriere ich mich mehr auf die Umgebung und das Team. Ich habe die – meiner Meinung nach – wichtigsten Lektionen über Softwareentwicklung in der realen Welt ausgewählt. Einige Themen sind theoretischer Natur: »Mit dem Compiler zusammenarbeiten« (Kapitel 7) und »Folge der Struktur im Code« (Kapitel 11). Andere sind vorwiegend praktisch: »Lerne, das Löschen zu lieben« (Kapitel 9) und »Schlechter Code soll schlecht aussehen« (Kapitel 13). Dieser Teil sollte auch für erfahrene Entwicklerinnen und Entwickler noch Neues enthalten.

Teil I verwendet ein durchgehendes Codebeispiel. Die Kapitel sind so eng miteinander verbunden und sollten in der richtigen Reihenfolge gelesen werden. In Teil II stehen die Kapitel für sich, bis auf einige Querverweise. Wenn du keine Zeit hast, das ganze Buch zu lesen, kannst du dir problemlos die spannendsten Themen aus Teil II herauspicken und separat lesen.

Über das Lehren

Ich habe viel Zeit damit verbracht, über das Lehren nachzudenken. Wissen und Fähigkeiten weiterzugeben, bietet viele Herausforderungen. Lehrende müssen Motivation und Selbstvertrauen vermitteln und zur Reflexion anregen. Das Gehirn des Schülers oder der Schülerin würde lieber Energie sparen und versucht, vom Stoff abzulenken.

Um dieses sich wehrende Gehirn zum Lernen zu bringen, müssen wir zunächst Motivation erzeugen. Dazu präsentiere ich meist eine einfach aussehende Aufgabe. Wenn den Lernenden klar wird, dass sie keine Lösung finden können, treibt die natürliche Neugierde sie weiter. Das ist der Zweck des Codebeispiels in Teil I. »Mach diesen Code besser« klingt wie eine einfache Aufgabe, aber der Code hat bereits eine Qualität, bei der Verbesserungen nicht sofort offensichtlich sind.

Der zweite Schritt ist, den Schülerinnen und Schülern das Selbstvertrauen zu geben, ihr neues Wissen anzuwenden und damit zu experimentieren. Wie wichtig dieser Schritt ist, wurde mir in einem Französischkurs klar. Wenn uns unsere Lehrerin eine neue Phrase beibringen wollte, folgte sie immer denselben Schritten:

1. Sie forderte jeden von uns auf, die Phrase nachzusprechen: pures Nachahmen, um es einmal gesagt zu haben.

2. Sie stellte jedem von uns eine Frage. Wir verstanden die Frage nicht immer, aber aus der Betonung ging hervor, dass es eine Frage war. Da wir keine anderen Werkzeuge hatten, wiederholten wir die Phrase von zuvor. Die Wiederholung gab uns Selbstvertrauen in die Verwendung der Phrase und ein erstes Stück Kontext dafür. Verständnis begann.

3. Dann forderte die Lehrerin uns auf, die Phrase in einem Gespräch zu verwenden. Die Fähigkeit, gelernte Bausteine zu etwas Neuem zusammenzusetzen, ist das eigentliche Ziel der Lehre und setzt Verständnis und Selbstvertrauen voraus.

Ich habe gelernt, dass dieses Vorgehen dem Shuhari entspricht, einem Konzept aus dem japanischen Kampfsport, das auch außerhalb dieses Sports zunehmend populär wird. Es besteht aus drei Teilen: »Shu« ist Nachahmung ohne Frage und Verständnis, »ha« ist Variation – eine kleine Änderung am Erlernten –, und »ri« ist Originalität, das völlige Verlassen des Bekannten.

Shuhari unterstreicht Teil I. Ich empfehle, zunächst den Regeln zu folgen, auch ohne sie zu verstehen. Dann, wenn du den Wert der Regeln verstehst, fang an, sie zu variieren. Und dann, wenn du die Regeln gemeistert hast, kannst du dich mit Code Smells (etwa: »übel riechendem Code«) beschäftigen. Für Refactoring zeige ich Beispiele an echtem Code, und die Lesenden sollen die Änderungen nachvollziehen (Nachahmung). Dann zeige ich dasselbe Refactoring in einem anderen Kontext (Variation). Schließlich präsentiere ich ein weiteres Beispiel, in dem das Refactoring angewendet werden könnte. Ich ermutige die Leserschaft, sich selbst daran zu versuchen (Originalität).

Du kannst dein Vorgehen anhand dieses Buches verifizieren und den Code anhand der Git Tags. Wenn du nicht selbst am Code arbeitest, wird Teil I viel Wiederholung enthalten. Ich möchte dich dazu anhalten, mit den Händen auf der Tastatur zu lesen.

Über den Code

Dieses Buch enthält viele Codebeispiele, sowohl in nummerierten Listings als auch im Fließtext. In beiden Fällen ist Code in nicht proportionaler Schrift gesetzt, wie in diesem Beispiel, um ihn vom Text abzusetzen. Code, auf den sich die...