Java by Comparison

Michael Vitz: Hallo und herzlich willkommen zu einer neuen Folge vom innoQ-Podcast. Ich bin Michael Vitz und zu Gast habe ich heute den Simon. Hallo Simon!

Simon Harrer: Hallo Michael!

Michael Vitz: Genau, du bist heute Gast, weil du ein Buch geschrieben hast. Aber bevor wir über das Buch sprechen, stell dich doch unseren Hörern mal ganz kurz vor. Wer bist du und was machst du so eigentlich?

Simon Harrer: Mein Name ist Simon Harrer, ich bin Senior Consultant seit April diesen Jahres bei innoQ und war vorher sechs Jahre an der Universität Bamberg als Dozent, habe da promoviert, mich dann mit einer kurzen Eskapade in die Start-Up-Welt begeben und bin dann doch wieder in das Angestelltenverhältnis zurückgekehrt, in den sicheren Hafen.

Michael Vitz: Okay. Und du hast, bevor du bei uns angefangen hast, ein Buch geschrieben, wie heißt denn das Buch?

Simon Harrer: „Java by Comparison“. Es hat den Untertitel „Become a Java Craftsman in 70 Examples“.

Michael Vitz: Okay. Das heißt, es geht wahrscheinlich um Java und es geht irgendwie um guten Code, nehme ich an?

Simon Harrer: Genau.

Michael Vitz: Und wie seid ihr bzw. bist du überhaupt auf die Idee gekommen, ein Buch zu schreiben? Selten fällt einem ja morgens ein: Ach, ich wollte da noch dieses Buch geschrieben haben und dann fängt man an zu schreiben.

Simon Harrer: Nee, das war ein langer Prozess. Wie ich schon sagte, war ich sechs Jahre an der Universität in Bamberg als wissenschaftlicher Mitarbeiter und hatte das Glück, gleich am Anfang, als ich gestartet habe, mit dem Jörg Lenhard zusammen zwei neue Java-Kurse zu entwerfen: Einmal fortgeschrittene Java-Programmierung und Programmierung komplexer und interagierender Systeme, da geht es eher um Nebenläufigkeit auf der JVM. Und das war sozusagen die Geburtsstunde des Buches, auch wenn wir damals noch nichts von diesem Buch wussten. Denn in den beiden Lehrveranstaltungen haben wir sehr viel Wert darauf gelegt, dass die Studierenden Aufgaben erarbeiten oder erledigen, Assignments bearbeiten, Code schreiben und diesen Code haben wir sehr detailliert ge-reviewed. Und den Studierenden dann ein Feedback zurückgegeben. Es war sehr, sehr zeitintensiv, hat aber unglaublich viel Spaß gemacht. Wir haben den Studierenden immer einen Feedbackbogen zurückgegeben und der ist immer detaillierter geworden, weil wir gemerkt haben, wenn wir es kurz halten, dann kommen viele Rückfragen, also müssen wir den sehr ausführlich gestalten.

Und die beste Form Feedback zu geben, war so, dass wir das problematische Code-Snippet, das wir als nicht „clean“, als nicht sauber erachtet haben, nochmal herauskopiert haben, dann gesagt haben, warum genau das jetzt nicht so gut ist, dann eine verbesserte Version daneben gestellt haben und dann erklärt haben, warum die jetzt auch wirklich besser ist. Das ist sozusagen gewachsen, über die Zeit, über diese sechs Jahre hatten wir immer mehr dieser Codebeispiele nach diesem Konzept und irgendwann haben wir einfach beschlossen: Okay, wir schreiben mal in Pandoc, schnell zusammen gehackt, ein kleines Büchlein, im DIN-A5-Format, waren ein paar Seiten und das sah dann so cool aus, dass wir dachten: Lass uns doch mal schauen, welche Verlage es so gibt. Dann haben wir ein Proposal geschrieben, das an Pragmatic Programmers geschickt und ja, es war verrückt, drei Tage später kam dann die Antwort: Ja, wir würden euch gerne unter Vertrag nehmen. Und damit startete dann das Jahresprojekt.

Michael Vitz: Das klingt ja cool. Das heißt, bei der Zielgruppe für das Buch seid ihr dann auch in etwa vom Skill her bei denen geblieben, für die ihr das an der Uni gemacht habt oder habt ihr da dann den Scope nochmal gewechselt?

