Zunächst werde ich alle Hauptabschnitte des Buches kurz beschreiben und meine kleinen Kommentare dazu geben. Danach folgt ein Gesamtfazit mit den Vor- und Nachteilen des Buches. Spoiler: Das Buch ist sehr gut und hat deutlich mehr Vorteile als Nachteile.
Grundlagen der Softwareentwicklung
Dieser Teil des Buches ist vollständig den grundlegenden Konzepten der Programmierung gewidmet sowie der Frage, aus welchen Bestandteilen die Programmierung besteht und was genau die Softwareentwicklung umfasst. Hier werden Phasen wie Anforderungsdefinition, Entwicklung, Testen und Wartung behandelt. Natürlich werden diese ausführlicher und interessanter beschrieben, sodass das Lesen nicht langweilig wird. Allerdings ist gerade dieser Abschnitt in erster Linie für diejenigen nützlich, die gerade erst ihre Karriere als Programmierer beginnen. Um das Verständnis dieses Teils noch weiter zu verbessern, verwendet der Autor Metaphern und Analogien (z.B. die Bau-Analogie). Wie in vielen ähnlichen Büchern wird auch hier die Fehlerkosten in den einzelnen Phasen der Softwareentwicklung (noch oberflächlich, da dies weiter unten detaillierter behandelt wird) angesprochen. Ein weiterer Pluspunkt dieses Abschnitts ist, dass bereits hier erwähnt wird, dass es verschiedene Ansätze in der Entwicklung gibt: iterative (spiralförmige) und Wasserfall-Modelle. Die Vor- und Nachteile jedes Ansatzes werden kurz beschrieben. Über modernere Begriffe und Methoden wie Scrum oder Agile wird hier nicht gesprochen, aber die vom Autor genannten Methodologien reichen für Einsteiger vollkommen aus. Schließlich spricht der Autor auch über wichtige Eigenschaften, die Software haben sollte, wie Skalierbarkeit, Wartbarkeit, Portabilität, Fehlertoleranz, Sicherheit und andere.
Hochwertiger Code
Wenn Sie denken, dass Sie nach dem nicht kleinen, aber dennoch interessanten Material sofort in einen Abschnitt eintauchen, in dem es um coolen Code und kontroverse Themen wie das Benennen von Funktionen und Variablen oder die Nutzung von Tabs und Leerzeichen geht, dann irren Sie sich. Es folgt ein ganzer Abschnitt über Softwaredesign. Ich würde nicht sagen, dass es hier um vollständige Architekturen geht — wie z.B. die Zwiebelarchitektur (bei Monolithen) oder Microservices. Vielmehr wird die Beschreibung des Systems als Ganzes betont, die Gliederung in größere Module und dann das Design einzelner Klassen, die wiederum durch Methoden beschrieben werden. Es handelt sich also um eine Art abstrakte Programmierung mit Diagrammen und Flussdiagrammen. Ich kann nicht garantieren, dass dieser Ansatz (mit Diagrammen und Flusscharts) heute noch überall angewandt wird. Das Einzige, wo ich dies selbst aktiv genutzt habe, war im College und später an der Universität. Bei keiner meiner Arbeitsstellen habe ich solche Diagramme gezeichnet, und auch meine Freunde und Kollegen nicht. In diesem Abschnitt wird auch ein Bezug zur OOP hergestellt, und für funktionale Programmierung mag das nicht ganz so einfach und offensichtlich sein. Daher ist es interessant, diesen Abschnitt zu lesen, aber wie sehr er in der Praxis angewendet werden sollte, ist fraglich.
Hier geht es eher um das Lösen kleiner und mittlerer Aufgaben als um vollständige Projekte. Es wird kein Wort über Technologien verloren, sondern überall Abstraktionen verwendet und das SOLID-Prinzip eingehalten. Übrigens wird das OOP-Prinzip recht gut erklärt. Natürlich könnte man darüber auch ein eigenes Buch lesen, aber für Einsteiger reicht dieses hier völlig aus. Es wird auch viel Zeit auf die richtige Benennung von Klassen und Methoden verwendet. Es wird erklärt, wann es sinnvoll ist, eine eigene Methode zu erstellen und wann nicht. Es gibt ein paar Worte über Exceptions und Fehlerbehandlung. Ein weiteres interessantes Plus für Anfänger ist das Programmieren mit Pseudocode. Ich nenne das gerne „Programmieren auf Papier“. Für Anfänger ist das besonders nützlich, wenn sie nicht wissen, wie sie einen bestimmten Algorithmus vollständig schreiben sollen.
Variablen
Ab diesem Abschnitt würde ich empfehlen, das Buch besonders aufmerksam zu lesen – auch für Programmierer, die bereits mehrere Projekte geschrieben haben und seit Jahren in der Entwicklung tätig sind.
Hundert Seiten Material. Man könnte meinen, was kann man alles über Variablen sagen? Es gibt einiges, und vieles davon ist nützlich. Der Abschnitt beginnt mit einem interessanten Test über Datentypen (einschließlich Bäume, Heaps und andere Typen). Es werden Beispiele für gute und schlechte Initialisierungen von Variablen in verschiedenen Sprachen gegeben. Der Gültigkeitsbereich wird anhand anschaulicher Abbildungen erklärt. Allgemeine Tipps zur Minimierung des Gültigkeitsbereichs werden genannt.
Es wird das Thema der Lebensdauer von Daten, die Benennung temporärer Variablen, Statusvariablen (Schalter) und Namenskonventionen für verschiedene Sprachen angesprochen. Es werden gängige und akzeptierte Abkürzungen, Standardpräfixe und sinnvolle Kürzungen von Namen behandelt.
Am Ende des Abschnitts gibt es eine detailliertere Einführung in Datentypen und deren Einschränkungen: Gleitkommazahlen, Enums, Konstanten, benutzerdefinierte Datentypen, Arrays, Strukturen und Zeiger.
Operatoren
In diesem Teil des Buches geht es um die sequentielle Organisation des Codes, die Verwendung von bedingten Anweisungen und Schleifen. Der Abschnitt umfasst ebenfalls 100 Seiten, daher gibt es hier viel zu entdecken. Zum Beispiel gibt es einen detaillierten Vergleich der Struktur und Laufzeit (Zeitaufwand) derselben Schleifen in verschiedenen Sprachen: C, C++, C#, Java und Visual Basic. Auch Rekursion und goto werden behandelt.
Code-Verbesserung
Der Abschnitt besteht aus folgenden Kapiteln:
- Softwarequalität
- Gemeinsame Konstruktion
- Von Entwicklern durchgeführte Tests
- Debugging
- Refactoring
- Strategien zur Code-Optimierung
- Methoden der Code-Optimierung
Am Anfang werden wieder die Anforderungen und Eigenschaften von Software genannt – fast dieselben wie zu Beginn. Es wird auf die Kosten der Fehlererkennung und -behebung hingewiesen. Der Abschnitt ist insgesamt theoretisch, mit wenig Code. Pair Programming wird erwähnt. Wie ich oben im ersten Abschnitt schrieb, ist das Material, auch dieses Kapitels, etwas umstritten, da vieles davon veraltet ist. Tests werden angesprochen. Übrigens werde ich bald eine Rezension zu einem separaten Buch über Tests schreiben. Anders als in gewöhnlichen Büchern, in denen erklärt wird, welche Testarten es gibt, was man abdecken soll und wie man Tests schreibt, geht der Autor hier einen anderen Weg. Er beschreibt z.B. typische Fehler beim Testen, wie die Analyse von Grenzwerten. Er erzählt von Testabdeckungs-Monitoren (die es damals schon gab), nennt einige Test-Tools, TDD und einige allgemein akzeptierte Standards.
Das interessantere Material beginnt in diesem Abschnitt jedoch mit dem Kapitel über Refactoring. Ein weiteres Beispiel eines for-Loops in verschiedenen Sprachen zeigt, wie unterschiedlich dieselbe Konstruktion je nach Programmiersprache Ressourcen verbraucht. Auch der Compilertyp spielt eine große Rolle. Es gibt eine interessante Tabelle, die die relative Leistung von Code in verschiedenen Sprachen zeigt. Zu den Vergleichsbeispielen in C, C++, C#, Java und Visual Basic werden auch PHP und Python hinzugefügt. Besonders oft findet man Leistungsvergleiche gängiger Operationen in C++ und Java. Es ist schwer zu sagen, wie relevant diese Tests heute noch sind, da neue Compiler-Versionen erschienen sind, neue Konstruktionen in den Sprachen hinzugekommen sind und selbst Interpreter, wie z.B. der von PHP, ständig neu geschrieben und optimiert werden. Aber die Botschaft dieses Kapitels ist nicht, die Laufzeit eines bestimmten Algorithmus oder einer Funktion (wie das Finden einer Quadratwurzel) zu vergleichen, sondern dass derselbe Code (eine Funktion) in verschiedenen Sprachen völlig unterschiedlich arbeiten kann (mal langsamer, mal schneller).
Am Ende des Abschnitts gibt es ein Beispiel dafür, wie die Änderung von Datentypen auf passendere die Geschwindigkeit eines Algorithmus beeinflussen kann (wiederum anhand von Beispielen in verschiedenen Sprachen).
Systemfragen
Der Abschnitt besteht aus folgenden Kapiteln:
- Wie die Programmgröße die Konstruktion beeinflusst
- Management der Konstruktion
- Integration
- Programmierwerkzeuge
Was ist hier interessant? Zum Beispiel wird das Thema behandelt, wie die Teamgröße die Effizienz beeinflussen kann, und es wird der ungefähre Anteil der Programmierer am geschriebenen Code in Abhängigkeit vom Team aufgelistet. Es wird beschrieben, wie die Projektgröße in Codezeilen ungefähr mit der Fehlerrate korreliert. Vielleicht sind die Diagramme und Tabellen etwas umstritten, aber es lohnt sich, darüber zu lesen. In erster Linie würde ich diesen Abschnitt sogar Managern zum Lesen empfehlen.
Insgesamt ist der Abschnitt theoretisch und enthält kaum Code. Außerdem wird das Thema der sich ändernden Anforderungen im Verlauf eines Projekts und deren Einfluss auf den Projektfortschritt angesprochen. Es werden auch die Hauptfaktoren aufgelistet, die sich auf die Geschwindigkeit auswirken können und die mit den Programmierern und dem Team zusammenhängen. Zu diesen Faktoren zählt der Autor:
- Erfahrung und Fähigkeiten des Programmierers;
- Motivation des Teams;
- Qualität des Managements;
- Menge des wiederverwendeten Codes;
- Fluktuation der Mitarbeiter;
- Variabilität der Anforderungen;
- und andere.
Es wird das Thema der Beziehung und der Kommunikation mit Programmierern angesprochen. Zum Beispiel, wie Programmierer ihre Zeit verbringen. Das Thema Burnout war also schon damals aktuell. Außerdem wird hier ein weiteres Thema erwähnt, das sich mit sogenannten „Glaubensfragen“ beschäftigt — wie die Wahl der IDE, Benennung und Codestil, Verwendung von Lintern und Ähnlichem.
Es wird das Thema Integration diskutiert — schrittweise und inkrementelle, T-förmige und einige andere. Die Vor- und Nachteile jeder Methode werden beschrieben. Das Material ist jedoch ziemlich umstritten, da moderne CI/CD-Ansätze überhaupt nicht erwähnt werden.
Die Kunst des Programmierens
Zusammenfassend ist dies ein allgemeiner Abschnitt des Buches, der viele andere Bereiche umfasst und auf bereits gelesene Abschnitte verweist. Es werden allgemeine Ratschläge präzisiert, es gibt viele Codebeispiele — von der Platzierung von Kommentaren bis zur Arbeit mit Klassen und Methoden. Ich würde nicht sagen, dass dieser Abschnitt als Fazit des gesamten Buches verstanden werden sollte — eher als Ergänzung zu den vorherigen. Der Abschnitt endet mit moralischen Empfehlungen des Autors, etwa wie man Faulheit, Sorgfalt und andere Eigenschaften betrachten sollte. Am Ende gibt es eine riesige Literaturliste, was zumindest auf einen professionellen Ansatz beim Schreiben des Buches und dessen gründliche Ausarbeitung hinweist.
Fazit
Dieses Buch hat fast 900 Seiten, aber lassen Sie sich davon nicht abschrecken, denn das darin dargestellte Material ist meiner Meinung nach sogar deutlich besser als das von Robert Martin. Nennen wir die wichtigsten Vor- und Nachteile des Buches.
Nachteile:
- Das Buch ist riesig und nicht jeder wird in der Lage sein, es komplett zu lesen.
- Das Erscheinungsjahr ist nicht das aktuellste, daher könnten einige Beispiele und Themen veraltet sein. Zum Beispiel gibt es keine Erwähnung einiger moderner Programmiersprachen, und die heutigen Ansätze für das Deployment von Anwendungen und die Softwareentwicklung haben sich bereits erheblich verändert.
Vorteile:
- Ausgezeichnete und verständliche Struktur.
- Leicht zu lesen.
- Am Ende jedes Kapitels gibt es eine kurze Zusammenfassung mit den wichtigsten Punkten.
- Oft werden Beispiele für schlechten Code gezeigt, die anschließend zu gutem Code verbessert werden.
- Code wird in verschiedenen Sprachen präsentiert, zudem gibt es Vergleiche von Algorithmen in verschiedenen Sprachen.
Das Buch ist definitiv gut. Ich würde sagen, es ist eines der besten theoretischen Bücher über Programmierung, das sowohl für Anfänger als auch für erfahrene Entwickler lesenswert ist.
