[0:00] Herzlich willkommen zum Anwendungsentwickler Podcast, dem Podcast rund um die Ausbildung

[0:07] zum Fachinformatiker für Anwendungsentwicklung. In dieser Episode gibt es einen Buchclub zu

[0:12] Java by Comparison. Viel Spaß! Hallo und herzlich willkommen zur 130. Episode

[0:24] des Anwendungsentwickler Podcasts. Mein Name ist Stefan Macke und heute habe ich mal wieder

[0:29] einen Buchclub für dich und gleichzeitig auch noch eine Einzelepisode. Heute mal kein Interview.

[0:34] Und das Buch, um das es heute gehen soll, das ist sowohl für Azubis als auch für Ausbilder

[0:39] super interessant. Ich habe das gerade am vergangenen Wochenende komplett durchgelesen

[0:44] in einem Rutsch und gedacht, Mensch, das muss sofort auf meine To-Read-Liste für jeden Azubi

[0:49] und auf jeden Fall auch im Podcast besprochen werden, weil das wirklich ein ganz klasse Buch

[0:53] ist für die Ausbildung, rund um die Ausbildung, wenn man sich bei der Programmierung verbessern

[0:58] will. Meine Azubis und ich lesen aktuell ja auch Clean Code. Das ist natürlich auch so ein

[1:03] Standardwerk, wo man auch viel, viel mitnehmen kann für die Praxis. Java by Comparison geht

[1:09] noch mal einen Schritt weiter, wie ich finde, weil es ganz konkrete Code-Beispiele gibt,

[1:13] an denen man sich verbessern kann. Über dieses Buch möchte ich heute mal ein bisschen sprechen,

[1:18] warum ich das gut finde und warum ich das ab jetzt sofort mit jedem Azubi durchlesen werde,

[1:23] selbst im ersten Ausbildungsjahr. Das ist also gut verständlich und man braucht nicht so viel

[1:28] Promierkenntnisse, um da einsteigen zu können. Von daher, ja, ich würde sagen, wir legen doch

[1:32] einfach mal direkt los. Ich habe das heute mal in ein paar Unterkapitel, sage ich mal,

[1:37] gegliedert. Wir fangen gleich erst mal an mit der Idee des Buchs. Worum geht es überhaupt? Wie ist

[1:40] das grundsätzlich aufgebaut? Dann, was ist die Zielgruppe dieses Buches? Also für wen ist das

[1:45] Buch geeignet? Wer kann das anwenden? Wer vielleicht eher nicht? Dann gehen wir einmal

[1:49] kurz durch den Inhalt des Buches, also welche Teile gibt es, welche groben Kapitel. Und zum

[1:55] Schluss gibt es noch einige konkrete Beispiele, die in dem Buch genannt werden, die ich zum Beispiel

[1:59] persönlich in meinem Alltag schon oft hätte gebrauchen können und jetzt halt habe in Form

[2:04] dieses Buches. Ja, ich würde sagen, fangen wir direkt mal oben an. Was ist die Idee des Buchs?

[2:09] Also erst mal vorweg, das Ding heißt Java by Comparison und der Name leitet sich wohl daraus

[2:14] ab, dass man halt immer Vergleiche von Code hat. Und zwar von, in Anführungszeichen,

[2:19] schlechtem Code und gutem Code. Und die beiden Code-Beispiele stehen immer auf der linken und

[2:24] rechten Seite des Buches, das heißt quasi genau gegenüber. Und man kann direkt vergleichen,

[2:29] was sich am Code ändert, wenn man ihn denn besser macht. Ich fange vielleicht mal mit einem ganz

[2:33] einfachen Beispiel an, dass man sich das grob vorstellen kann. Stellen wir uns vor, das ist

[2:37] auch die erste Regel, die im Buch genannt wird und die ich auch häufig in der Praxis sehe. Wir

[2:41] haben eine if-Abfrage und fragen darin einen Boolchen-Wert ab, eine Variable zum Beispiel

[2:46] vom Typ Boolean. Dann könnten wir sowas schreiben, if Variable gleich gleich true. Oder wir schreiben

[2:53] einfach if Variable, denn Variable ist ja selber schon ein Bool und ich muss das nicht mehr mit

[2:58] true oder false vergleichen. Und das ist auch gleich die erste Regel. Auf der linken Seite

[3:03] steht Code, in dem sowas gemacht wird, wie gleich gleich true, gleich gleich false,

[3:06] ungleich false, was auch immer. Und auf der rechten Seite steht quasi genau der gleiche

[3:10] Code, bloß ohne diese völlig unnötigen Vergleiche. Und das Schöne ist jetzt,

[3:14] dass auf dem Rest der zwei Seiten genau erklärt wird, warum das linke Beispiel

[3:19] schlecht ist, in Anführungszeichen, oder weniger gut, sagen wir mal so. Und auf der rechten Seite

[3:24] natürlich auch schön erklärt wird, warum man es denn besser und vor allem wie man es besser machen

[3:28] kann. Das hat mich sofort überzeugt, gerade als ich die erste Regel gesehen habe und ich gedacht

[3:32] habe, mein Gott, wenn ich irgendwie einen Euro kriegen würde für jedes Mal, wo ich unnötige

[3:37] Vergleiche mit Boolchen-Variablen sehe, ich wäre, glaube ich, reich. Und das ist so cool,

[3:42] denn jetzt kann ich einfach diese Regel quasi meinen Azubis oder Studierenden zum Beispiel,

