Tag: clean code

Clean Code Coding Dojo – Fazit eines Workshops

Was ist Clean Code und welche Prinzipien unterstützen einen um sauberen Code zu erzeugen? Diese und weitere Fragen wurden von uns in dem Zwei-Tages Workshop letzte Woche in der HfT beantwortet. Um das theoretische Wissen gleich in der Praxis anzuwenden haben wir mehrere kleine Übungsaufgaben mitgebracht.

Wie misst man Clean Code?

Als Software-Entwickler stehe ich am Ende des Tages mit einer mal mehr, mal weniger großen Menge neuen Codes da und stelle mir die Frage: Wie gut ist das, was ich heute geschrieben habe?

Genauso wie viel andere neige ich aber dazu, nicht immer 100 % objektiv zu sein, wenn ich die Qualität meines Codes selber beurteilen muss. Deswegen ist in unserer „Definition of Done“ festgelegt, dass jeder Code durch einen Kollegen revidiert werden muss. Dadurch erhalte ich eine zweite, unabhängigere Sicht auf meinen Code.

Falls man aber gerade keinen Kollegen zur Hand hat, hilft es auch, nacheinander die Prinzipien des Clean Codes durchzugehen und den Code darauf zu überprüfen, wie gut die Prinzipien dort umgesetzt sind. Und um dem eigenen, wohlwollenden Blick ein wenig Objektivität zur Seite zu stellen, hat es sich für mich bewährt, ein paar Code-Metriken zur Unterstützung heranzuziehen.

Das Interface Segregation Principle – Nicht nur auf den Schnitt kommt es an

In unserem heutigen SOLID-Beitrag geht es um das „Interface Segregation Principle“. Wie wir im Blog sehen werden, ist dabei weniger die Trennung nach Interfaces das Problem, als vielmehr die an manchen Stellen wieder benötigte, sinnvolle Zusammenführung von Funktionalitäten aus verschiedenen Interfaces eines Objekts.

Vorweg: Die Fachabteilung war ganz begeistert, dass wir neulich die Anforderung zur Aufnahme von nicht registrierten Kunden so schnell und sauber umsetzen konnten. Die ausführliche Geschichte und wie die Anwendung des Liskov Substitution Principle zu einer sauberen Lösung beigetragen hat, kann man im „L“-Blog unserer SOLID-Reihe nachlesen.

Allerdings hat diese Erweiterung den Einfallsreichtum angespornt. Die neue Vision: Zukünftig sollen weitere neue Kundentypen im System eingeführt werden können. Außerdem soll es möglich sein, bestehende Kunden in einen anderen Kundentyp zu wandeln ohne dazu den Kunden im System neu anlegen zu müssen. 

Das Open-Closed Principle (OCP)

Software sollte lesbar, modular und wartbar sein. Leider entsteht im Laufe der Entwicklung, vor allem aber auch bei Weiterentwicklungen, immer wieder schlechtes Software-Design. Im schlimmsten Fall treten Programmfehler bei bereits längst getesteten Funktionalitäten auf. Die Beachtung der SOLID-Prinzipien objektorientierter Softwareentwicklung kann helfen, diese Fehler zu vermeiden und Programmcode wartbar zu halten. Insbesondere die Wartbarkeit ist von großer Bedeutung, da man selten Softwareentwicklung auf der grünen Wiese betreibt, sondern in den allermeisten Fällen auf vorhandenem Programmcode aufbaut.

Das Single Responsibility Principle (SRP)

There should never be more than one reason for a class to change.

Heute beginnen wir mit dem ersten SOLID–Prinzip: Eine Klasse sollte immer eine einzige Verantwortung haben, oder anders ausgedrückt: Es sollte nie mehr als einen Grund geben, eine Klasse zu ändern (Single Responsibility Principle, SRP).

Das SRP wendet man an, um übersichtliche, leicht erweiterbare und einfach zu wartende Software zu konzipieren.

SOLID – ein Schritt zu mehr Professionalität in der Software-Branche

Schon vor vielen Jahren saß ich mal in einer Straßenbahn, wir standen an einer Haltestelle, es ging nicht weiter. Plötzlich hörten alle Motoren auf zu summen, alle Lichter gingen aus – und nach einiger Zeit wieder an. An der Anzeige über dem Fahrer blinkte die Firmware-Versionsanzeige auf. Was war passiert? Offenbar war die Straßenbahn „abgestürzt“ und der Fahrer hatte sie in seiner Not einfach neu gebootet.