Die fünf SOLID-Prinzipien kennen Sie seit Lektion 1.4.6, an kleinen Beispielen mit einem Vorher und einem Nachher. In Lektion 2.10.4 haben Sie sie im Alltag wiedergesehen, an der Frage, was sich ändert, wenn die Kladde ins Web zieht. Dieses Modul erklärt die Prinzipien nicht noch einmal. Es geht den umgekehrten Weg: vom Code aus, den Sie in den letzten Modulen selbst geschrieben haben, und der ist inzwischen groß genug, um weh zu tun.
Jede Lektion dieses Moduls hat denselben Aufbau. Sie beginnt mit einem Geruch im echten Code der Kladde. Ein Charakterisierungstest hält fest, was der Code heute tut. Dann folgt der Umbau in kleinen Pull Requests, danach eine Messung, die den Gewinn belegt, und zum Schluss die Frage, wann man es nicht macht. Diese Lektion legt den Grund: Sie lernen die Gerüche kennen, finden sie in Ihrer Kladde und setzen die Tests, bevor irgendjemand umbaut.
Ein Prinzip ist ein Werkzeug gegen einen Schmerz
Ein häufiger Fehler beim Lernen von SOLID: Man liest die Prinzipien, findet sie einleuchtend und baut ab sofort für jede Klasse eine Schnittstelle, zerlegt jede Methode und plant Erweiterungspunkte für Dinge, die nie kommen. Der Code wird nicht besser, nur länger.
Die Regel dieses Moduls lautet deshalb: Ein Prinzip ist ein Werkzeug gegen einen Schmerz, kein Ziel. Der Schmerz ist konkret. Eine kleine Anforderung zwingt Sie, fünf Dateien anzufassen. Ein Test braucht eine Datenbank, obwohl er eine Regel prüft. Eine Testattrappe muss zwanzig Methoden haben, von denen der Test eine braucht. Wo es nicht weh tut, gibt es nichts zu reparieren.
Den Schmerz zeigt oft schon der Code selbst, bevor die nächste Anforderung kommt. Solche Anzeichen heißen Code-Gerüche, ein Begriff aus der Literatur zum Refactoring. Ein Geruch ist kein Fehler. Er ist ein Hinweis, dass hier etwas faul sein könnte, und ein Anlass, genauer hinzusehen.