[3:46] ich sag mal, hinlegen oder hinschicken, wie auch immer. Dann können sie sich das durchlesen und

[3:51] dann erspare ich mir das hundertfache Erklären, warum man nicht mit Boolchen-Variablen noch

[3:55] Vergleiche machen muss. Also von der Grundidee, es gibt 70 Codebeispiele, einmal in der schlechten

[4:01] Form und einmal in der optimierten Form. Das ist also schon eine ganz schöne Hausnummer. Insgesamt

[4:06] ist das Buch aber gar nicht so dick. Das sind also, wenn ich mir hier die gedruckte Ausgabe mal

[4:09] kurz angucke, sind wir auf Seite 160, 165, wo wirklich der Text aufhört. Also es ist wirklich

[4:16] sehr dünn, wenn man es in der Hand hat. Das kann man wirklich relativ schnell durchlesen, sofern

[4:20] man natürlich den Code versteht. Davon gehe ich aber mal aus. Das heißt, es ist kurz und kompakt

[4:25] und auf keinen Fall langweilig. Die Codebeispiele sind auch so gewählt, dass sie rund um so eine

[4:29] Reise zum Mars sich drehen. Das heißt, es gibt immer die Domäne Astronaut und Rakete und Flug

[4:35] und Mars Rover und solche Sachen. Also ganz witzig gewählt, sodass man also nicht irgendwie mit den

[4:40] 0815 Artikel und Rechnungen und so weiter totgeschlagen wird, sondern dass man auch ein

[4:47] bisschen Abwechslung hat und ein bisschen was anderes liest als diese Standardbeispiele. Von

[4:51] daher hat mir sehr, sehr gut gefallen. Auch die Domäne, die das Ganze noch mal so ein bisschen

[4:55] auflockert. Und das Buch beginnt jetzt mit so grundlegenden Sachen, wie ich gerade gesagt habe,

[5:00] keine burschen Vergleiche, und wird dann immer, ich sage mal, so ein bisschen komplexer. Am Ende

[5:04] gibt es dann auch was zum Thema funktionale Programmierung, Fehlerbehandlung und so weiter.

[5:08] Also es baut schon so ein bisschen aufeinander auf. Ich sage mal, wenn ich so einen Azubi im

[5:11] ersten Lehrjahr habe, der vielleicht ganz grob aus dem Bauch, ich sage mal ein halbes Jahr da ist,

[5:15] der schon seine ersten Erfahrungen gemacht hat, der ein bisschen was programmiert hat,

[5:18] dann wird er das auf jeden Fall verstehen können und auch nachvollziehen können, warum vielleicht

[5:22] dann das, was auf der rechten Seite steht, besser ist. Dann leiten wir auch so ein bisschen gerade

[5:26] schon mal zur Zielgruppe über. Aber bevor wir da ein bisschen tiefer reingehen, vielleicht noch

[5:31] als Letztes. Das Buch heißt zwar Java by Comparison und der ganze Code ist auch Java. Ich

[5:36] bin aber der Meinung, dass man das ohne Probleme auch auf alle anderen Puomi-Sprachen übertragen

[5:39] kann, die zumindest so ähnlich sind. Also was habe ich jetzt im Kopf? PHP, C-Sharp. Ich denke mal,

[5:45] die Konzepte gibt es in allen Sprachen, die dort behandelt werden, auch wenn die Standardbeispiele

[5:50] hier im Buch jetzt in Java sind. Ich glaube, das kann auch jemand, der eine andere Sprache kennt,

[5:54] gut nachvollziehen. Und die Beispiele sind bewusst so klein und so kurz gewählt,

[5:59] dass man also nicht einen riesen Kontext erst mal verstehen muss mit 1000 super geilen

[6:03] Sprachmitteln, sondern es geht wirklich um die absoluten Grundlagen der Programmierung. Also

[6:07] sowas wie, ich sage jetzt mal, Schleifen-If-Bedingungen. Wenn man sowas hat, das reicht,

[6:12] um die Beispiele zu verstehen. Man muss also jetzt nicht super tiefe Kenntnisse von Java haben,

[6:16] außer vielleicht in den etwas späteren Kapiteln, wo es dann um Sachen geht wie zum Beispiel Optionals

[6:21] oder Streams. Wobei diese Konzepte natürlich in anderen Sprachen inzwischen auch drin sind. Die

[6:25] heißen da vielleicht ein bisschen anders. Also zum Beispiel Link in C-Sharp, das wäre sowas,

[6:29] was ich so mit so einem Stream vergleichen kann. Aber grundsätzlich ist das Buch für jeden Azubi

[6:35] und jeden Ausbilder geeignet, egal ob er jetzt mit Java arbeitet oder vielleicht in der Praxis

[6:39] mit einer anderen Programmiersprache. Das wollte ich kurz zum Abschluss noch mal sagen. Gut,

[6:43] gehen wir da mal so ein bisschen über zur Zielgruppe. Also ich habe gerade schon gesagt,

[6:46] so Anfänger bis Fortgeschrittene, dafür ist das Buch gut geeignet. Und das Buch selbst bringt auch

[6:51] so einen kleinen Einstiegstest mit. Wenn man zum Beispiel das FizzBuzz-Problem vernünftig

[6:56] lösen kann, dann ist man eigentlich genau die richtige Zielgruppe für dieses Buch. Das ist