Simon Harrer: Wir sind im Prinzip bei denen geblieben. Wir gehen davon aus, dass jemand schon grundsätzlich Java programmieren kann, das heißt, dass er Kontrollfluss versteht, ein bisschen Exception-Handling versteht. Im Buch beschreiben wir es so, dass er den FizzBuzz-Test sehr souverän bestehen kann. Dieser FizzBuzz-Test ist so eine typische Aufgabe für Bewerber, in der man prüft, ob jemand Schleifen, Bedingungen und ein kleines bisschen Output, ein bisschen Arithmetik, ein bisschen Expressions, also Conditions, kann.

Michael Vitz: Das heißt, wenn ich sozusagen die Grundsyntax der Sprache kenne plus ein paar Datenstrukturen und ein CLI-Programm schreiben könnte, dann bin ich in etwa die Zielgruppe. Und das heißt, was ist denn eure Idee, was ich sozusagen im Laufe des Buches lerne und wo ich dann am Schluss hinkommen soll?

Simon Harrer: Man startet wie gesagt mit diesem Basis-Wissen, ich sage mal FizzBuzz und eine CLI-Anwendung und man lernt praktisch saubereren Java-Code zu programmieren. Es ist kein Buch, in dem man großartig neue Java-Bibliotheken oder neue Frameworks lernt, sondern im Prinzip ist das Buch wie ein Mentor, der einem hilft, besseren Code zu schreiben. Es schaut sozusagen auf den Code, den du schreibst, ein bisschen drauf und sagt, wenn du dieses und jenes schreibst: Hmm, das ist vielleicht nicht so gut, schreibe es doch besser so, aus diesen und jenen Gründen.

Michael Vitz: Genau. Und du hast ja eben schonmal erwähnt, dass ihr, als ihr diese Übungsaufgaben korrigiert habt, immer so eine Struktur beibehalten habt. Kannst du diese Struktur vielleicht nochmal etwas detaillierter erläutern? Was ihr euch dabei gedacht habt und was die Elemente dieser Struktur sind?

Simon Harrer: Die Struktur ist eine Doppelseite: Auf der linken Seite hat man ein Code-Beispiel, das ein Problem hat, aber nur ein Problem, auf das wir uns fokussieren wollen. Da können auch andere Probleme mit dabei sein, aber uns interessiert immer nur ein Problem in einem konkreten Code und darunter eine Erklärung, warum das Problem auch wirklich ein Problem ist. Wir wollen ein Problembewusstsein schaffen. Und auf der anderen Seite, also direkt daneben, wenn man das Buch aufklappt, direkt im Vergleich sieht man im Prinzip eine verbesserte Version dieses Code-Beispiels und darunter eine Erklärung, warum jetzt diese verbesserte Version auch wirklich besser ist.

Michael Vitz: Das heißt, so ein Code Snippet kann dann maximal eine viertel Seite sein, so Pi mal Daumen. Das heißt, es geht dann wahrscheinlich auch wirklich um sehr gezielte Problemlösung von sehr kleinen Dingen und nicht von einer Riesen -Klassenstruktur oder so etwas in der Art, oder?

Simon Harrer: Genau. Man kann sich das vorstellen, wie wenn man eine Twitter-Nachricht schreibt, man muss sich ganz schön beschränken, das fördert aber vielleicht auch die Kreativität, genauso ist es hier eben auch. Dieses Format hat uns einerseits beschränkt, aber auch erlaubt, sehr fokussiert bestimmte Probleme im „Clean Code“-Umfeld darzulegen und verständlich darzustellen. Gerade für Anfänger ist es ja sehr wichtig, dass man es einfach und verständlich darstellt.

Michael Vitz: Ja, auf jeden Fall. Und wenn man ein Beispiel zu groß aufspannt, muss man ja auch gleichzeitig viel mehr im Kopf halten und so kann man ja tatsächlich Problem für Problem angehen.

Simon Harrer: Besonders stark ist es eben, dass man den Code links und rechts direkt im Vergleich sehen kann. Man bekommt da so ein Bewusstsein: Okay, wenn ich das so umschreibe, dann wird es wirklich besser, dann schaut es sauberer aus, man kann das sehr leicht nachvollziehen. Das überzeugt eben sehr stark.

