Clean Code Kochbuch (eBook)

KAPITEL 1

Clean Code

Als Martin Fowler in seinem Buch Refactoring: Improving the Design of Existing Code (dt. Refactoring: Wie Sie das Design bestehender Software verbessern) den Begriff »Refactoring« definierte, beschrieb er dessen Stärken und Vorteile und die Gründe für Refaktorierungen. Glücklicherweise kennen die meisten Entwickler mehr als zwei Jahrzehnten später die Bedeutung von Refactoring und Code-Smells. Entwickler kämpfen täglich mit technischen Schulden, und Refactoring ist zu einem zentralen Bestandteil der Softwareentwicklung geworden. In seinem grundlegenden Buch nutzt Fowler Refactorings, um Code-Smells zu eliminieren. Dieses Buch stellt einige dieser Refactorings in Form semantischer Rezepte vor, mit denen Sie Ihre eigenen Lösungen verbessern können.

Was ist ein Code-Smell?

Ein Code-Smell, wörtlich ein »übler Codegeruch«, signalisiert ein Problem im Code. Oft deuten Menschen das Vorhandensein von Code-Smells als Indiz dafür, dass das gesamte System auseinandergenommen und neu aufgebaut werden muss. Das widerspricht aber dem Geist der ursprünglichen Definition. Code-Smells sind lediglich Indikatoren für mögliche Verbesserungen. Ein Code-Smell verrät nicht direkt, was falsch ist, er mahnt nur zu besonderer Vorsicht.

Die in diesem Buch vorgestellten Rezepte bieten Lösungen für diese Symptome und ihre zugrunde liegenden Probleme. Wie in jedem Kochbuch sind auch diese Rezepte Vorschläge und die Hinweise zu Code-Smells Leitlinien und Heuristiken, keine starren Regeln. Bevor Sie ein Rezept blind anwenden, sollten Sie die zugrunde liegenden Probleme verstehen und die Vor- und Nachteile Ihres Entwurfs und Codes abwägen. Zu einem guten Codedesign gehört es, Leitlinien mit praktischen Überlegungen und dem jeweiligen Kontext in Einklang zu bringen.

Was ist Refactoring?

Fowler liefert in seinem Buch zwei sich ergänzende Definitionen:

Refactoring (Substantiv): eine Änderung der internen Struktur einer Software, um sie verständlicher und kostengünstiger veränderbar zu machen, ohne ihr beobachtbares Verhalten zu ändern.

refaktorieren (Verb): Software durch die Anwendung einer Serie von Refactorings zu restrukturieren, ohne ihr beobachtbares Verhalten zu verändern.