[7:00] ganz interessant, weil das FizzBuzz benutze ich auch seit Jahren, zum Beispiel im Programmiertests

[7:03] für angehende Azubis. Ich mache das auf jeden Fall auch immer in meinem Java-Tutorial mit den

[7:09] neuen Auszubildenden und so weiter. Und von daher, also wenn du das FizzBuzz-Problem noch nicht kennst,

[7:13] es geht darum, dass man von 1 bis 100 zählen soll. Und für alle Zahlen, die durch 3 teilbar sind,

[7:17] soll man Fizz ausgeben, anstatt der Zahl. Für alle Zahlen, die durch 5 teilbar sind, Buzz. Und

[7:22] für alle, die durch beide teilbar sind, also durch 15, dann soll man FizzBuzz ausgeben. Also das heißt,

[7:26] du hast quasi 100 Zeilen, die du ausgibst und es liest sich dann 1, 2, Fizz, 4, Buzz, Fizz, 7 und

[7:33] so weiter. Und da braucht man so ein paar grundlegende Programmierkenntnisse, also im

[7:38] Prinzip alles, was man für Algorithmen braucht. Man braucht eine kleine Sequenz, eine Wiederholung

[7:41] und auch eine Verzweigung. Das heißt, so grundlegende Programmierkonstrukte kann man

[7:44] damit ganz gut abdecken. Wenn man das Problem lösen kann, hat man schon mal die Basics der

[7:48] Programmierung verstanden. Und das ist auch die Empfehlung des Buches. Wenn man das alleine lösen

[7:53] kann – und ich sage einfach mal so, in einer Viertelstunde steht, glaube ich, sogar auch im

[7:56] Buch drin – dann ist man genau die richtige Zielgruppe für dieses Buch. Und im Prinzip kann

[8:01] man sich jetzt vorstellen, dass viele der Regeln oder Beispiele, die in dem Buch genannt werden,

[8:05] jetzt hin zu einer optimalen Lösung gehen, weg von Sachen, die sich wiederholen oder unnötig sind

[8:12] oder schwer zu verstehen sind. Wenn du das mal am FizzBuzz-Beispiel sehen willst, hör doch einfach

[8:17] mal mein Wissenshäppchen an, das Don't-Repeat-Yourself. Da habe ich schon vor einigen

[8:22] Monaten inzwischen was genau zu diesem Problem sogar gemacht. Und im Blogartikel dazu findest

[8:27] du sogar meine Schritt-für-Schritt-Überarbeitung eines üblichen FizzBuzz-Algorithmus hin zu einem,

[8:32] ich sage mal, optimierten, ohne Wiederholungen und so weiter. Packe ich alles in die Shownotes,

[8:37] kannst einfach reinschauen. Mein Wissenshäppchen Nummer 1, Don't-Repeat-Yourself. Ja,

[8:41] ich finde aber auch, wenn man gerade kein Premier-Einsteiger mehr ist, sondern vielleicht

[8:45] auf der anderen Seite steht, nämlich als Ausbilder tätig ist, ist das Buch super gut geeignet. Denn

[8:49] ich habe ja schon gesagt, gerade wenn ich jetzt irgendwie meinem Azubi zum hundertsten Mal

[8:53] erklären muss, also ich hoffe nicht dem gleichen Azubi zum hundertsten Mal, aber insgesamt über

[8:56] alle Azubis und Studierenden hinweg, zum hundertsten Mal erklären muss, warum man nicht

[9:00] mehr gleich gleich True schreiben muss, wenn man schon eine Buche-Variable hat, dann erleichtert

[9:04] das natürlich auch meine Arbeit und ich bin nicht mehr so angenervt, in Anführungszeichen. Das bin

[9:08] ich natürlich nie. Ja, ich bin ja Ausbilder und vermittel gern Wissen, aber irgendwann nervt es

[9:13] doch schon ein bisschen, wenn man immer wieder dasselbe erzählen muss und erklären muss. Und

[9:16] hier habe ich jetzt wirklich ein Buch an der Hand, wo ich wirklich auf zwei Seiten ganz

[9:20] grundlegende Probleme bei der Programmierung super gut erklärt habe. Viel besser und viel

[9:26] nachvollziehbar, als wenn ich das jedes Mal selber erklären müsste. Das heißt, ich könnte

[9:31] jetzt zum Beispiel, angenommen, ich mache ein Code-Review bei meinem Azubi und ich finde da

[9:34] wieder so einen Bullshit-Vergleich, dann könnte ich ihm einfach da hinschreiben als Kommentar,

[9:37] nicht sowas wie, ja, Bullshit-Vergleiche sind unnötig, dies und das, und dann müssen wir wieder

[9:41] drüber reden, dann müssen wir einen Termin finden, wo ich ihm das erklären kann und hin und her,

[9:44] sondern ich kann ihm einfach sagen, hey, guck doch mal in Kapitel 1 von dem Buch,

[9:48] Java by Comparison, da steht genau drin, warum du das hier eigentlich nicht machen solltest. Also,

[9:53] das erhoffe ich mir zumindest, dass es in Zukunft möglich ist, denn ich habe das Buch ja selber

[9:56] gerade erst gelesen und meine Azubis kennen es noch gar nicht, aber in Zukunft würde ich mir

[10:00] wünschen, dass ich das so machen kann, denn dadurch erspare ich mir natürlich auch, ja,