Michael Vitz: Ja, das kann ich mir gut vorstellen. Denn sonst, wenn man eine Webseite liest, dann scrollt man immer und dann hat man schon wieder vergessen, wie das Schlechte aussieht. Insofern finde ich das gerade auch mit dieser Gegenüberstellung tatsächlich eine ganz gute Idee, zumindest in der Print-Edition, wenn man das digital liest, muss man sich einen zweiten Bildschirm kaufen oder so.

Simon Harrer: In Adobe-Reader kann man eine doppelseitige Anzeige aktivieren, da geht es auch sehr gut.

Michael Vitz: Gut zu wissen, das werde ich dann wahrscheinlich in Anspruch nehmen. Jetzt habe ich mal ein bisschen über das Buch und das Inhaltsverzeichnis geskimmt und ach, wir haben noch gar nicht gesagt, dass es, glaube ich, Ende April herausgekommen ist?

Simon Harrer: Genau.

Michael Vitz: Genau. Das heißt, wenn ihr uns hört, dann solltet ihr es im deutschen Buchhandel ohne Probleme erstehen können. Aber ich habe gesehen, dass ihr sozusagen als Inhaltsstruktur generell etwas größere Blöcke aufgemacht habt. Kannst du da mal sagen, was so in etwa die Idee war, was sind so die Blöcke?

Simon Harrer: Wir starten am Anfang mit einfachen Problemen zum Codestyle, das ist eher so, um mal reinzukommen und dann geht es weiter. Wir haben ein Kapitel zu Kommentaren, zur Benennung von allem möglichen, ob es jetzt Variablen, Klassennamen oder Pakete sind, dann haben wir Fehlerbehandlung mit Exceptions und was man da alles beachten muss, Testing mit JUnit5 sogar schon, da sind wir ganz up to date, objektorientiertes Design, funktionale Aspekte über Java-Streams und Optional und dann ein abschließendes Kapitel über Dinge, die irgendwie wichtig werden, wenn die rechte Welt losgelassen wird, sei das jetzt Logging, Continuous Integration oder Arbeiten im Team mit gemeinsamen Java-Formatierungsrichtlinien, solche Themen.

Michael Vitz: Das ist cool. Gerade weil ihr eine Zielgruppe habt, die noch am Anfang ihrer Karriere steht, die tatsächlich noch die Grundlagen, die ja ein bisschen von der Sprache weggehen, auch noch mit lernen muss, das finde ich ganz cool. Ich habe auch gesehen, dass ihr am Ende eines Blockes immer noch so eine Art Zusammenfassung habt, die, so nehme ich an, nochmal den Gesamtblock zusammenfasst.

Simon Harrer: Genau. Jedes Kapitel wird motiviert, meistens mit einer Metapher, das ist immer ganz schön und dann schließen wir es mit so einem kleinen Wrap ab.

Michael Vitz: Jetzt haben wir schon über die generelle Aufteilung gesprochen und was so ein Item in etwa ist und ich denke, um zu gucken, ob man das Buch kaufen möchte, ob da etwas für einen drin ist, wäre es vielleicht ganz sinnvoll, wenn wir uns mal so zwei oder drei Items herausnehmen und darüber sprechen würden. Vielleicht fangen wir mal irgendwie mit etwas vorne an und wir müssen es auch so halten, dass ihr als Hörer oder Hörerin es versteht. Ich würde vielleicht mal zufällig etwas herausgreifen und sagen: Man kann mal über Verneinung als erstes sprechen. Das ist glaube ich ein Item, das relativ am Anfang steht. Kannst du mal so grob sagen, was ihr da erklärt habt? Damit man mal einen Eindruck davon bekommt, wie das Level so ist.

Simon Harrer: Also das Item heißt jetzt hier ganz klar „avoid negation“, also Verneinungen vermeiden, und es zielt halt darauf ab, dass jede Verneinung letztendlich eine Indirektion bedeutet, „yet another level of abstraction or indirection“ und das Problem, das die Studierenden letztendlich hatten, welches wir gesehen haben, ist, dass so angefangen wird, dass man ein if schreibt, ein Conditional und schreibt dann irgendeine Expression hinein und die überarbeitet man nicht mehr, die bleibt dann stehen. Häufig landen da dann irgendwelche Ausrufezeichen mit drin oder man ruft eben Methoden auf, in deren Name eine Negation ist, das ist versteckter, aber man hat dann ja trotzdem diese Negation, wenn man es liest, im Kopf und muss umdenken und beides macht den Code eben schwer lesbar. Und in einigen Fällen hat man doch sehr einfache Möglichkeiten diese Negierung komplett zu vermeiden. In diesem Beispiel haben wir ein if mit einem else zusammen und wenn man in der if-Bedingung eine Negation drin hat, also ein „not“ gleich am Anfang, kann man sehr einfach die beiden Bodies, sage ich mal, des if und des else einfach vertauschen, die Negierung herausnehmen, man hat also ohne semantisch irgendetwas zu ändern, die Negation entfernt und der Code lässt sich leichter lesen.

