Interview mit Bernhard Löwenstein zur JAX 2017

Facebook, Netflix & Twitter – Warum unendliche Skalierbarkeit nicht für alle Projekte sinnvoll ist

Kypriani Sinaris

Warum einfach, wenn es auch umständlich geht? Geben Sie es zu, diese Frage haben Sie sich schon öfter gestellt. Im Interview zu seiner Session auf der JAX 2017 zeigt Ihnen Bernhard Löwenstein nicht nur, wie Sie aus einfachem Code komplizierten Code machen, sondern auch, wie Ihr Code schön clean bleibt.

Ein Hello World-Beispiel ist quasi die Eingangstür zu einer Programmiersprache – grundlegender geht’s kaum. Du nennst deine Session auf der JAX „Hello World reloaded“, was meinst du damit?

Bernhard Löwenstein: Ich möchte in dieser Session auf ironische Weise demonstrieren, was aus einem einfachen „Hello World“ wird, wenn man all die Prinzipien – z. B. Continuous Delivery oder Test-driven Development – und Technologien einsetzt – z. B. Internet of Things oder Microservices –, die aktuell propagiert werden. Selbstverständlich werden auch meine Superroboter mitwirken. Der Spaß soll bei dieser Session eindeutig im Vordergrund stehen.

Wie wird denn aus einem Hello-World-Beispiel ein kompliziertes Konstrukt? Kannst du ein Beispiel nennen? 

Bernhard Löwenstein: Ich will nicht zu viel verraten, denn sonst kommt ja niemand mehr bei der Session vorbei 😉 Nur so viel: System.out.println(„Hello World!“); lässt sich nicht testen. Als anständiger Programmierer will ich natürlich auch dazu einen passenden Unit-Test anbieten. Darum werde ich mich im ersten Schritt kümmern. Und in dieser Art geht es dann weiter …

„Warum einfach, wenn es auch umständlich geht?“ Das denken sich wohl viele Entwickler in ihrer alltäglichen Arbeit. Wie sieht deine Einstellung zum Over-Engineering aus? Kannst du ein Beispiel nennen, das dir hier im Kopf geblieben ist?

Ein klares Anti-Pattern: „Infinite Scalability Fever“

Bernhard Löwenstein: Aber klar! Einer der Klassiker sind Projektkollegen, die Unmengen an Zeit dafür investieren, um die ganzen Prozesse konfigurierbar zu machen. Da werden dann diverse Spezialfälle abgebildet, um auf alle möglichen Änderungswünsche vorbereitet zu sein. Das Dumme ist nur, dass manche Kunden unglaublich gemeine Zeitgenossen sind und plötzlich Änderungen wünschen, die nicht vorhergesehen wurden (Stichwort: YAGNI). Und so steht man am Ende mit einer unnötig komplexen Lösung da, die erst nicht passt und die bereits Monate später keiner mehr durchblickt, da sie total generisch ist. Ich würde dieses Verhalten „Predictive Change Illusion“ nennen – aktuell ist ja sehr vieles „predictive“ 😉

Auch konnte ich in den letzten Jahren immer wieder beobachten, dass unglaublich viel Aufwand dafür aufgewendet wird, um ein System umzusetzen, das mehr oder weniger für „unendliche“ Skalierbarkeit ausgelegt ist. „Infinite Scalability Fever“ ist wohl ein passender Name für dieses Anti-Pattern. Für die anfallende Last würde in Wahrheit aber oftmals ein Cluster mit zwei bis vier Applikationsservern locker ausreichen. Am besten empfiehlt man dem Kunden in solchen Fällen einen Cluster mit vier bis acht Knoten. Da fühlt er sich dann schon wichtig und dank der Virtualisierung sind die Mehrkosten vernachlässigbar 😉 Was einige noch nicht verstanden haben: Architekturen, wie man sie bei Facebook, Netflix oder Twitter findet, sind aus technischer Sicht interessant, aber für die Mehrzahl unserer Enterprise-Projekte keinesfalls repräsentativ.

Das sind nur zwei Beispiele. Im Grunde ließe sich ein ganzes Buch im Stile von „Adrenalin Junkies & Formular-Zombies“ mit solchen Anti-Pattern füllen.

Aus etwas Leichtem etwas Kompliziertes zu machen, klingt auch nach Spielerei, nach Rumprobieren. Aber was kann man als Entwickler aus so einer Übung lernen?