[10:04] Zeit zum einen und dieses ewige Wiederholen von Dingen, die ich schon tausendmal erzählt habe.

[10:09] Und gerade diese grundlegenden Sachen, die kann man, glaube ich, ganz gut im Selbststudium sich

[10:13] angucken. Man sieht sofort vorher und nachher, man kann das miteinander vergleichen, man sieht

[10:18] zum Beispiel jetzt, dass der Code kürzer wird, dass er trotzdem verständlich bleibt und das

[10:22] Gleiche macht wie vorher und ich glaube, das führt zu einer guten Erkenntnis, wenn ich als angehender

[10:27] Entwickler mir das quasi selber erarbeiten kann. Das ist jetzt zumindest meine Vorstellung. So,

[10:32] wie sagt man so schön, Vorsicht, Disclaimer, ich habe das Zeug natürlich in der Praxis noch

[10:37] nicht selber angewendet. Ich habe das Buch gerade erst komplett gelesen und werde das jetzt in

[10:41] Zukunft machen und ich wünsche mir, dass das so funktioniert. Ich gehe auch ganz stark davon aus,

[10:45] dass das so funktionieren wird, aber ich weiß natürlich noch nicht, ich habe es noch nicht in

[10:49] der Praxis erprobt. Aber so, wie die Kapitel geschrieben sind und man kann sich es ja einfach

[10:53] angucken, ein kleines Problem auf zwei Seiten erklärt. Kurz und knackig und bündig und gut

[10:59] nachvollziehbar und von daher für mich eine ganz tolle Referenz für diese üblichen Probleme,

[11:03] die ich halt beim Code Review meiner Azubis immer wieder finde. Okay, das zur Zielgruppe. Also

[11:09] meiner Meinung nach sowohl für Ausbilder als auch für Azubis bestens geeignet und auch schon für

[11:14] Azubis, die gerade erst anfangen mit der Programmierung. Gut, dann kommen wir jetzt mal

[11:18] zu den Inhalten. Also worum geht es denn genau in dem Buch? Was sind die einzelnen Kapitel?

[11:22] Grundsätzlich ist der Aufbau ja so, dass er erst mal ganz einfach losgeht. Ich habe jetzt schon

[11:27] ja tausendmal erzählt, dieses Beispiel mit den unnötigen Bulschen vergleichen. Aber das geht

[11:32] dann zum Beispiel weiter mit, dass man keine Negationen verwenden soll. Also zum Beispiel

[11:36] anstatt zu sagen, Person ist nicht erwachsen, könnte man zum Beispiel besser sagen, jugendlich,

[11:42] weil das menschliche Gehirn besser positive Sachen verstehen kann. Oder ganz wichtiger Hinweis,

[11:47] dass man zum Beispiel immer Klammern nutzen sollte, gerade bei if-Konstrukten zum Beispiel.

[11:51] Denn wenn man eine Klammer am Ende vergisst zu setzen, dann wird der Code eventuell nicht so

[11:57] ausgefüllt, wie man es haben will und so weiter. Also so ein paar ganz einfache Sachen, die man

[12:00] aber schnell mal falsch machen kann und aber auch schnell verstehen kann, warum man sie denn nicht

[12:05] machen sollte. Damit geht es so ein bisschen los und dann wird es Schritt für Schritt immer so ein

[12:09] bisschen schwieriger, in Anführungszeichen sage ich mal. Das heißt, es gibt dann zum Beispiel

[12:14] ein Kapitel komplett über Kommentare. Warum sollte man keine Kommentare schreiben und wie kriegt man

[12:18] es hin, dass der Code trotzdem lesbar bleibt? Oder diese üblichen Probleme, die Codesmells,

[12:24] die man vielleicht kennt, die Magic Numbers zum Beispiel. Anstatt die Nummern direkt hinzuschreiben,

[12:29] konstanten, mit sprechenden Namen benutzen und so weiter. Das ist also etwas, wo man schon ein

[12:33] bisschen mehr Verständnis vielleicht haben muss, weil der Code auch insgesamt dann lesbarer werden

[12:38] muss. Da geht es also nicht nur um die reinen Sprachkonstrukte, wie hier gehört eine Klammer

[12:41] hin und so weiter, sondern eher schon in Richtung von Verständlichkeit und von Design meines Codes.

[12:47] Dann gibt es ein ganzes Kapitel zum Thema Benennung von Dingen. Das ist ja auch etwas,

[12:52] wo man sich ganz, ganz intensiv mit beschäftigen kann. Es gibt ja den schönen Spruch, ich weiß

[12:55] gar nicht von wem er ist, es gibt eigentlich nur zwei Probleme in der Informatik. Einmal,

[13:00] den Dingen einen Namen zu geben und dann Cache Invalidation. Und wenn man jetzt eine erweiterte

[13:05] Version des Witzes haben will, kann man noch sagen und Off-By-One-Errors. Aber das nur so am

[13:10] Rande. Es geht jetzt hier also weiter, wie benenne ich die Sachen. Es gibt einen Ausflug in Richtung

[13:15] Domänensprache, dass ich meinen Code also so benennen sollte, wie der Fachbereich zum Beispiel

[13:19] auch mit der Terminologie umgeht. Dann gibt es ein ganzes Kapitel zum Thema Fehlerbehandlung,

[13:24] was ich auch sehr gut finde. Gerade das Try-Catch zum Beispiel, dass man seine Ressourcen immer

