Mit __BUZZWORD__ wird endlich alles gut!

2 minute read Published:

Gute, wartbare Software zu schreiben ist hart. Die Prinzipien dies zu erreichen gibt es jedoch länger als ich lebe. “Separation of Concerns” taucht wohl zum ersten mal 1974 in Edsger W. Dijkstras Paper “On the role of scientific thought” auf. Kohäsion und Kopplung wurden von Larry Constantine in den späten 60ern als Teil von Strukturiertem Design. In den letzten Jahrzehnten beschäftigen wir uns vor allem damit, wie wir diese Prinzipien am besten umsetzten. Sei es durch Funktionale, Objektorientierte oder Modulare Programmierung oder Serviceorientierung.

Seitdem führen wir einen alljährlichen Tanz auf, welche neue Form der Abstraktion endlich zu wartbarer und skalierbarer Software führt. Sicherlich haben sie alle irgendwo ihre Daseinsberechtigung. Letztlich wird jedoch jeder evolutionäre Schritt dazu missbraucht zu argumentieren warum man vorher keine wartbare Software schreiben konnte. Wartbare Monolithen sind nicht möglich, es geht nur mit Serviceorientierung. Aber das ist dann auch nicht das Wahre, es sollten Microservices sein oder noch besser Function as a Service (FaaS).

Die Wahrheit ist jedoch, dass wenn man nicht in der Lage ist diese Prinzipien in einem Monolithen umzusetzen, man auch keine wartbare Software auf Grundlage von Microservices erreichen will. Wenn ich nicht in der Lage bin meinen Code mit Hilfe von Modulen oder Klassen in einzelne Komponenten aufzuteilen, die eine geringe Kopplung untereinander haben und für einen Bereich zu ständig sind, wie will ich dann Services schneiden? Natürlich haben diese weiteren Vorteile, wie einfachere Skalierbarkeit und die Wiederverwendung von Logik zwischen mehreren Systemen, aber dies ist nur selten wirklich das Problem. Und wenn ich bereits einen gut durchdachten Monolithen gebaut habe, sollte es auch kein Problem sein hier einen Teil als Service herauszutrennen.

Ich habe das Gefühl, dass sich ein Großteil der Branche gerne selbst belügt. Man stürzt sich auf das nächste große Buzzword, um sich nicht damit auseinandersetzen zu müssen, dass man es nicht hinbekommt das Problem mit vorhandenen Mitteln zu lösen. Wenn der Versuch dann auch scheitert ist wieder die Technologie schuld und die nächste Zug da auf den man aufspringen kann. Es wird aber nicht dazu führen, dass wir wirklich bessere Software schreiben. Es bleibt immer nur ein dreiköpfiger Affe, der vom wirklichen Problem ablenkt.