Als Software-Entwickler oder Software-Designer steht man vor der Aufgabe, mit Code zu arbeiten, der von möglichst vielen anderen Entwicklern und Designern verstanden werden können soll. Das schließt den ursprünglichen Autor mit ein, wenn er unter Umständen Jahre danach den Code wieder selbst bearbeitet. Zu rund 80% arbeiten Entwickler mit bestehendem Code und stehen oft vor dem Problem, dass sie ihn nicht (auf Anhieb) verstehen. Das hat unterschiedliche Ursachen:
- Der Quellcode wurde über die Zeit immer wieder unter Umständen von unterschiedlichen Entwicklern ergänzt,
- und er hat unter Umständen unter den vielen verschiedenen Stilen gelitten.
- Durch debugfixing wurde der Code immer nur an lokal mit geringem scope gefixt, ohne das große Ganze zu sehen.
Das realisiert sich dann durch unleserlichen Code oder in einer Software-Architektur, die beide als Vorlage für sogenannte Antipatterns dienen können. Antipattern begegnen uns in zweierlei Hinsicht: Im Kleinen im Code in Form von unverständlichen Bezeichnern, Sprach-Konstrukten oder Code-Strukturen. Im Großen in einer Architektur, die schwer zu verstehen ist und aber auch eine Pflege, Ergänzung oder Fehlerbeseitigung erheblich erschwert.
Inhalt
1. Antipattern
Code Antipattern
Beispiele für Antipattern im Kleinen finden sich auf der Website https://github.com/droogans/unmaintainable-code. Die durchaus realistischen Beispiele dort wecken auf und sollen Anstoß geben, es in Zukunft besser zu machen.
Architektur-Antipattern
Beispiele für Architektur-Antipattern sind
- big ball of mud: keine erkennbare Architektur
- gas factory: unnötig komplexe Entwürfe
- god object: ein Objekt, das zu viel weiß/macht
- inner plattform effect: durch weitreichende Konfigurationen wird eine schwache Kopie der Plattform erreicht;
- spaghtetticode: kompakte Struktur, viele Sprungbefehle, monolithischer Block
- sumo marriage: ein fat client ist stark von der Datenbank abhängig
Weiter Informationen hierüber findet sich auf Wikipedia oder bei sourcemaking.
2. Wert einer Software
Um die Bedeutung von Antipatterns richtig einordnen zu können, muss man sich den Wert einer Software vor Augen führen. Ich gehe hierbei davon aus, dass die Software professionell produziert wird vor einem ernsten betriebswirtschaftlichem Hintergrund.
Für wen ist der Wert einer Software wichtig?
- Die Firma oder die Person, die die Software verkauft (und auch noch in Zukunft verkaufen möchte), hat ein betriebswirtschaftliches Interesse für eine möglichst hochwertige Software.
- Der Benutzer, der Lizenznehmer und der Käufer einer Software hat sich auf diese eingelassen. Er hat eventuell ganze Prozesse und das Wissen bei sich und den Angestellten darauf ausgerichtet. Ein Wertverlust wäre für ihn meist fatal.
- Der Entwickler, der die Software programmiert hat, hat nicht nur ein Interesse am Wert der Software, weil er von den beiden ersten Gruppen abhängig ist, sondern auch weil er sich selbst auf Technologien eingelassen hat, die eng mit der Software verbunden sind. Ein Wechsel derselben ist auch für ihn mit Aufwand verbunden.
Aufwand
Der Wert einer Software errechnet sich nicht aus der Formel
Wert der Software = Anzahl der aufgewendeten Mann-Stunden * Stunden-Lohn
Mit der Formel wird lediglich der Aufwand berechnet, der mittels Arbeitsleistung in die Software investiert wurde. Dieser entspricht nicht dem gegenwärtigen Wert der Software, wie er für die genannten Interessensgruppen von Bedeutung ist.
Der Wert der Software
- ...misst sich unter anderem an dem finanziellen Erlös für die Bereitstellung der Software.
- ...wird bewertet mit der Frage: Kann die Software an zukünftige Anforderungen angepasst werden?
- ...und mit der Frage: Steht der Aufwand hierfür in einem gesunden Verhältnis zum Ertrag?
3. Fazit
Ist der Programm-Code schlecht lesbar und nicht verständlich, ist die Architektur schwer zu pflegen, so ...
- ...ist die Software weniger wert, und
- ...macht es weniger Spaß, diese zu programmieren.
Bemühen wir uns also nicht darum, Antipattern zu vermeiden, tragen wir dazu bei, Software zu produzieren, die weniger Wert ist. Dadurch gefährden wir nicht nur uns selbst, sondern auch viele andere, die in einem engen abhängigen Verhältnis zu der Software stehen.
Datum 13.11.2016 / Text Thomas Steglich / Photo / Artikel als PDF ( KB) / tweet Artikel / feedback Formular.