[13:29] schließen muss. Das ist dann zum Beispiel speziell in Java auch dieses Try-With-Resources gibt,

[13:34] was automatisch zum Beispiel Dateien nach der Abarbeitung zumacht und so weiter. Das heißt,

[13:40] viele gute Sachen, die ich auch in, ich sag mal, robustem Code heutzutage so erwarten würde. Und

[13:45] hier wird immer wirklich schön an einem kleinen Beispiel erklärt, warum das so ist und was einem

[13:49] das auch bringt. Dann ein separates Kapitel zum Thema Tests. Wie baue ich meine Unit-Tests auf?

[13:55] Wie rum ist zum Beispiel die Reihenfolge bei dem IsHerdEquals oder sowas? Oder wenn ich

[14:01] Vergleiche mit Double-Werten mache, dass man darauf aufpassen muss, dass sie vielleicht

[14:05] durch Gleitkomma-Arithmetik zu Rundungsfehlern führen und so weiter. Also ganz konkrete Beispiele,

[14:11] wie man dann auch vernünftige Tests schreibt. Dann geht es weiter mit einem Kapitel über das

[14:16] Design von Klassen und Objekten. Das heißt zum Beispiel sowas wie Immutable Classes finde ich

[14:23] eine ganz interessante Geschichte. Oder dass man aufpassen soll, dass Referenzen zum Beispiel auf

[14:28] Listen, die man als Instanzvariablen hat, nicht nach draußen gegeben werden dürfen, damit man

[14:33] da nicht drin rum vorwerkeln kann zum Beispiel. Dann ganz wichtig, dass man nicht mit Null arbeiten

[14:38] darf zum Beispiel. Solche Dinge werden da gut erklärt. Und dann gibt es noch ein Kapitel zum

[14:42] Thema Flow. Das geht jetzt in Richtung von Streams und Lambdas. Seit Java 8 kann man das ja wunderbar

[14:48] machen. Das heißt, anstatt jetzt so anonyme Klassen zu nutzen, können wir jetzt Lambda-Ausdrucke

[14:52] benutzen. Anstatt verschachtelte Vorschleifen sollten wir vielleicht lieber die Stream-API

[14:57] benutzen. Und Methodenreferenzen werden eingeführt, um den Code noch lesbarer zu

[15:02] machen. Also ganz viele konkrete Sachen, die auch in modernem Java-Code heute Gang und Gäbe sind

[15:08] oder es sein sollten, werden hier gut eingeführt. Und in Kapitel 9 gibt es dann noch einen Ausblick

[15:14] auf die Praxis. Das heißt, hier gehen wir jetzt auch ein bisschen weg von der konkreten Programmierung

[15:18] hin zu dem, was es drumherum noch so gibt und geben sollte. Zum Beispiel automatisierter Build,

[15:25] Continuous Integration und Logging-Framework einsetzen, statt alles auf die Konsole zu

[15:30] schreiben. Das sind so Dinge, die sollte man, sobald man sein erstes echtes Projekt umsetzt,

[15:35] auf jeden Fall machen. Aber wer sagt einem das? Wer bringt einem das bei? Und vor allem,

[15:40] warum soll man es denn machen? Und hier sind diese Sachen, die ich gerade erwähnt habe,

[15:43] auf ein, zwei Seiten komplett einmal erklärt. Klar, das reicht in der Tiefe noch nicht aus. Das

[15:49] ist völlig in Ordnung. Continuous Integration zum Beispiel habe ich eine komplette Podcast-Episode

[15:53] schon aufgenommen, nur für eine Einführung. Also das ist natürlich etwas oberflächlich,

[15:58] das ist völlig klar. Aber hier geht es ja auch darum, dass man erstmal einen Einstieg findet.

[16:01] Und dafür finde ich es absolut in Ordnung, dass hier zum Abschluss des Buches nochmal wirklich auf

[16:06] die Praxis eingegangen wird, dass die Programmierung heute halt eben nicht mehr nur algorithmik ist,

[16:11] sondern dass man auch den ganzen Rumstrom herum berücksichtigen muss, dass man halt Abhängigkeiten

[16:15] hat, dass ich eine komplexe Entwicklungsumgebung habe, dass ich im Team arbeite und nicht alleine.

[16:20] Und das sind alles Dinge, auf die weist das Buch zum Ende auch nochmal hin. Das heißt,

[16:24] für mich rundet es das so ein bisschen ab. Es sind nicht nur konkrete Code-Beispiele,

[16:28] sondern auch ein bisschen was darüber hinaus. Und das hat mir in dem Buch auch sehr gut gefallen,

[16:32] dass solche Dinge, die in meiner Entwicklerpraxis absolut wichtig sind, aber wenig mit dem Code

[16:37] an sich zu tun haben, dass die hier also auch nochmal schön dargestellt werden und verständlich

[16:41] erklärt werden. So, ganz nebenbei zu den Themen oder zu einigen, die ich gerade erwähnt habe,

[16:46] gibt es natürlich auch von mir passende Podcast-Episoden, zum Beispiel Test-Driven,

[16:49] Development, Unit-Testing. Ja, dafür habe ich was gemacht. Funktionale Programmierung habe

[16:53] ich ein langes Interview aufgenommen zum Thema, wie ich das mit Java zum Beispiel umsetzen kann.

[16:58] Und Continuous Integration hatte ich gerade schon gesagt, gibt es auch alles. Also einfach mal die