Der Begriff »Refactoring« wurde 1990 von Ralph Johnson und William Opdyke geprägt und im Jahr 1992 zum Thema von Opdykes Dissertation, »Refactoring Object-Oriented Frameworks« (https://oreil.ly/zBCkI). Populär wurden Refactorings später durch Fowlers Buch. Seit Fowlers Definition hat sich viel in diesem Bereich getan. Die meisten integrierten Entwicklungsumgebungen (IDEs) unterstützen heutzutage automatische Refactorings und führen strukturelle Änderungen sicher durch, ohne das Systemverhalten zu verändern. Dieses Buch enthält viele Rezepte für solche automatischen, sicher anwendbaren Refactorings. Es bietet darüber hinaus auch semantische Refactorings an, die allerdings nicht automatisch sicher sind, da sie das Systemverhalten ändern können. Seien Sie also bei der Anwendung von Rezepten mit semantischen Refaktorierungen vorsichtig, da sie Ihre Software in Mitleidenschaft ziehen können. Ich werde in entsprechenden Fällen darauf hinweisen. Wenn das Verhalten Ihres Codes durch Tests umfassend abgedeckt ist, können Sie sicher sein, dass wichtige Geschäftsszenarien nicht beeinträchtigt werden. Refactoring-Rezepte sollten nicht gleichzeitig mit Fehlerkorrekturen oder der Entwicklung neuer Funktionen angewendet werden.

Die meisten modernen Unternehmen nutzen in ihren CI/CD-Pipelines leistungsstarke Testsuiten. Sehen Sie sich auch Software Engineering at Google von Titus Winters et al. (O’Reilly 2020) an, um herauszufinden, ob diese Testabdeckungssuiten bei Ihnen vorhanden sind.

Was ist ein Rezept?

Ich verwende den Begriff »Rezept« in einem eher lockeren Sinne. Ein Rezept besteht aus einer Reihe von Anweisungen, um etwas zu erstellen oder zu verändern. Die Rezepte in diesem Buch funktionieren am besten, wenn Sie die dahinterstehende Absicht erfassen, es aber auf Ihre eigene Art und Weise umsetzen. Andere Kochbücher in dieser Reihe sind konkreter und enthalten Schritt-für-Schritt-Lösungen. Um die Rezepte dieses Buchs zu verwenden, müssen Sie sie in die von Ihnen genutzte Programmiersprache und für Ihr Softwaredesign übersetzen. Die Rezepte sollen Ihnen helfen, ein Problem zu verstehen, die damit verbundenen Konsequenzen zu erkennen und Ihren Code zu verbessern.

Warum Clean Code?

Clean Code – guter, sauber formulierter Code – lässt sich leicht lesen, verstehen und warten. Er ist gut strukturiert, präzise und verwendet aussagekräftige Bezeichnungen für Variablen, Funktionen und Klassen. Er orientiert sich zudem an etablierten Best Practices und Entwurfsmustern, wobei Lesbarkeit und Verhalten Vorrang vor Performance und Implementierungsdetails haben.

Clean Code ist in allen sich weiterentwickelnden Systemen, in denen tägliche Änderungen stattfinden, sehr wichtig. Das gilt ganz besonders für Umgebungen, in denen es nicht möglich ist, beliebig schnell Updates durchzuführen, wie etwa bei Embedded Systems, Raumsonden, Smart Contracts, mobilen Apps (zum Beispiel wegen Verzögerungen durch interne Reviews der Store-Anbieter).

Während sich klassische Refactoring-Bücher, Websites und IDEs auf Refaktorierungen konzentrieren, die das Systemverhalten nicht ändern, enthält dieses Buch sowohl Rezepte für solche Szenarien (z.B. sichere Umbenennungen), aber auch semantische Refactorings, bei denen sich die Art und Weise ändert, in der bestimmte Probleme gelöst werden. Es ist wichtig, den Code, die zugrunde liegenden Probleme und die Intention des Rezepts zu verstehen, um angemessene Anpassungen vornehmen zu können.

Lesbarkeit, Performance – oder beides?

Dieses Buch dreht sich um Clean Code. Einige der Rezepte mögen nicht zu den herausragend performanten Lösungen gehören. Im Zweifel ziehe ich aber die Lesbarkeit der Leistung vor. Deshalb widme ich ein ganzes Kapitel (Kapitel 16) der vorzeitigen Optimierung, bei der Leistungsprobleme adressiert werden, ohne dass für die Notwendigkeit der Optimierung ausreichende Evidenz vorliegt.

Für leistungsabhängige, unternehmenskritische Aufgaben besteht die beste Strategie darin, zunächst Clean Code zu schreiben und diesen mit Tests abzudecken, um anschließend die Engpässe unter Anwendung des Pareto-Prinzips zu verbessern. Dieses Prinzip, angewendet auf Software, besagt, dass man die Performance um 80% steigern kann, wenn man 20% der kritischen Engpässe bearbeitet.

Diese Herangehensweise wirkt der Tendenz entgegen, vorzeitige Optimierungen vorzunehmen, ohne dass dafür ausreichend Evidenz vorliegt. Vorzeitige Optimierungen führen meist nur zu geringen Verbesserungen und können Clean Code beeinträchtigen.

Arten von Software

Die meisten Rezepte in diesem Buch zielen auf Backend-Systeme mit komplexer Geschäftslogik. Der Simulator, dessen Konstruktion wir in Kapitel 2 beginnen werden, eignet sich perfekt dafür. Da die Rezepte domänenunabhängig sind, können Sie die meisten auch bei der Frontend-Entwicklung, für Datenbanken, Embedded Systems, Blockchains und in vielen andere Szenarien anwenden. Es gibt zudem spezifische Rezepte mit Codebeispielen für UX, Frontend, Smart Contracts und andere Bereiche (siehe beispielsweise »Low-Level-Fehler vor Endbenutzern verstecken« auf Seite 362).

Maschinengenerierter Code

Muss man denn auch heute, da es eine Vielzahl von Tools für computergenerierten Code gibt, noch über Clean Code nachdenken? Die Antwort ist ein klares Ja. Sogar mehr denn je. Für die Programmierung gibt es viele kommerzielle Codeassistenten. Allerdings haben sie (noch) nicht die vollständige Kontrolle: Sie agieren als Copiloten und Helfer, aber die Designentscheidungen trifft weiterhin der Mensch.

Zum Zeitpunkt der Erstellung dieses Buchs erzeugen die meisten kommerziellen und KI-Tools anämische Lösungen und Standardalgorithmen. Sie sind jedoch erstaunlich nützlich, wenn einem gerade nicht einfällt, wie man eine kleine, spezifische Funktion erstellt, oder um zwischen Programmiersprachen zu übersetzen. Beim Schreiben dieses Buchs habe ich solche Werkzeuge intensiv genutzt. Ich beherrsche die mehr als 25 Programmiersprachen, die ich in den Rezepten verwendet habe, nicht alle selbst. Viele Codebeispiele habe ich mit der Unterstützung einer Vielzahl von Assistenztools in verschiedene Sprachen übersetzt und getestet. Ich möchte auch Sie dazu einladen, alle verfügbaren Werkzeuge zu nutzen, um die Rezepte dieses Buchs in Ihre bevorzugte Sprache zu übersetzen. Diese KI-Werkzeuge sind...