Michael Vitz: Genau und wenn man den Trick einmal kennt, dann unterstützen einen ja sogar IDEs dabei, meines Wissens nach ist es ja ein klassisches refactoring pattern, sozusagen ein switch mit if und else, ich weiß nicht genau, wie der Fachterminus ist, aber das bietet einem jede IDE. Und diese Negation bezieht sich ja nicht nur auf das Negationszeichen, also das Ausrufezeichen, sondern auch darauf, wenn man in Methodennamen so etwas wie isInvisible() oder isNotVisible() hat, auch da können ja Negationen vorkommen.

Simon Harrer: Das geht schon ein bisschen Richtung Naming dann, aber wir haben es eher aus der Negierungsperspektive gesehen und dann sollte man eben eine Methode nehmen, die das nicht enthält, zur Not muss man die noch schreiben, aber der Code wird dadurch viel, viel lesbarer, wenn man ihn sozusagen umdreht und die Methode nimmt, die keine Verneinung im Namen enthält.

Michael Vitz: Genau, ich kenne das sonst aus der Praxis, dass man dazu neigt, doppelt zu verneinen, also !isInvisible() zu benutzen, anstatt einfach isVisible. Ich glaube, es ist klar, dass das lesbarer ist, weil es ja auch die Intention viel mehr ausdrückt.

Simon Harrer: Genau. Wir haben hier noch den schönen Satz im Buch: „Everybody likes no negations“. Ich glaube, das zeigt es ganz gut.

Michael Vitz: Ja, das ist auf jeden Fall eine sehr schöne Zusammenfassung, die gefällt mir. Dann wollen wir noch ein etwas komplexeres Beispiel nehmen, genau, du hattest in unserer Vorbesprechung vorgeschlagen, wir könnten nochmal über State und Behaviour, also über State und Funktionalität sprechen. Sag doch mal, was da so eure Idee war.

Simon Harrer: Genau, also wir haben hier ein Item names „Combine state and behaviour“. Das ist eben etwas, das wir sehr häufig gesehen haben, dass Studierende einerseits Klassen gebaut haben, die eigentlich nur einen Zustand enthalten haben, und dann Klassen geschrieben haben, die nur Verhalten hatten, also nur Methoden, während die anderen eben die Felder enthielten, also komplett getrennt. Das sieht man teilweise auch in der Industrie, das kommt dann auf die Frameworks an, ob man eben alles stateless machen möchte, da ist es vielleicht eher eine Ausnahme. Aber allgemein, wenn man sich Objektorientierung anschaut, möchte man ja Zustand und Verhalten, vor allem Verhalten, welches mit diesem Zustand interagiert, möglichst nah beieinander haben, um eine hohe Kohäsion zu bekommen und die Idee ist eben, das Problembewusstsein aufzuzeigen. Das haben wir hier in diesem Beispiel gemacht, wir hatten hier eine Raumschiffhülle, die kann Löcher enthalten, das ist der Zustand. Und wir haben eine Reparatureinheit, die kann eben Löcher von dieser Hülle reparieren und wie ich schon erzählt habe, aktuell ist es eben aufgeteilt und es wäre aber besser, man hätte sozusagen in der objektorientierten Designwelt eine Hülle, die intern diese Löcher hat und man kann eben eine Methode aufrufen, dass die Hülle bitte repariert werden soll. Dann wäre die Methode, die auf diesem Wert der Löcher in dieser Hülle arbeitet, viel viel näher dran und man hätte die Möglichkeit, den Zustand auch zu verstecken, also „Information Hiding“ zu betreiben, was ja auch ein Ziel des objektorientierten Designs ist.

Michael Vitz: Genau. Sowas findet man sonst in einem Projekt auch ganz viel. Da findet man Person und PersonUtil und der spannende Teil steckt in der Util-Klasse. Util ist ja auch noch so ein Name, der nichts bedeutet. Er hat eigentlich eine klare semantische Bedeutung, aber man neigt oft dazu, sehr große Util-Klassen zu schreiben, oder?