[17:01] Podcast-Suche anschmeißen oder in die Shownotes gucken. Da sind die jeweiligen Episoden von mir

[17:06] verlinkt. Okay, zum Abschluss heute gibt es nochmal drei konkrete Beispiele, die man so im

[17:13] Buch finden kann. Ich habe den Code dazu ein bisschen angepasst, um jetzt nicht einfach das

[17:17] abzuschreiben, was im Buch zu sehen ist. Guckst du einfach mal in die Shownotes. Da habe ich mir

[17:20] ein bisschen was Eigenes ausgedacht. Den einen habe ich jetzt schon öfter erwähnt. Diese unnötigen

[17:25] Vergleiche mit Bool habe ich jetzt schon ein paar mal erklärt. Da gehen wir jetzt nicht nochmal genau

[17:28] darauf ein. Aber zwei zusätzlich habe ich nochmal rausgenommen und zwar nutze die Domänensprache.

[17:33] Ich habe mal in meinem Beispiel ein bisschen was aus der Versicherungsdomäne genommen. Ja,

[17:37] da kann man jetzt mit ganz kryptischen mathematischen Geschichten arbeiten. Ja,

[17:41] also ich habe zum Beispiel schon was programmiert für die Krankenversicherung mit AX und Groß K von

[17:47] XY und Klein K von X und also ganz wilde mathematische Funktionen, die man da bauen

[17:52] muss. Das Problem ist nur, dass am Ende keiner mehr da durchsteigt. Die Mathematiker, die wissen das

[17:56] vielleicht alles noch, was die ganzen kleinen und Großbuchstaben und Alpha Omega und so weiter

[18:00] alle bedeuten. Entwickler tun sich da vielleicht ein bisschen schwerer mit, wenn sie das mal zwei

[18:04] Wochen nicht mehr lesen. Das heißt, man kann da auch etwas sprechendere Namen für finden. Und

[18:08] anstatt zum Beispiel solche komischen Abkürzungen zu nehmen, könnte ich jetzt einfach

[18:11] Domänenbegriffe benutzen. In unserem Fall der Krankenversicherung wäre es halt sowas wie der

[18:15] Monatsbeitrag oder zum Beispiel die Alterungsrückstellung oder der Kopfschaden oder

[18:22] Rentenbarwert. Das ist jetzt für Leute, die nicht aus der Krankenversicherung kommen, sind das

[18:26] vielleicht auch alles Begriffe, die nicht so intuitiv sind oder vielleicht sogar eine ganz

[18:29] andere Bedeutung haben, als man eigentlich glaubt. Aber es ist immer noch einfacher,

[18:32] das zu verstehen, als irgendwie K von X und Y und Z und Alpha Omega zu benutzen. Das ist

[18:38] jetzt nur ein Beispiel, wie man es machen kann. Andere Möglichkeit, wenn man eher technische

[18:43] Begriffe für seine Variablen wählt, wie zum Beispiel Index in Lookup-Tabelle oder sowas,

[18:48] das ist ja sehr, sehr technisch, kann man dem nicht noch einfach einen fachlichen Namen geben,

[18:52] damit auch ein Mitarbeiter aus dem Fachbereich versteht, was da vor sich geht zum Beispiel.

[18:58] Ich vergleiche das immer auch ganz gerne, wenn ich zum Beispiel mit Excel arbeite, damit, dass ich ja dort auch Zellreferenzen einen Namen geben kann.

[19:05] Und anstatt, dass ich dann so eine Formel mache wie Summe von A1 bis X3 zum Beispiel, könnte ich einfach machen Summe der Kopfschäden.

[19:13] Und die Kopfschäden sind dann halt dieser Zellbereich mit dem kryptischen Namen.

[19:17] Das sind Dinge, die meinen Code sofort lesbarer machen und auch fachlich viel besser prüfbar machen.

[19:23] Denn man kann ganz schnell mal den Unterschied zwischen einem kleinen K und einem großen K übersehen.

[19:28] Gerade wenn ich so case-sensitive Sprachen habe wie in Java, wo das dann zwei unterschiedliche Variablen wären.

[19:33] Und dann fällt einem gar nicht der Fehler im Code auf.

[19:35] Wenn da aber sprechende Domänennamen stünden, wäre es mir vielleicht aufgefallen, dass das eine der Kopfschaden ist und das andere der was auch immer das dann ist.

[19:43] Ja, ich weiß es selber nicht.

[19:45] Gut, nächstes Beispiel und damit auch das letzte für heute ist dann zum Beispiel, dass man Optionals so benutzen sollte, wie sie gedacht sind.

[19:51] Und nicht so, wie sie nicht gedacht sind.

[19:53] Ja toll, was heißt das jetzt?

[19:55] Also man sollte Optionals so benutzen, wie man Streams auch benutzt.

[19:58] Also eher in einem funktionalen Ansatz.

[20:00] Was bedeutet das?

[20:02] Vielleicht für alle, die nicht jeden Tag mit Java arbeiten.

[20:04] Vielleicht gehörst du ja dazu.

[20:06] Ein Optional ist ein Datentyp, der repräsentiert, dass ein Wert entweder vorhanden ist oder nicht vorhanden ist.

[20:12] Also man kann das fast wirklich mit optional übersetzen.

[20:15] Beispiel, ich suche einen Benutzer anhand seiner ID in der Datenbank.

[20:19] Entweder gibt es den Benutzer, dann kriege ich halt ein gefülltes Optional zurück.

