Über die Wartung von Code: S.O.L.I.D. oder S.T.A.B.L.E.

Erklärtes Ziel der objektorientierten Programmierung ist bekanntermaßen, die reale Welt mit Objekten nachzustellen. Objekte stellen dabei meist Sammlungen von Eigenschaften dar, die Fähigkeiten besitzen. Dass, und warum, bei der Umsetzung eines solchen Objektmodells einiges schiefgehen kann, muss man sicherlich niemandem erklären.

Um dieser Tendenz entgegenzuarbeiten, es wird an der Stelle auch gerne von Erosion gesprochen, wurden von Robert C. Martin fünf Prinzipien für ein gutes objektorientiertes Design entwickelt, die jeder Programmierer kennen sollte. Zusammengefasst werden sie als SOLID:

1. Single responsibility principle Eine Komponente sollte genau eine Zuständigkeit besitzen.
2. Open closed principle Komponenten sollten offen für Erweiterungen, aber geschlossen für Veränderungen sein.
3. Liskov substitution principle Objekte sollten durch Instanzen ihrer Kinder ersetzbar sein, ohne die Korrektheit des Programms zu beeinflussen. Benannt nach Barbara Liskov.
4. Interface segregation principle Ein Objekt sollte nicht gezwungen sein, Schnittstellen zu besitzen, die es nicht benötigt.
5. Dependency inversion principle Abstrakte Objekte sollten nicht von konkreten abhängig sein.

Diese fünf Prinzipien, so man sie denn korrekt befolgt, führen zu einem prinzipiell wartbaren und gut verständlichem Softwareprojekt. Nun ist es allerdings so, dass es einen weiteren Grundsatz gibt:

Software wird öfter gelesen als ausgeführt.

Das bedeutet, dass in die Wartung großer Projekte sehr viel Zeit reinfießt; und weil Wartung viel Geld kostet und die User sich an ihre Software gewöhnt haben und, und, und... starten Projekte selten auf der sprichwörtlichen grünen Wiese, fangen also selten bei 0 an. Das beudetet, man findet oftamls über Jahre gewachsene Strukturen vor, die unter den verschiedensten Faktoren entwickelt wurden und von Entwicklern verschiedensten Könnens gewartet werden.

Was das mit SOLID zu tun hat? Die oben genannten Prinzipien sind sehr grundlegende, tiefgreifende architektonische Richtlinien. Es bedeutet viel Aufwand sowohl in Sachen Programmierung als auch Testen, ein Dependency inversion principle in ein Projekt einzubauen, das bereits seit fünf Jahren prima ohne auskommt. Wie schon an der Formulierung zu erkennen ist, ist der Mehrwert oftmals auch zweifelhalt gering. Woran soll man sich nun also halten, was ist die Mao-Bibel des Legacy-Entwicklers?

Die Softwareentwicklerin Sarah Mei aus den USA schlug für die Wartung von bestehender Software eine andere Abkürzung vor, STABLE:

1. Smell your code Wie man an einem Wein zuerst riecht, soll man sich mit der Codebasis, an er man arbeiten soll, vorher vertraut machen. Was sind bekannte Probleme, was kann man schnell verbessern?
2. Tiny problems first In gewachsenen Projekten gibt es viele Probleme, vieles riecht. Statt den großen Umbau, mit dem man erst Tage später vielleicht fertig ist, zu starten, sollte man die kleinen Probleme zuerst angehen. Erst wenn man die ganzen kleinen Ärgernisse beseitigt hat, kann man das große Ganze korrekt einschätzen.
3. Augment tests Bevor man große Komponenten anfasst und von Problemen bereinigt, muss man das korrekte Verhalten definieren und mit automatischen Tests validieren. Erst dann kann man sicher Korrekturen vornehmen.
4. Back up Sind Objekte zu abstrakt und Funktionen zu verkapselt, sollte die Codebasis erstmal in eine einfachere Form, beispielsweise prozedural, gebracht werden. Danach kann man sich um all die Duplikationen und Kapselungen kümmern und so ein neues Design entwerfen.
5. Leave it better than you found it Auch unter dem Namen Pfadfinderregel bekannt. Code, den man verwüstet vorfindet, aber an dem man nicht unbedingt Änderungen vornehmen muss, sollte man trotzdem aufräumen und so für den nächsten Entwickler, vielleicht man selbst, besser hinterlassen.
6. Expect good reasons Man sollte immer davon ausgehen, dass Entwickler gute Gründe für das haben, was sie tun. Vielleicht steckt hinter abstrusen Konstruktionen ein tieferer Sinn oder eine Funktion, die man so nicht erahnt hätte. Außerdem ist es gut für die Teammoral, wenn man nicht sofort seinen Kollegen anschimpft, warum Code aussieht, wie er es tut.

Vielleicht können mehr Entwicklerteams diese Prinzipien beachten, wenn sie es mal wieder mit urtümlichen Code nach alter Väter Sitte zu tun haben. Die Folien, inklusive Transkript, des hervorragenden Vortrags, von dem ich diese Informationen habe, sind hier zu finden: Speakerdeck.