Simon Harrer: Genau. Es geht aber sogar noch weiter Richtung diese Manager- oder Controller-Klassen, diese klassischen Wörter, die man da so gesehen hat bei uns in den Beispielen.

Michael Vitz: Genau. Das heißt, es ist tatsächlich nochmal diese klassische Idee auch an der Stelle zu zeigen, dass Objektorientierung gerade beides zusammenfügt, ohne direkt mit diesen Hammern „Polymorphie“ und sowas zu machen. Also einfach nur Basis, beide Dinge zusammen zu führen. Dann würde ich vorschlagen, dass wir noch ein drittes nehmen, wo wir schon in der Vorbesprechung Spaß dran hatten, weil das durchaus unterschiedlich zu sehen ist. Du hast gesagt, wir hätten da noch etwas mit Lambda und Methodenreferenzen. Was hat es denn damit auf sich?

Simon Harrer: Das Item, das wir uns da herausgesucht und diskutiert hatten, heißt „Favor Method References over Lambdas“. Mit Java8 kamen ja die Java Streams dazu und eben auch Lambda-Konstrukte. Man bildet ja häufig eine Liste in einen Stream ab und dann filtert man, mappt und dann lässt man sich eine neue Datenstruktur, also eine Liste machen oder über count() zählt man die Elemente oder solche Themen. Und bei diesem Filter muss man ja ein Prädikat übergeben, irgendetwas, das ein Element der Liste auf einen Wahrheitswert abbildet und da kann man eben ganz normal eine Lambda-Expression hineinschreiben. Das ist auch der Standardweg, den die Studierenden machen. Sie lernen: Okay, ich kann hier Streams programmieren und ich kann hier Lambdas hineinwerfen, also schreibe ich das einfach hin. Also Listenelement, Pfeil und dann irgendwie komplexer Code. Und das bleibt meist gar nicht bei einer Zeile, das wird dann auch schnell mal mehr. Vielleicht nicht immer beim Filter, aber oft dann bei map() oder bei anderen Operationen.

Das Problem hierbei ist, dass man das nicht separat testen kann. Man kann immer nur den gesamten Java-Stream, also diesen Block, der da aufgerufen wird, testen, weil das Lambda ist ja in dem Filter versteckt, sozusagen „inline“ definiert, man kommt da irgendwie nicht heran. Man kann das natürlich in eine Variable herausziehen, aber viel eleganter ist es eben, einfach eine Method Reference zu übergeben und das sozusagen als Muster zu sehen: Wenn ich ein Lambda sehe, zu überlegen, ob ich das lieber mit einer Method Reference machen sollte, weil ich diese Method Reference ja separat aufrufen und testen kann und damit die Möglichkeit habe, viel saubereren Code zu schreiben.

Michael Vitz: Letzten Endes trennst du damit ja auch ein bisschen die Zuständigkeiten, weil der Aufruf dieser Liste und des Filters und der Map ist ja letzten Endes sozusagen nur eine logische Verknüpfung und die eigentliche Logik hast du dann schön einzeln in diesen Methoden, die du intern benutzt. Und wenn du beweist, dass die Logik für ein Element funktioniert und die Zusammensteckung korrekt ist, dann musst du gar nicht mehr groß Fachlichkeit bei dem Zusammenstecken testen.

Simon Harrer: Ja, genau, man könnte sagen, man testet praktisch die einzelnen Functions, die man übergibt oder Predicates separat und dann macht man sozusagen einen Integrationstest in der Idee, dass man die irgendwo hineinsteckt und das dann testet in dieser funktionalen Welt mit diesen Streams.

Michael Vitz: Genau. Was mir gerade noch einfällt: Ich sehe auch noch ganz häufig, was der Gewinn daran ist, es so zu machen. Dadurch, dass man eher die Methoden herauszieht, hat man, glaube ich, auch noch den Vorteil, dass man die Methode an einer anderen Stelle vielleicht sowieso nochmal braucht. Und vorher dann eigentlich eine Duplizierung hatte. Das ist etwas, das ich auch schon gesehen habe.

Simon Harrer: Mir fällt gerade sogar noch etwas Drittes ein: Man kann ja dann diesem Code einen Namen geben, das fällt ja vorher weg.

