Von der Kunst, guten Code zu schreiben

Die Qualität des Codes hat einen Einfluss darauf, ob eine Software effizient entwickelt, fehlerfrei genutzt und gewartet werden kann. Andernfalls steigt die Fehleranfälligkeit, was den Aufwand für Wartung und Fehlersuche in die Höhe schnellen lässt. «Wer am Anfang des Projekts in die Codequalität investiert, wird am Ende viel Zeit eingespart haben», sagt dazu Marco Ravicini, Senior Software-Architekt bei bbv.

Um qualitativ guten Code erzeugen zu können, halten sich viele Entwicklerinnen und Entwickler an die SOLID-Prinzipien. Diese helfen, die Wartbarkeit von Code zu erhöhen und somit länger lebende Software zu schreiben. SOLID ist ein Akronym, es steht für ein Subset der Prinzipien des objektorientierten Designs (OOD) und stammt von Robert C. Martin, der diese bereits vor rund 20 Jahren erstmals erwähnte [1]:

Single-Responsibility-Prinzip (Prinzip der eindeutigen Verantwortlichkeit)

Open-Closed-Prinzip (Prinzip der Offenheit und Geschlossenheit)

Liskovsches Substitutionsprinzip

Interface-Segregation-Prinzip (Prinzip der Schnittstellentrennung)

Dependency-Inversion-Prinzip (Abhängigkeit-Umkehr-Prinzip)

Zur Erläuterung von SOLID:

• Single-Responsibility-Prinzip: Jede Softwareeinheit soll eine einzige Aufgabe übernehmen. Auf diese Weise sollen zukünftige Änderungen vereinfacht werden.
• Open-Closed-Prinzip: Softwareeinheiten sollen offen für Erweiterungen, aber geschlossen für Modifikationen sein. Durch Vererbung von Eigenschaften können Funktionalitäten zwar erweitert, aber nicht grundlegend verändert werden.
• Liskovsches Substitutionsprinzip: Abgeleitete Klassen sollten sich so verhalten wie die Basisklasse, ohne von unerwartetem Verhalten überrascht zu werden.
• Interface Segregation-Prinzip: Interface-Aufteilungen sollen gemäss der Anforderung der Clients gemacht werden. Ein Client soll nicht gezwungen werden, von Interfaces abzuhängen, die nicht benötigt werden.
• Dependency-Inversion-Prinzip: Die Flexibilität im System soll gewährleistet werden, indem höhere Klassen nicht direkt von tieferen Klassen abhängig sind.

Kritik an SOLID

Die SOLID-Prinzipien scheinen aber nicht über alle Zweifel erhaben zu sein. Daniel Terhorst-North übte 2017 mit seinem Talk «Why Every Single Element of SOLID is wrong» Kritik an SOLID und erntete damit viel Zustimmung, aber auch Kritik. Zwar war seine eher spontane, launig formulierte Präsentation durchaus ernst gemeint, doch wurden seine Thesen in den Sozialen Medien mitunter auch dahingehend wiedergegeben, dass SOLID völlig ausgedient habe. Terhorst-North wollte sich aber keinesfalls so verstanden wissen. Vielmehr lautet seine Kernaussage: Die SOLID-Prinzipien sind nicht falsch, doch sie sind zu vage, als dass sie einem als Entwickler gut unterstützen. Deshalb war sein damaliger Ratschlag ultrakurz: «Write simple code!». [2] «Damit hat er natürlich recht», sagt Marco Ravicini, «doch hilft einem Entwickler dieser Tipp auch nur bedingt weiter. Denn die Frage ist: Wie entsteht einfacher Code?»

CUPID als Nachfolger von SOLID?

Daniel Terhorst-North beliess es indes nicht bei einer Kritik an SOLID. Vielmehr erhielt er eine Einladung zur Craft Conf 2021, um dort seine eigenen Prinzipien vorzustellen. Die Herausforderung, die ihm gestellt wurde, lautete: «Wenn du heutzutage Prinzipien für moderne Softwareentwicklung geben könntest, welche würdest du wählen?» Terhorst-North entwickelte daraufhin die CUPID-Eigenschaften. Er spricht bei CUPID bewusst nicht von «Prinzipien», sondern von «Eigenschaften» oder «Zielen», an die man sich annähert und die den Code für Menschen eingängig machen – und somit das Programmieren «joyful» werden lassen. Hier seine Erläuterungen:

Prinzipien sind Regeln oder Richtlinien

• Sie definieren Konditionen oder Grenzen
• Code entspricht entweder diesen Regeln oder er ist falsch (er verletzt sie)

Eigenschaften sind Qualitäten oder Charakteristiken

• Sie definieren ein Ziel oder ein Zentrum, zu dem man gehen möchte
• Code ist entweder näher am Ziel oder weiter weg

Passend dazu setzt er das Zitat von Martin Fowler: «Any fool can write code that a computer can understand. Good programmers write code that humans can understand.» Daniel Terhorst-North generiert mit «CUPID – for joyful Coding» eine Sammlung an Eigenschaften mit Fokus auf den Menschen – sprich: auf die Person, die den Code entwickelt.

Composable – plays well with others

Unix philosophy – does one thing well

Predictable – does what you expect

Idiomatic – feels natural

Domain-based – in language and structure

Diese fünf Eigenschaften beinhalten Ziele oder erweiterte Eigenschaften für guten Code. Marco Ravicini erläutert diese Eigenschaftensammlung folgendermassen:

Composable: Guter Code hat eine kleine «Oberfläche»: Von aussen sind nur jene Teile sichtbar, die für Entwickler relevant sind. So wird die Verwendung des Codes möglichst einfach gehalten. Es kann weniger schiefgehen, es entstehen weniger Konflikte, etwa bei Änderungen und Verschiebungen. Somit ist die Intention des Codes offensichtlich. Mit eindeutig definierten Schnittstellen ist er einfacher zu lernen und zu verwenden.

Unix philosophy: Guter Code sorgt dafür, dass ein Programm/Modul/Klasse/Funktion nur genau eine Aufgabe macht – diese dafür gut.

Predictable: Der Code verhält sich wie erwartet und ohne Überraschungen. Er ist deterministisch in der Ausführung und ist beobachtbar im technischen Sinne. Sein interner Status kann von den Outputs abgeleitet werden, ist aber nicht veränderbar.

Idiomatic:  Der Umgang mit gutem Code soll sich natürlich anfühlen. Es werden die Idiome des Kontextes (Domäne, Firma, Team) sowie des Ökosystems der Sprache, in der er geschrieben ist, verwendet.

Domain-based: Für guten Code wird die Domänensprache und deren Struktur verwendet.  Die Struktur des Codes soll die Lösung widerspiegeln und nicht das darunterliegende Framework oder die eingesetzten Konzepte. Anstatt technischer Konzepte (Models, Views, Controllers) werden Domänenbegriffe (Dokumente, Zahlungen) verwendet. Dabei sollen die Domänengrenzen als Modulgrenzen und Deployment-Units beachtet werden.

CUPID ist kein Ersatz für SOLID, sondern eine Bereicherung

Die CUPID-Eigenschaften sollen die SOLID-Prinzipien nicht konkurrenzieren und sie auch nicht obsolet machen. «Sie sind lediglich eine neue Art, guten Code zu beschreiben», erklärt Marco Ravicini. «Hoffentlich werden die Eigenschaften von der Entwickler-Community auch so aufgenommen und nicht als ‹SOLID ist tot, lange lebe CUPID› aufgefasst», sagt er weiter.  Marco Ravicini erachtet CUPID als sehr hilfreich, da es die zielorientierten Eigenschaften erleichtern, guten von schlechtem Code zu unterscheiden. Das fördere einen zielorientierten Dialog unter den Entwicklern und führe dazu, alles zu unternehmen, damit man näher an die Ziele herankommt.

Trotz CUPID sind die SOLID-Prinzipien also nicht out-of-date, vielmehr bleiben sie nach wie vor gültig, sagt Marco Ravicini. «CUPID gibt uns lediglich eine Alternative und eine neue – eventuell freundlichere – Sicht auf guten Code.» Als Verweis darauf, dass der Begriff «Cupid» auch eine Bezeichnung des römischen Liebesgotts Amor ist, fordert er die Community auf: «Nutzt CUPID und bringt ein bisschen Liebe in euren Code!»

Referenzen:

[1] Martin, Robert C. (2000). «Design Principles and Design Patterns» (PDF). Archived from the original (PDF) on 2015-09-06.

[2] Dan North. CUPID – The back story.