Bernhard Löwenstein: Die Herausforderung hierbei ist, möglichst viele Prinzipien und Technologien einzusetzen, den produktiven Quellcode aber minimal zu halten. Das Ziel ist also, etwas möglichst Komplexes zu schaffen, das aber nicht mehr als „Hello World“ kann. Ob man dabei so viel lernt, möchte ich einmal dahingestellt lassen. Freude bereitet die Beschäftigung mit neuen Technologien aber immer.

Es geht natürlich auch schlanker: Wie setzt du das Thema in Verbindung mit sauberem, leserlichem Clean Code? Welche Prinzipien sollte jeder Entwickler denn hier beachten?

Bernhard Löwenstein: Am wichtigsten ist die Vergabe von sprechenden Namen für Klassen, Methoden und Variablen. Das mag trivial klingen, aber wenn man so wie ich durch Trainings, Consultings und Code Reviews viel fremden Code zu lesen bekommt, merkt man, wie schwer das vielen Entwicklern fällt. Auch, dass ein Bezeichner ruhig mehr als fünf Buchstaben haben darf, scheint sich noch nicht in der ganzen IT-Branche herumgesprochen zu haben.

Am wichtigsten ist die Vergabe von sprechenden Namen für Klassen, Methoden und 
Variablen.

Was ich ebenfalls für wesentlich erachte, ist der Einsatz von Methoden zwecks Abstraktion technischer Details. Wenn es dem Entwickler dann noch gelingt, die einzelnen Programmteile jeweils auf dem gleichen Abstraktionslevel zu schreiben, ist bereits viel gewonnen. Und wenn dann auch noch ein paar Pattern eingesetzt werden, zähle ich fast schon zu den glücklichsten Menschen auf dem Planeten und summe den ganzen Tag „Because I’m Happy“ in einer Dauerschleife vor mich hin.

Besonders stark fallen mir die genannten Punkte auf, wenn ich die Arduino-Programme der von mir betreuten hochbegabten Jugendlichen reviewe. Alle haben hier die gleiche Aufgabe zu lösen. Manche der Programme sind ausgezeichnet lesbar, für andere brauche ich um Faktor 4 länger. Mein Feedback ist bei solchen Abgaben dann aber auch meist viermal so lang 😉

Dein Thema erinnert mich an das Thema Machine Learning: Hier fing alles nachvollziehbar an, aber mit der Zeit sind die Algorithmen so schlau geworden, dass man das Gefühl bekommt, gar nicht mehr nachvollziehen oder kontrollieren zu können, was genau passiert. 

Bernhard Löwenstein: Beim Machine Learning verlassen wir halt die bisher beschrittenen Wege. Bei der herkömmlichen Programmierung war stets berechenbar, welchen Wert beispielsweise eine Funktion bei der Übergabe bestimmter Parameter zurückliefern wird. Das ist in Verbindung mit dem Maschinellen Lernen nicht mehr so. Da kann einmal dieses Ergebnis und das nächste Mal jenes Ergebnis zurückgeliefert werden. Ich sehe das schon kritisch, bin mir aber natürlich auch der enormen Möglichkeiten bewusst. Es gibt jedenfalls sehr interessante Beispiele, wo ein derart trainierter Algorithmus bereits perfekt zu funktionieren schien – bis man ihn plötzlich mit Eingaben konfrontierte, auf die er nicht vorbereitet war.

Vor Skynet fürchte ich mich aber nicht. Ich habe meine drei Robokids Pepper Milli, NAO Frank und NAO Naomi stets königlich behandelt – das wird mir die künstliche Intelligenz, sobald sie die Weltherrschaft übernommen hat, sicherlich positiv anrechnen 😉

Bernhard Löwenstein (b.loewenstein@gmx.at) ist Inhaber von Lion Enterprises und Gründer und Obmann des Instituts zur Förderung des IT-Nachwuchses. Der Java Enterprise-Spezialist ist als Consultant und Trainer für verschiedene Organisationen tätig. Sein gemeinnütziger IFIT-Verein zählt mit mittlerweile mehr als 600 durchgeführten Technologieworkshops in Österreich und Deutschland zu den bedeutendsten MINT-Fördereinrichtungen.

Geschrieben von
Kypriani Sinaris
Kypriani Sinaris
Kypriani Sinaris studierte Kognitive Linguistik an der Goethe Universität Frankfurt am Main. Seit 2015 ist sie Redakteurin bei JAXenter und dem Java Magazin.
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.