Michael Vitz: Das stimmt, ja. Außer man delegiert sowieso nur, also man macht so etwas wie t führt zu t.getName(), dann ist es klar, aber da ist dann immer die Gefahr, von der du am Anfang sprachst, dass es länger und länger wird.

Simon Harrer: Ja. Die Erfahrung zeigt auch: Es wächst sehr schnell.

Michael Vitz: Wie Code immer. Genau. Du hattest gesagt, dass es immer Doppelseiten sind und es heißt ja „Become a Java Craftsman in 70 Examples“, also 70 mal 2 sind 140 plus ein bisschen Vor- und Nachwort ergeben ungefähr 160 Seiten, das heißt, das ist so in etwa der Umfang des Buches?

Simon Harrer: Genau.

Michael Vitz: Gut. Das heißt, es sollte in vertretbarer Zeit lesbar sein, nicht so dick wie „Domain-driven Design“, das ist glaube ich deutlich dicker.

Simon Harrer: Ja. Es ist glaube ich sehr gut verdaubar, wir haben auch sehr darauf geachtet, dass es sich locker liest, dafür haben wir einen recht guten Editor gehabt, die Dame hat uns immer wieder darauf hingewiesen, das kleine Apostroph immer zu schreiben, damit es im Englischen flüssiger zu lesen ist.

Michael Vitz: Und gibt es irgendwie noch etwas Verstecktes, etwas Lustiges im Buch, wo man dann auch nochmal drüber schmunzeln kann?

Simon Harrer: Ja, wir haben so ein bisschen Humor überall eingebaut und es ist sogar ein Easter Egg versteckt.

Michael Vitz: Das heißt, wenn ihr das finden wollt, müsst ihr natürlich das Buch kaufen.

Simon Harrer: Und sehr detailliert lesen. Es ist wirklich gut versteckt!

Michael Vitz: Das ist auf jeden Fall für mich nochmal eine Aufgabe: Das Buch nochmal in Ruhe zu lesen und das Easter Egg zu finden. Und was mir noch einfällt: Ihr habt ja über die Struktur gesprochen und du hast es auch Items genannt und ich kenne ein Buch aus dem Java-Universum, das auch von Items spricht, das ist „Effective Java“ von…

Simon Harrer: Joshua Bloch.

Michael Vitz: Genau, von Joshua Bloch. Das heißt, ihr seid da ja schon ein bisschen ähnlich, kannst du vielleicht nochmal sagen, was so aus deiner Sicht der Unterschied zwischen den beiden Büchern ist?

Simon Harrer: Ich glaube, der größte Unterschied ist die Zielgruppe. Joshua Bloch ist wirklich für Experten, die können da immer mal wieder drüberlesen und lernen, glaube ich, bei jedem Lesen nochmal etwas, weil er einfach sehr viel, sehr, sehr gut erklärt. Wir sehen uns eher für die Anfänger und Anfänger plus, die vielleicht mit dem Buch noch nicht soviel anfangen können, denen das noch zu abstrakt ist, die da einfach noch nicht mitkommen und erst einmal ein Bewusstsein bekommen wollen dafür, was denn guter Code ist. Und da sehen wir unser Buch eigentlich ganz gut platziert. Wir empfehlen auch explizit am Ende unseres Buches: Lest „Effective Java“, 3rd Edition, das ist ja jetzt erst vor kurzem erschienen.

Michael Vitz: Das heißt als weiterführendes Material, um einfach noch ein paar mehr Anmerkungen zu finden.

Simon Harrer: Genau. Ich glaube, wir haben auch ein paar Elemente, die in eine andere Richtung gehen als bei Joshua Bloch, insbesondere unser letztes Kapitel: „Prepare for the Real World“. Da haben wir viele Dinge drin, die Joshua Bloch nicht behandelt in seinem „Effective Java“ und vorher immer wieder mal Themen, die eigen von uns sind.

Michael Vitz: Okay. Und jetzt habt ihr das Buch fertiggestellt und es ist draußen und man freut sich, glaube ich, dann, wenn man es endlich in physischer Form vor sich hat und selbst darin lesen kann. Habt ihr jetzt genug von dem Thema und vom Bücher schreiben oder habt ihr jetzt schon Ideen, noch etwas Aufbauendes zu machen oder etwas in der Richtung?

