Ort: Xing (Dammtorstraße 30)
Zeit: 08.08.2017 18:30 Uhr
Vortragsfolien: Dropbox (Folien auf englisch)
Kategorie:Qualität
Kevlin ist ein hervorragender Sprecher und versteht es sein Publikum mit Fachwissen und einer gesunden Portion Komik zu unterhalten. Er ist Autor des Buches "97 Things Every Programmer Should Know", das bereits in verschiedenste Sprachen übersetzt worden ist. Dieses Mal sprach Kevlin über die Disziplin, durch die wiederholte Durchführung einer Programmierübung zu lernen. Er zeigte sehr eindrucksvoll wie und was man dabei alles lernen kann. Ich hoffe ich kann es über meinen Beitrag auch nur annähernd so gut vermitteln, wie er in seiner Präsentation.
Auf den Namen des Meetups ("Get Kata") ist er in durch einen Film namens "Get Carter" gekommen. Prinzipiell hat diese Anlehnung kaum etwas mit dem Vortrag zu tun, außer dass er so unterhaltsam war wie ein Prime Time Krimi. Das Wort Kata kommt aus dem Chinesischen und kann Form, Muster, Style oder auch Trainingsübung bedeuten. Basierend auf einem zugehörigen Zitat von Jon Jagger, sprach er davon, dass es bei diesen Übungen nicht vorrangig darum gehe eine Aufgabe abzuschließen (so wie wir es wahrscheinlich eher aus dem Arbeitsleben gewohnt sind), sondern eher darum eine Aufgabe zu meistern. Dabei wird es durchaus der Fall sein, dass man nach einem erfolgreichen Abschluss seine Erfahrungen bedenkt, aber dann sehr bewusst einen ganz anderen Ansatz wählt um neue andere Erfahrungen zu machen. Diese Erfahrungen seien wichtig, um beurteilen zu können, welche der durchgeführten Lösungen am "meisterhaftesten" sind.
Sehr eindrucksvoll zeigte er dies am Beispiel des Pythagoras - einem sehr bekannten Satz aus der Mathematik, mit dem sich die Seiten eines rechtwinkligen Dreiecks berechnen lassen. Die - auch aus meiner Erfahrung - wirklich verbreitetste Illustration des Pythagoras ist die Anzeige der resultierenden Quadrate an den Seitenlängen des Dreiecks (wie bspw. auch auf der deutschen Wikipedia-Seite des zugehörigen Artikels). Leider veranschaulicht diese Version weder die Korrektheit sehr gut noch die Herleitung dieses Satzes. Hierfür gibt es weit bessere Illustrationen. Kevlin zeigte einige von ihnen, aber am besten gefiel mir die Version des "Pythagoras by rearrangement". Diese Version erscheint bspw. als Animation auf der zugehörigen englischen Wikipedia-Seite - Die Tatsache, dass sich diese Herleitung nicht in einem einzigen Bild darstellen lässt, sondern einer Animation bedarf, ist wahrscheinlich der Grund für dessen gehemmte Verbreitung.
Danach ging es zu verschiedenste Versionen des berühmten Katas FizzBuzz - Die TDD-Entwickler (TDD = Test Driven Development) werden es kennen. Bei FizzBuzz kommt es unter Verwendung der Zahlenreihe von 1 bis 100 darauf an, dass man jede durch 3 teilbare Zahl durch das Wort "Fizz" ersetzt und jede durch 5 teilbare Zahl durch "Buzz". Alle Zahlen, die durch 15 (also sowohl durch 3 als auch durch 5) teilbar sind, müssen mit "FizzBuzz" ersetzt werden. Dies ist eine recht einfache Übung, an der man aber dennoch eindrucksvoll erkennen kann, welcher Blumenstrauß an korrekten Lösungen zustande kommen können. So wurden Programmierkonstrukte verwendet von einer Folge von Abfragen, durch die gemeinsam die Lösung entsteht oder Abfragen, bei der immer genau eine die jeweils korrekte Lösung zur Verfügung stellt. Ebenfalls gab es Lösungen mit syntaktischen Anpassungen, wie bspw. der Verwendung des in vielen Programmiersprachen verfügbaren ternären Operators oder dem Verwenden von Ranges (Groovy). Jedoch ist auch das Initialisieren getrennter Listen (eine für Fizz und eine für Buzz) möglich, aus denen das Ergebnis dann resultiert (z.B. ergibt 15 einen Treffer in der Fizz- als auch in der Buzz-Liste und ergibt somit FizzBuzz). Wie man die Implementierung sehr eindrucksvoll auf die Spitze treiben kann, zeigt die über GitHub verfügbare Version von FizzBuzzEnterpriseEdition (Java-Version). Diese ist bereits in den verschiedensten Programmiersprachen entstanden und sind ebenfalls alle über GitHub verfügbar. Ich finde diese Versionen sollten jedem Architekten einmal vorgeführt werden, um ihnen einen Denkanstoß zu geben, wie viel architektonische Möglichkeiten eine Anwendung wirklich benötigt.
