equilibrium/resources/page/blogs/blag/entries/03-solid-vs-stable.md

---
{:title "Solid vs Stable"}
---

# Ü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.

<blink>

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.  **S**ingle responsibility principle  
    Eine Komponente sollte genau eine Zuständigkeit besitzen.
2.  **O**pen closed principle  
    Komponenten sollten offen für Erweiterungen, aber geschlossen für Veränderungen sein.
3.  **L**iskov substitution principle  
    Objekte sollten durch Instanzen ihrer Kinder ersetzbar sein, ohne die Korrektheit des Programms zu beeinflussen. Benannt nach Barbara Liskov.
4.  **I**nterface segregation principle  
    Ein Objekt sollte nicht gezwungen sein, Schnittstellen zu besitzen, die es nicht benötigt.
5.  **D**ependency 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.  **S**mell 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.  **T**iny 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.  **A**ugment 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.  **B**ack 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.  **L**eave 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.  **E**xpect 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](https://speakerdeck.com/sarahmei/is-your-code-too-solid-with-transcript).