Simon Harrer: Ich glaube, wenn man ein Buch geschrieben hat, vor allem auch zu dritt, über ein Jahr hinweg, dann freut man sich erstmal riesig und dann darf man das auch erstmal ein paar Monate sacken lassen und, man nimmt das mal so mit. Wir haben natürlich ganz viele Ideen, insbesondere, weil wir ja auch diesen Java-Concurrency-Kurs gehalten haben. Es gibt ja noch viele Elemente, die wir jetzt hier nicht untergebracht haben, das heißt, es bietet sich natürlich eine zweite Edition an mit einem Kapitel zu Concurrency, da müssten wir nur in die Schublade greifen und das letztendlich machen, das wäre sicherlich sehr, sehr spannend. Ansonsten liegt mir einfach dieses Thema Clean Code und auch „Teaching Clean Code“ sehr am Herzen, wie kriege ich das, gerade bei den Anfängern, besser unter? Da haben wir jetzt auch gemeinsam noch ein bisschen dran geforscht, haben auch ein Paper geschrieben, in einem Workshop veröffentlicht, da versuchen wir jetzt auch mehr zu machen. Einerseits mit statischen Codeanalyse-Werkzeugen in Kombination mit unserem Buch zu arbeiten, dass man bestimmte Probleme automatisiert erkennt und dann eben verlinkt auf eine sehr detaillierte Beschreibung, warum dieses Problem ein Problem ist und wie man es eben beheben kann. Denn das ist noch ein großes Problem bei den statischen Codeanalyse-Tools heutzutage, dass sie eben oft sehr kurze Erklärungen haben, oft fehlt auch wie man es löst oder es wird nur sehr abstrakt beschrieben und man hat auch sehr viele False Positives und in dieser Welt muss man eben leben und da wollen wir gucken: Wie kann man das trotzdem verzahnen, dass man gerade Anfängern, die in dieser Welt irgendwie klarkommen müssen, dass man denen etwas an die Hand geben kann.

Michael Vitz: Aber ich glaube, gerade wenn man in die Richtung der Codeanalyse-Tools geht, dann ist es selbst für einen erfahrenen Java-Entwickler wie mich auch nicht verkehrt, wenn an einem Warning nochmal etwas mehr Prosa steht, was denn jetzt wirklich das Problem ist, weil selbst ich habe das teilweise bei manchen SonarQube-Warnungen, dass ich hinein gucke und eigentlich weiß, was es ist und dann stehen da so 3–4 Worte und dann denkt man sich so: Ja schön, aber das hilft jetzt auch nicht jedem.

Simon Harrer: Ja. Du weißt es eben, aber jemand mit 1–2 Jahren Erfahrungswert, der weiß es halt nicht und das ist echt ein Problem.

Michael Vitz: Ich finde, das ist auf jeden Fall eine gute Idee. Ich glaube, dass die meisten statische Codeanalyse kennen, aber das wird ja auch nicht immer und überall gemacht und es ist glaube ich eine ganz nette Ergänzung für jeden Entwickler mit jedem Know-how. Auch, weil es einem Arbeit bei Code Reviews abnimmt, weil so Dinge einfach schon automatisiert gecheckt sind, das empfinde ich auf jeden Fall als eine super Idee, das in diese Richtung zu erweitern. Haben wir noch etwas vergessen, das die besonders am Herzen liegt?

Simon Harrer: Nein. Ich wollte mich nur nochmal bedanken, am Ende macht man das doch immer so: Meinen beiden Co-Autoren, dem Jörg Lenhard und dem Linus Dietz. Wir haben jetzt, glaube ich, über eineinhalb Jahre an diesem Buch geschrieben, das war eine super Zeit und ich glaube, ich freue mich auf eine zweite Edition, wenn das machbar ist.

Michael Vitz: Es ist schön, wenn man sich danach noch riechen kann und nicht vollkommen zerstritten ist. Super. Ich wollte mich auch nochmal bei dir bedanken, dass du zu Gast warst: Danke dir! Und ich hoffe, ihr habt etwas mitgenommen, habt vielleicht Lust das Buch zu kaufen oder habt festgestellt, dass es einfach nicht für euch gedacht ist, dann hoffe ich aber, dass ihr trotzdem etwas aus dieser Episode mitnehmen konntet und ich hoffe, dass ihr beim nächsten Mal wieder reinhört. Tschüss!

Simon Harrer: Tschüss!