[20:23] Und wenn es den Benutzer nicht gibt, weil er zum Beispiel gelöscht wurde oder ich habe mich vertippt bei der ID oder wie auch immer, dann kriege ich halt ein leeres Optional.

[20:30] Was soll das Ganze?

[20:31] Das ist eigentlich ein Ersatz für Null.

[20:33] Das heißt, anstatt zu sagen, Mensch, den Benutzer gibt es nicht, ich mache mal Return Null.

[20:37] Und der Aufrufer muss jetzt jedes Mal gucken, ob der Benutzer vielleicht Null ist.

[20:40] Denn wenn er es nicht tut, kriegt er einen Null-Pointer.

[20:43] Und das wollen wir natürlich auf jeden Fall vermeiden.

[20:45] Deswegen können wir so ein Optional zurückgeben.

[20:47] Und zum einen sehe ich dann direkt an der API der Methode, dass hier ein OptionalOfUser zurückkommt.

[20:53] Also Optional ist eine generische Klasse.

[20:55] Genau wie ListOf oder zum Beispiel, das fällt mir noch ein, Map oder was auch immer.

[21:01] Alles, was halt irgendwie typisiert werden kann.

[21:04] Das ist ein Optional eben auch.

[21:05] Der hat halt eben einen inneren Datentyp und den ja quasi umschließt.

[21:09] Und dann sehe ich schon an der Methode, oh, hier kommt kein User zurück, der im Zweifel Null ist.

[21:14] Sondern hier kommt ein OptionalOfUser zurück.

[21:17] Und ich sehe schon direkt, ohne die Methode überhaupt mehr genauer anzugucken,

[21:20] dass es auch sein kann, dass es eben keinen Benutzer gibt, der da zurückgegeben wird.

[21:24] Das heißt, zum einen wird der Code für mich offensichtlicher, weil ich nicht mehr überlegen muss,

[21:29] könnte der User auch Null sein?

[21:31] Ich prüfe mal besser, ob das ist.

[21:33] Und zum anderen vermeide ich eben auch diese Null-Pointer, die dann auftreten können,

[21:38] wenn ich vergesse, Null-Check zu machen.

[21:40] Denn wenn ich immer ein Optional zurückkriege, und der ist im Zweifel halt eben leer,

[21:43] dann kann auf jeden Fall ein Null-Pointer nicht mehr auftreten,

[21:46] weil das Ding, was ich zurückkriege, ist definitiv nicht Null.

[21:49] Jetzt kann ich aber an dem Optional sowas machen wie, hey, ist denn der Wert vorhanden oder nicht?

[21:54] In Java hieße das dann IsPresent.

[21:56] Das heißt, ich kann an dem Optional die Methode aufrufen, IsPresent,

[21:59] und dann sagt er mir, ja oder nein, also ist ein bool'scher Rückgabewert.

[22:02] Und dann kann ich halt davon abhängig was machen.

[22:04] Also, if Optional IsPresent, mach irgendwas mit dem User, zum Beispiel.

[22:09] Das sieht jetzt aber nicht großartig anders aus als,

[22:11] if User ungleich Null, mach irgendwas.

[22:14] Das ist also vom Code her exakt identisch,

[22:16] nur dass ich einmal auf Null prüfe und einmal dieses IsPresent benutze.

[22:19] Und hier kommt genau das Problem, was jetzt dieser konkrete Fall aus dem Buch schildert.

[22:24] Nämlich, dieses IsPresent zu benutzen, ist eigentlich genau falsch.

[22:27] Das wollen wir so eigentlich nicht.

[22:29] Stattdessen wollen wir einen eher streambasierten Ansatz wählen

[22:32] und den Optional entscheiden lassen, ob er bestimmte Dinge ausführen soll oder nicht.

[22:36] Und zwar abhängig davon, ob der Wert vorhanden ist oder nicht.

[22:39] Das heißt, wie sieht das konkret aus?

[22:41] Anstatt IsPresent zu benutzen, gibt es eine Methode, die heißt ifPresent.

[22:46] Und dieser Methode kann ich ein Lambda-Ausdruck reingeben.

[22:49] Und der Lambda wird dann nur ausgeführt, wenn der Wert vorhanden ist in dem Optional.

[22:54] Das heißt, ich spare mir eigentlich die Fallunterscheidung als Aufrufer

[22:58] und delegiere diese Entscheidung, ob etwas gemacht werden soll oder nicht,

[23:02] abhängig von dem Vorhandensein des Wertes, an genau die Klasse, die dafür zuständig ist,

[23:07] nämlich das Optional.

[23:08] Und so ist mein Code deutlich kürzer, trotzdem, wie ich finde, verständlicher

[23:13] und ich habe diesen eher flow-orientierten, den in Java stream-orientierten Ansatz.

[23:18] Ich kann die Sachen hintereinander reihen

[23:20] und sie werden nicht immer unterbrochen durch if not null, if not null, if not null.

[23:24] Das ist jetzt ein weiteres Beispiel aus dem Buch, was den Code deutlich lesbarer macht

[23:28] und eben auch weniger fehleranfällig, weil diese Null-Pointer nicht mehr auftreten können.

[23:33] So, damit habe ich jetzt eigentlich alles gesagt, was es zu Java by Comparison zu sagen gibt.

[23:38] Ach ja, übrigens, die Autoren heißen Simon Harrer, Jörg Lenhardt und Linus Dietz.

[23:44] Wie man an den Namen schon hört, sind das sogar alles Deutsche.

[23:47] Die haben auch schon an Universitäten in Deutschland zum Beispiel Java gelehrt.

[23:51] Das Buch ist bei den Pragmatic Programmers erschienen und ist auch auf Englisch tatsächlich.

[23:55] Aber die Autoren kommen sogar alle aus Deutschland

[23:58] und haben ihre Erfahrungen aus der Lehre an verschiedenen Hochschulen in dieses Buch gegossen.

[24:03] Kommen also wirklich aus der Praxis und ich kann das absolut bestätigen.

[24:06] Die Beispiele drin sind, die habe ich schon mehrfach bei meinen eigenen Studierenden und Auszubildenden gesehen.

[24:11] Von daher, ich kann das nur wärmstens empfehlen, das Buch.

[24:14] Ich kann es nur noch mal wiederholen.

[24:15] Sowohl für Azubis als auch für Ausbilder eine ganz tolle Sammlung mit konkreten Code-Optimierungen,

[24:22] die man im Alltag direkt anwenden kann.

[24:24] Also wirklich ganz, ganz tolle Geschichte.

[24:27] Ich glaube, der Return on Investment, wenn man das so sagen kann, dieses Buches ist wirklich hoch.

[24:32] Denn ich kann die Sachen, die ich gelesen habe, eigentlich sofort verstehen,

[24:35] kurz und knackig erklärt und einfach direkt in die Praxis überführen.

[24:39] Und ich sehe vor allem auch, was mir das bringt.

[24:41] Also nicht so, ja, du sollst keine Kommentare verwenden,

[24:44] sondern hier sind halt wirklich direkt mit Beispielen hinterlegt,

[24:47] warum das besser ist, wenn ich stattdessen zum Beispiel sprechende Methodennamen benutze.

[24:51] Also es ist offensichtlich durch das Layout dieses Buches auch so gelöst,

[24:55] dass ich vorher, nachher direkt vergleichen kann.

[24:57] Ich sehe, der Code wird kürzer, er wird lesbarer.

[25:00] Und das ist also, ja, für jemanden, der diese Sachen zum Beispiel zum ersten Mal liest,

[25:04] wirklich, wie ich finde, augenöffnend.

[25:06] Also wenn man den Code wirklich sehen kann und ihn selber vergleichen kann,

[25:10] ist es viel, viel besser, finde ich, als wenn mir mein Ausbilder mir erklären würde,

[25:14] ja, das musst du so und so machen, weil und denk doch mal da dran und so.

[25:17] Viel einfacher, wenn ich es wirklich plastisch vor mir sehe.

[25:19] Ich glaube, es ist auch für Einsteiger deswegen gut nachvollziehbar.

[25:23] Wenn du jetzt auch der Meinung bist, dass das Buch was für dich ist,

[25:26] dann schau doch gerne mal in meine Shownotes unter anwendungsentwicklerpodcast.de

[25:31] slash 130 für die heutige 130. Episode.

[25:36] Da findest du Links natürlich zum Buch, zur Website zum Buch,

[25:40] zu verschiedenen Rezensionen zum Buch und auch noch zu einer Podcast-Episode

[25:44] beim InnoQ Podcast.

[25:46] Vielleicht kennst du den schon.

[25:47] Da hat der Simon Harrer, einer der Autoren, auch schon mal ein Interview gegeben.

[25:51] Der arbeitet nämlich bei InnoQ und, ja, da bot sich das natürlich an.

[25:55] Da erzählt er auch noch mal ein bisschen mehr zum Buch.

[25:57] Kann ich auch absolut empfehlen, wenn du mal so ein bisschen Hintergrund wissen,

[26:00] wie es zu dem Buch kam und was der Ansatz war und so wissen willst.

[26:03] Ansonsten von mir, wie gesagt, ganz klare Leseempfehlung.

[26:06] Ab jetzt werde ich das mit jedem meiner Azubis auf jeden Fall lesen

[26:10] oder ihn lesen lassen oder sie,

[26:12] weil ich glaube, dass man wirklich viel für die Praxis mitnehmen kann.

[26:15] Wenn du das Buch auch schon gelesen hast und Feedback vielleicht hast,

[26:17] schreib mir gerne einen Kommentar unter die Shownotes, wie gesagt,

[26:20] anwendungsentwicklerpodcast.de slash 130.

[26:23] Da findest du alles, was du wissen musst.

[26:25] Auch noch mal die Code-Beispiele, die ich heute genannt habe,

[26:27] kannst du dir auch angucken.

[26:28] Und natürlich auch die ganzen Podcast-Episoden,

[26:30] die noch mal tiefer in die Themen reingehen,

[26:32] die im Buch nur so ein bisschen angeschnitten werden.

[26:35] Okay, damit bin ich für heute durch.

[26:37] Ich hoffe, du konntest ein bisschen was mitnehmen.

[26:39] Und ich hoffe natürlich auch, dass du das Buch mal anguckst,

[26:41] denn ich glaube, da können wir alle noch viel von mitnehmen,

[26:44] gerade wenn du in der Ausbildung tätig bist oder selber halt noch in der Ausbildung bist.

[26:48] Ansonsten sage ich vielen Dank fürs Zuhören und bis zum nächsten Mal.

[26:52] Tschüss!

[27:00] Untertitel im Auftrag des ZDF für funk, 2017