Tobias
Herzlich willkommen zum Sandpapier, dem regelmäßig unregelmäßigen Podcast von Sandstorm. Wir sprechen über Themen, Herausforderungen und Experimente aus unserem Alltag als Softwareunternehmen. Heute haben wir uns das Thema Softwarequalität und Qualitätsverbesserung vorgenommen. Wir, das sind heute der Theo, hallo Theo, Moin, der Florian, auch Klaus genannt, hallo und der Tobias, das bin ich, hallo zusammen. Das Thema Softwarequalität. Wie viele Podcastfolgen kann man dazu machen? Alle. Gibt es bestimmt eigene Podcasts zu. Warum ist das Thema für uns wert, drüber zu sprechen und vor allem auch eine eigene Podcastfolge zuzumachen? Wir haben ja, wenn ich ein bisschen zurück schaue, wir haben viel über unser 2028 Ziel in den letzten Podcastfolgen gesprochen und ich habe mir gedacht, hey, lass uns mal wieder was Technischeres machen und eine Sache, die wir dieses Jahr stark fokussiert haben, war eben das Thema Qualität und Qualität zu verbessern. Das war auch ein wichtiges Thema auf unserem Retreat im März. Zumindest war das für mich so. Und wir haben ja tatsächlich einiges geändert und experimentieren. Für mich das das prägnanteste ist, dass wir die Fragen in unserer Morgenrunde erweitert haben. Morgenrunde? Sollte ich das kurz erklären?
Theo
Ja, vielleicht nochmal so ganz grob zusammenfassen hilft, glaube ich.
Tobias
Morgenrunde. Das ist unser tägliches Stand-up. Jetzt muss ich Stand-up erklären. Also im Team unser tägliches Sync-Meeting.
Theo
Ich mach das großartig, glaube ich. Das ist schlimm, wenn man so ein komplett eigenes Vokabular hat, ne?
Tobias
ist wie eine eigene Sprache. Vielleicht müssen wir eine Folge zum Glossar machen. Ja, also im Team haben wir ein tägliches Meeting morgens um neun, wo wir uns abstimmen, was steht für uns an. Und da geht das um mit einer Reihe von Fragen. Und wir haben die Fragen erweitert zusätzlich zu, was hat mich gestern glücklich gemacht und frustriert, um dem emotionalen Raum zu geben. Und die Frage, was mache ich heute, um den Blick darauf zu lenken, habe ich irgendwo Abstimmungsbedarf, den ich jetzt, wenn alle kurz beisammen sind, sehr schnell und effizient klären kann. Haben wir das erweitert um Fragen zur Verbesserung unserer Qualität im Sinne von, helft mir, die Fragen sind, möchte jemand ein synchrones Code Review machen, bekommen, sich abholen? Möchte jemand Pair Programming machen? Und das dritte ist Shaping. Ich glaube, den Begriff müssen wir dann auch nochmal erklären. Ja, ja. Und dann, das machen wir quasi am Ende der Morgenrunde, wird nochmal diese Frage in den Raum geworfen und dann können sich sozusagen Leute zusammenfinden, um gemeinsam an Dingen zu arbeiten. Das hat sich für mich, das ist so für mich das Offensichtlichste, was sich geändert hat, was sozusagen ja jeden Tag passiert in der Morgenrunde. Und wir hatten gerade in der Vorbesprechung, haben ja drüber gesprochen, wann wir damit angefangen haben. Und Theo, du hattest so gesagt, für dich kam das vermutlich aus dem Thema Morgenrunden-Experiment. Ich weiß gar nicht, ob wir schon mal eine Folge, doch zum Thema Meetings hatten wir auch schon mal eine Folge gemacht. Ja, da hatten wir eine Folge.
Theo
Ja, da hat er mir eine Folge gemacht. Ich hatte auch gerade überlegt, da können wir dann, glaube ich, in den Show Notes nochmal verlinken.
Tobias
Genau, aber wir hatten vor Weihnachten, also es ist auch schon fast ein Jahr her, eine Retrospektive zum Thema Morgenrunde und Wochenrückblick gemacht und da kamen Experimente raus und du warst in der Gruppe mit, die sich mit dem Experiment beschäftigt hat. Dazu mal ganz kurz Theo, was war jetzt der Anknüpfungspunkt mit diesen Qualitätsgeschichten?
Theo
Der Anknüpfungspunkt von der Morgenrunde, ehrlich gesagt, ich kriege es nicht mehr so hundertprozentig rekonstruiert. Aber eine Sache, die wir zumindest festgestellt haben, ist, dass so dieses ganze Thema Codequalität und in dem Fall jetzt Reviews als erster Schritt, dass das, sage ich mal, zwar theoretisch in unserer Kultur verankert ist, aber ganz oft im Tagesgeschäft liegen bleibt. Und deswegen haben wir überlegt, wie können wir das irgendwie präsenter machen, sodass wir, sage ich mal, alle mitbekommen, hey, da passiert was und es gibt die Möglichkeit, sich das zu holen. Und wie reden wir sozusagen einfach mehr darüber? Und das war dann letztendlich der Grund, warum wir diese Frage einfach erst mal nur zum Thema Code Reviews, also möchte jemand ein synchrones Code Review haben, mit aufgenommen haben und auch in dem Kontext gleich noch darüber gesprochen haben, was ist denn der Unterschied zwischen einem synchronen und einem asynchronen Code Review und wann benutzt man vielleicht was. Und genau, dann haben wir versucht, das sozusagen im Team dadurch so ein bisschen zu streuen und einfach durch diese regelmäßige Wiederholung jeden Morgen animieren wir uns einfach gegenseitig tendenziell stärker dazu, das auch wirklich einzufordern und diese Code Reviews zu machen. Auch wenn wir durchaus Phasen hatten, wo es mal sehr still war, wenn die Frage kam, aber inzwischen ist es eigentlich so, dass fast jeden Morgen jemand was sagt, auch weil wir die impliziten Dinge, die sowieso im Hintergrund passieren, inzwischen auch explizit machen. Was meine ich damit? Code Reviews haben auch davor schon stattgefunden, auch vielleicht, wenn es quantitativ nicht so war, wie wir es uns manchmal gewünscht hätten. Und als wir die Frage in den Raum gestellt haben, haben wir sie erst mal nur so verstanden nach dem Motto, wer möchte denn jetzt ein Code Review haben. Und gerade Leute, die sowieso in einem Projekt zusammen, in einem Team arbeiten, haben das quasi hinter den Kulissen geklärt und es damit nicht explizit gemacht. Und inzwischen sind wir an einem Punkt angekommen, wo auch diese Leute einfach sagen, hey, ich mache mit Person X oder Y ein Code Review oder eben zusätzlich ich shape mit der Person etwas oder ich schreibe Tests mit der Person oder mache eben Per-Programming. Das machen wir jetzt zusätzlich explizit und damit haben wir diese Stelle so ein bisschen aufgelöst. Das beantwortet glaube ich deine Frage nicht so hundertprozentig, Tobi, aber das ist so die ganz grobe Richtung, aus der wir da gekommen sind.
Tobias
Ich würde an der Stelle flohern, Klaus, du hast heute deine Premiere hier im Podcast, deswegen würde ich die Gelegenheiten nutzen. Möchtest du dich kurz vorstellen, mal sagen, was ist dein Hintergrund für die Zuhörerinnen und Zuhörer?
Klaus (Florian)
Ja, super gern. Also ich bin der Florian. Da es bei Sandstorm schon Florian gibt, bin ich der Klaus. Beides ist fein. Genau, ich bin seit September 2021 bei Sandstorm, also jetzt mittlerweile ein Jahr und Monat. Genau, ich komme aus der, also ich bin kein Studierter, kein akademischer Informatiker, sondern sozusagen auf dem zweiten, dritten, vierten Bildungsweg dahingekommen und ja, genau, entwickle jetzt Software.
Tobias
Seit wieviel Jahren, würdest du sagen, machst du das professionell?
Klaus (Florian)
Ich würde sagen, seit 2020 professionell und seit 2019, genau, in Ausbildung, in Anführungszeichen, und davor immer mal Kleinigkeiten, ohne so richtig zu wissen, was und wie und warum. Genau. Ich bin noch relativ frisch.
Tobias
Und jetzt hast du gesagt, du bist seit einem guten Jahr, bist du bei Sandstorm und hast sozusagen das, was Theo gerade beschrieben hat, dieses Experiment, diese Veränderung der Morgenrunde ja mitbekommen, als du angefangen hast, gab es diese Frage nicht am Ende der Morgenrunde und jetzt, wie Theo gerade beschrieben hat, ist sie, weiß ich nicht, ein täglicher Bestandteil. Wie blickst du darauf, ist es so, okay, da hat sich was geändert, mache ich halt mit oder sagst du, was löst das in dir aus?
Klaus (Florian)
Genau. Also für mich hat das Erweitern der Morgenrunde, also gerade den letzten Teil, den Theo angesprochen hat, unglaublich viel Impact gehabt, weil ich vorher nicht wusste, wie viel tatsächlich Reviews passieren, wie die Abstimmung so hinter den Kulissen ist. Genau, das explizit machen hat mir insofern geholfen, dass ich gemerkt habe, okay, hier passiert unglaublich viel dahingehend und es ist total okay, Code Reviews einzufordern, weil vorher, wenn man so in seinem Projekt rumdümpelt, hat man so das Gefühl, die anderen haben auch wahrscheinlich gerade alle ziemlich viel zu tun, es ist jetzt wahrscheinlich blöd, die zu stören und so. Aber dieses explizit machen hat halt insofern geholfen, dass ich gemerkt habe, okay, hier passiert viel und es ist echt okay, das zu callen auch. Das zu callen, was heißt das? Also das anzumelden, dass man jetzt mal konkret gerne einen Code Review hätte. Genau. Und das ganz öffentlich in der Morgenrunde, ohne jetzt zu überlegen, ah, wen schreibe ich denn da jetzt mal an? Bei den Fragen, die vorher in der Morgenrunde waren, was hat mich happy gemacht, was frustriert da? Die sind super für eine Tendenz, so um rauszukriegen, ah, okay, hier ist gerade eine Person wahrscheinlich gerade total im Fokus und hat wahrscheinlich wenig Zeit heute. Aber genau, also dieses Anmelden hat es halt einfach super einfach gemacht, da zu einem Code Review zu kommen oder zu einem Pair Programming, was vorher für meinen Begriff deutlich schwieriger war.
Tobias
Für mich hat eine ganz große Rolle gespielt. Theo, du bist ja schon ein paar Jahre länger dabei, dass wir schon seit Jahren uns über das Thema Codequalität und wie verbessern wir die Qualität von der Software, die wir entwickeln? Wie verbessern wir das? Das spielt ja schon lange eine Rolle. Also das ist ja nichts, was wir uns jetzt im Jahr 2022 zum ersten Mal überlegt haben. Auch zum Beispiel das Thema Pair Programming. Da haben wir schon vor Jahren im Wochenrückblick mal drüber gesprochen und auch gesagt, hey, guck mal ganz praktische Anleitung, so und so kann das funktionieren. Pair Programming kann unterschiedliche Rollen haben. Und ich glaube, das hat in manchen Settings gut funktioniert, in anderen nicht, weil häufig so eine, wie sagt man, das Klaus, du hast es so ein bisschen beschrieben, so dieses, kann ich jemanden stören? Die anderen sind ja auch beschäftigt. Ist das zusätzlicher Aufwand, der sozusagen im Projekt untergebracht werden kann oder nicht? Da war so ein gewisser Vorbehalt, glaube ich, da bei manchen. In manchen Settings hat das funktioniert, in anderen nicht. Und für mich war das Retreat, was wir im März dieses Jahres gemacht haben, wo wir uns ja jedes Jahr für eine Woche als Firma irgendwo ein Haus mieten und mit uns selbst beschäftigen, im Sinne mit unserer internen Verbesserung und nicht an Kundenprojekten arbeiten. Da haben wir uns ganz explizit dieses Jahr auch weniger Themen vorgenommen, um zu sagen, hey, was müssen wir denn tun, um zum Beispiel dieses Qualitätsthema richtig auf die Straße zu bringen? Und das, Klaus, was du gerade beschrieben hast, das ist für mich ein schönes Beispiel dafür, da hat es funktioniert, dieses explizit machen, dieses Zeigen, es passiert und es ist erwünscht. Wisst ihr, was ich meine? Es ist nicht normal gesagt worden und dann, wie wird es denn jetzt tatsächlich gelebt, gerade Florian, Klaus, für dich als Neusandstormer das zu sehen? Ich glaube, da hat sich viel für uns verbessert tatsächlich.
Theo
Ja, auf jeden Fall sehe ich auch so. Ich glaube, das ist nach wie vor natürlich ein Prozess, also das ist nichts, wo es, glaube ich, so ein totales Ende gibt. Aber ich habe auch gerade in dem letzten Jahr sind mir auch da ganz viele Sachen begegnet oder Dinge, die ich reflektieren konnte, was funktioniert für mich, was funktioniert für mich nicht so gut. Gerade so in diesem Thema Per Programming und Synchrone Code Reviews. Beschreib das mal, ja? Beschreib mal deine Erfahrung. Ja, also ich habe für mich ganz grundsätzlich festgestellt, dass ich Per Programming, wenn es sich einrichten lässt, meistens noch lieber mag als nur ein Synchrones Code Review. Wir sollten dann, glaube ich, nachher nochmal ganz kurz auch erläutern, was der Unterschied ist. Asynchrones, Synchrones Code Review. Genau, aber ich bleibe mal ganz kurz erstmal beim Per Programming. Und ich glaube, früher hatte ich auch da so diese ganz klassische Projektmanagementangst, dass, wenn wir zu viel Per Programming machen, dann akkumuliert man halt in Anführungsstrichen doppelt so viele Stunden. Genau, die Milchmädchenrechnung ist ja nur zwei.
Tobias
Beschreib das mal, beschreib mal deine Erfahrung. Ja, also ich habe für mich ganz grundsätzlich festgestellt, dass ich per Programming, wenn es sich einrichten lässt, meistens noch lieber mag als nur ein synchrones Code Review. Wir sollten dann, glaube ich, nachher nochmal ganz kurz auch erläutern, was der Unterschied ist, asynchronous, synchrones Code Review. Genau, aber ich bleibe mal ganz kurz erstmal beim Per-Programming und ich glaube früher hatte ich auch da so diese ganz klassische Projektmanagement Angst, dass wenn wir zu viel Per-Programming machen, dann akkumuliert man halt in Anführungsstrichen doppelt so viele Stunden. Genau, die Milchmädchenrechnung ist ja nur zwei entwickelnde Arbeiten zusammen, also verdoppelt sich der Aufwand.
Theo
Richtig, aber meiner Erfahrung nach ist das typischerweise eher nicht der Fall, sondern – also ja, man braucht vielleicht etwas länger als eine einzelne Person, aber dafür ist die Qualität in der Regel um ein Vielfaches höher, plus man spart sich eigentlich auch im Nachgang dieses synchrone Code Review, weil das per Programming selbst ist schon ein Prozess des Code Reviews. Und man kommt quasi im Dialog oft viel, viel besser zum Ziel. Was ich auch festgestellt habe, ist, dass es trotzdem Situationen gibt, wo per Programming tendenziell nicht so gut funktioniert. Das ist oft dann, wenn die Tasks, sage ich mal, also die Aufgaben, sage ich mal, etwas stupider sind oder eine Person so klar weiß, was sie tun möchte und muss, dass es so eine Tendenz dazu gibt, dass eine Person dann einfach nur noch daneben sitzt und so ein bisschen zuguckt.
Tobias
Ich würde das mal formulieren als, ich kann das jetzt hier runterschruppen, du musst mir nicht dabei zugucken.
Theo
Genau, und das ist so der Punkt, wo ich einfach gelernt habe, selbst immer mal zu reflektieren. Also auch während ich dann in einem Pair Programming sitze, im Zweifelsfall, zu sagen, hey, du, ich schalte hier gerade ab, ich habe das Gefühl, du brauchst mich eigentlich gar nicht. Und das sind dann oft auch so Situationen, wo es manchmal reicht, vorne ab über ein Konzept einfach ausführlicher zu reden. Und wenn das Konzept klar ist, ist das eigentliche Tunen meist gar nicht mehr so problematisch. Oder, also auch da ist natürlich dieser Code Review Aspekt immer noch relevant, aber da muss man, glaube ich, so ein bisschen aufpassen. Und was ich gerade in dem Bereich noch so ein bisschen lernen, optimieren, wie auch immer, möchte, ist, dass ich dieses Konzept des, es gibt so ein Pair Programming, das Konzept des Navigators und des, na, wie heißt das andere, ich komme gerade nicht drauf? Drivers. Drivers, danke, genau. Mit anderen Worten, eine Person ist sozusagen die ausführende Person, die im Grunde in erster Linie das hinschreibt, was der Navigator sagt, also der Navigator sagt, schreibe bitte in Datei XY diese und jene Zeile Code und jetzt gehe ich in die andere Zeile und diese Rollen sollten in regelmäßigen Intervallen wechseln, das ist so, wenn man ganz klassisch Pair Programming by the Book quasi macht. Und ich glaube tatsächlich, dass ich das in meinen Pair Programming Sessions noch ein bisschen zu wenig mache, aber ich glaube, dass es helfen würde, so Situationen zu vermeiden, die eine Person dann vielleicht doch mal eine Tendenz hat, abzuschalten irgendwie und das ist so ein Ziel, was ich noch habe, da etwas besser zu werden. Genau, ein Tool, was im Kontext mit Pair Programming uns extrem geholfen hat in meinen Projekten ist testgetriebene Entwicklung, aber da würde ich vielleicht auch später einfach nochmal was zu sagen. Genau, vielleicht ganz kurz, bevor wir nochmal dieses Thema Code Reviews erstmal nochmal etwas konkreter beleuchten, wie ist es denn bei euch? Ich meine Tobi, du bist jetzt nur unser Top Secret Software Entwickler, also du bist angeblich kein Software Entwickler, aber fickst ständig irgendwelche Bugs und du machst ganz oft Pair Programming mit irgendwelchen Leuten und Klaus, du bist ja auch die ganze Zeit dabei, wie ist denn, was das betrifft, eure Erfahrung so gewesen?
Tobias
Ich würde, Klaus, da mal das Wort tatsächlich geben. Wie war es mit deiner Erfahrung im letzten Jahr?
Klaus (Florian)
Ich versuche einen ganz kurzen Rollback, ich war vorher, als ich das erste Mal als Softwareentwickler angestellt war, war ich sozusagen der einzige Entwickelnde, der so ein Essenbestellsystem für Kindergärten entwickelt und dann sozusagen gemaintant hat die ganze Zeit. Das bedeutet, ich hatte null Code Reviews, null Pair Programmings und wenn ich dringend eins brauchte, dann habe ich jemanden bei Sandstorm gefragt, ich kannte nämlich schon einen, der hier gearbeitet hat, Manu, der hat dann in seiner spärlichen Freizeit dann ab und zu mal drüber geguckt und als ich hier angefangen habe und dann nach dem Onboarding sozusagen ins erste Projekt geworfen wurde, ging das superschnell los und ich habe das erste Mal jemanden gesehen, der meinen Code kommentiert hat und das ist so, das ist so ein … War das ein Kulturschock? Das war ein Kulturschock tatsächlich, aber so positiv, obwohl, also die Tendenz ist so, gerade wenn man so privat noch so Musik macht und man schmeißt immer mal so einen Release raus oder so und dann schreibt jemand drunter und es ist so, also das hättest du verbessern können, das hättest du verbessern können, das geht noch besser, dann fühlt sich das ein bisschen an wie ja, okay, ich höre halt die CD und genieße es oder halt nicht, aber das ist ja bei Code fundamental anders, also hier geht es ja, es geht ja wirklich darum, den Code zu verbessern und da ist ja jede Kritik wirklich super, super hilfreich und das habe ich superschnell gemerkt, dass das mir wahnsinnig viel gebracht hat, dass sich das Lerntempo wahnsinnig erhöht hat im Vergleich zu vorher und dass ich eigentlich nur davon profitiert habe. Tatsächlich.
Tobias
Kannst du sagen, wie oder warum das so ist, dass sich dein Lerntempo dadurch verändert hat oder dass dieses Mindset, jetzt wird an dem, was ich da gemacht habe, rumgekriddelt, das ist es ja genau nicht, was du beschrieben hast, sondern du hast es gerade als sehr positives beschrieben, hatte ich das Gefühl? Ja. Danke.
Klaus (Florian)
Ja, unbedingt. Also vorher sind mir oft Fehler, als ich allein entwickelt habe, sind mir Fehler oder Ungenauigkeiten oder mal vergessen, irgendwas Nullsafe zu machen oder so. Das ist mir später auf die Füße gefallen. Und dann gibt es ein konkretes Problem. Im Alltag fällt irgendwas aus und dann muss es schnell gefixt werden, dann ist der Stresspegel unfassbar hoch und dann sucht man, sucht man und findet vor lauter Bäumen den Wald nicht. Und das ist, also das einfach vorher zu sehen, dass Dinge passieren können und hier von der Erfahrung von anderen Entwicklenden zu profitieren, das ist unerlässlich. Also es ist wirklich, wirklich hilfreich.
Theo
Ist aber spannend, dass du gerade die Null-Safety als Beispiel anführst, weil ich tatsächlich behaupten würde, dass weder Per-Programming noch Code-Reviews wirklich gute Tools sind, um solche Sachen aufzufangen. Also im Einzelfall kann das sicherlich mal klappen, aber ich würde fast behaupten, dass insbesondere Code-Reviews eher dazu tendieren, dass solche Sachen im Service-Fall übersehen werden. Hast du wirklich die Erfahrung gemacht, dass du öfter solche Sachen damit catchen konntest?
Klaus (Florian)
Nee, ich hab an die Zeit gerade zurückgedacht, was, also, ich hab, in so einem Prot-Inzident hatte ich halt im Kopf, wo ich überhaupt nicht wusste, was eigentlich los ist, und da war irgendwo in tieferer Ebene irgendwas nicht null safe. Und ich wüsste jetzt bei meiner Arbeit bei Sandstorm, dass wenn ich den Code ins Review gegeben hätte, dass jemand gesagt hätte, hier an der Stelle, guck mal, guck doch da mal bitte genau hin. Echt? Okay. Also, im Sch-
Theo
Ich behaupte von mir, dass die Chance durchaus relativ hoch ist, dass ich das in deinem Code nicht sehen würde, wenn du mir den Code zeigst.
Tobias
Ich glaube, das spricht einen guten Punkt an. Ob per Programming oder Code Reviews, das ist ja kein, ich mach das und dann passieren keine Fehler mehr Thema, sondern Theodor hat es wirklich von uns gesagt. Ich nehme jetzt mal den schönen Begriff, kontinuierlicher Verbesserungsprozess, Continuous Improvement und wir lernen ja aus unseren eigenen Fehlern – toi, toi, toi, Klopf auf Holz – das Beispiel von Klaus, wenn du sagst, da ist mir mal so ein Null-Safety-Thema voll auf die Füße gefallen, das hast du jetzt halt im Hinterkopf und guckst damit drauf und Theo vielleicht andere Sachen und sagt, oh, Null-Safety würde ich jetzt im Code Review wahrscheinlich, könnte mir durchrutschen sozusagen. Aber wir machen ja dieses Qualitätsthema, um Schritt für Schritt besser zu werden.
Theo
Ja, also ich bin da grundsätzlich bei euch. Ich glaube nur, das Problem ist so ein bisschen, dass man sich darüber bewusst werden sollte, welche Erwartungshaltung man realistisch an bestimmte Methodiken und Tools sozusagen stellen kann. Und ich glaube, das Code Review ist nicht besonders gut dafür geeignet, tatsächlich fundamentale Fehler im Code zu finden, insbesondere dann, wenn man vielleicht projektübergreifend Code Reviews macht. Also sprich, wenn ich sozusagen vielleicht nur bis zum gewissen Grad vertraut bin mit der Technologie, die du benutzt und auch deine Domäne nur bis zum gewissen Grad kenne, dann ist die Chance, dass ich diese Art von Fehler nicht sehe, ziemlich groß. Und die Wahrscheinlichkeit, dass du das selber findest, ist viel, viel größer. Ich glaube, dass diese sogenannten synchronen Code Reviews, und ich würde jetzt dann im Anschluss vielleicht wirklich gleich mal ganz kurz den Unterschied erklären, die helfen vor allen Dingen dabei, Code verständlicher zu machen. Also mit anderen Worten, anders, ich sage einmal ganz kurz den Unterschied. Also ein typisches Code Review in den meisten Unternehmen, Organisationen, wie auch immer, ist meiner Ansicht nach das asynchrone Code Review und das funktioniert typischerweise so. Jemand löst ein Problem, sei es er oder sie baut ein Feature oder fixen einen Bug und pusht dann seinen Code in eine Ressourcen, Source Code Verwaltung, wie meinetwegen GitHub oder GitLab. Und dort wird dann ein Merchrequest erstellt und da sieht man die ganzen Code Änderungen und die werden einer Person X quasi zum Review gegeben und die sucht sich dann irgendwann einen Sight Slot, in dem sie den Code sich einfach anguckt und dann der Kommentare dran schreibt. Diese Art Code Review ist nach meiner Auffassung so ein bisschen, stammt die vor allen Dingen aus der Open Source Welt, wo das notgedrungen so ist, weil typischerweise die Leute international verteilt sind zu völlig anderen Zeiten an diesem Code sitzen, weil sie es meistens auch in ihrer Freizeit tun und es dadurch sozusagen relativ schwer ist eine synchrone Review Situation zustande zu bringen. Für Unternehmen würde ich behaupten, dass diese Art Code Review in den meisten Fällen gar nicht so besonders gut geeignet, weil die Teams da viel enger miteinander arbeiten und eine synchrone Situation herstellen können. Kommen wir also zum Synchronen Code Review. Was ist das? Ein Synchrones Code Review ist ein Review, wo sich mehrere Personen zusammenfinden, typischerweise die eine Person oder mehrere Personen, die den Code geschrieben haben und eine Person, die den Code sozusagen noch nicht gesehen hat und dann redet man über den Code und guckt ihn sich gemeinsam an. Da gibt es verschiedene Varianten, wie das passieren kann. Meiner Erfahrung nach funktioniert es meistens so, dass ich beispielsweise jemand anderem erkläre, was ich da getan habe und da ist meine Reihenfolge meistens die, dass ich erstmal ganz grob, wenn die Person das Projekt vielleicht gar nicht kennt, erkläre ich, wo befinden wir uns denn hier gerade, was ist das für ein Projekt. Dann gehe ich ein bisschen auf die Problemstellung ein. Dann zeige ich typischerweise das, was ich getan habe, erstmal sozusagen in der Ausprägung, also sprich nicht den Code selbst, sondern ich zeige, wenn es jetzt angenommen, ich habe eine Webseite und habe da ein Feature eingebaut und eine Web App, dann zeige ich erstmal das Feature, wie es an sich funktioniert, dass die Person so eine grobe Vorstellung davon hat, worum es geht und dann steige ich in den Code ein und dann erkläre ich dieser Person, was ich da getan habe, erkläre bestimmte Stellen, die meinetwegen besonders kompliziert waren oder warum ich bestimmte Dinge gemacht habe und die Person kann Fragen stellen. Manchmal lohnt es sich auch, wenn die Person selbst erstmal auf den Code guckt und selber dann mir Fragen stellt und das, was für mich dann den Mehrwert schafft, für mich ganz persönlich und was ich in der Lage bin auch zu finden, ist Nachvollziehbarkeit des Codes, also sprich, ich kann erkennen, sind da genügend Kommentare, verstehe ich, was da steht, könnte ich jetzt ohne, dass die Person mir das erklärt, auch nachvollziehen, was da gerade los ist in diesem Code. Was ich in der Regel, ich sage mal, es sei denn, es ist ganz, ganz offensichtlich, nicht finden werde, sind eben solche Null-Safety-Issues oder so. Dafür ist aus meiner Sicht halt eine typ-sichere Sprache beispielsweise hilfreich oder wenn die Sprache eben kein gutes statisches Typ-System hat und keinen Compiler, dann wenigstens eine sehr, sehr gute Unit-Test-Abdeckung in dem Fall, die sozusagen solche Dinge entdecken kann, wobei ich da den Compiler an der Stelle für solche Probleme wie Null-Safety tatsächlich vorziehen würde. Lass mich noch nicht zu... Ja, sorry, ich schweife ab. Ja, genau, also...
Klaus (Florian)
Genau. Punkt. Genau. Ja, sorry. Ich schweife ab. Ja, genau. Genau. Also, darf ich hier reingrätschen? Unbedingt. Und trotzdem ein flammendes Plädoyer dafür halten, warum die Synchrone Code Review sowas dann doch kann. Das Ding, also voll d'accord, ich bin voll d'accord mit allem, was du sagst, das Ding ist bei dem Synchrone Code Review, dass du, wenn du das einforderst, legst du auch die Regeln fest für das Synchrone Code Review. Und wenn, also ich hatte beides schon, ich habe auch so einen Default, der ist so ähnlich wie deiner, wie so ein Synchrone Code Review funktionieren kann, soll, ich zeige das Feature und dann gucken wir in den Code zusammen rein. Und manchmal habe ich das aber, dass ich was ganz Explizites davon haben will, von diesem Code Review und sage, ich möchte hier gerne mit dir zusammen nochmal in die Logik reinschauen, ob ich hier irgendwas, ob hier, ob das in Ordnung so ist. Und dann ist für die Person, die den Code Reviewed auch klar, wo der Fokus grad liegt.
Theo
Darf ich hier reinkritschen? Unbedingt.
Klaus (Florian)
Und im Zweifel würde ich, also das ist jetzt noch nicht vorgekommen, aber ich würde dann im Zweifel sogar für zwei Themen, also für denselben Code, vielleicht einmal die Logik mit jemandem anschauen und vielleicht jemand anders nochmal drüberschauen, der dann, der den Code noch gar nie gesehen hat. Also wenn es mir ganz wichtig wäre, ich habe das Gefühl, dass die erste Runde immer reicht, deswegen ist es zu der zweiten Runde noch nie gekommen, aber wenn dann jemand sich in die Logik rein denkt und dann auch sozusagen befangen ist vom Code, dann würde ich tatsächlich das nochmal vielleicht zu einem asynchronen Review geben.
Theo
Ich finde es total spannend. Ich glaube, den Blickwinkel vorher klären, das ist ein total gutes Tool. Ich glaube, man muss trotzdem vorsichtig sein, dass man sich da nicht falschen Illusionen hingibt. Weil die Person, die deine Logik und den Code am besten kennt, bist in der Regel du. Das heißt, die Chance, dass du diese Dinge findest, ist viel, viel größer, als dass es jemand anderes findest. Meiner Erfahrung nach zumindest. Ich kann mich nur an sehr wenige Code Reviews erinnern, die ich gegeben habe, wo ich in der Lage war, solche Sachen einfach in einem größeren Ausmaß zu entdecken.
Tobias
Ich glaube, das ist gar nicht zwingend das, was erwartet wird, sondern ich glaube, dieser große Schritt ist schon, ich committe nicht einfach und pushe und dann fire and forget, und dann ist es nicht mehr meine Verantwortung, das wird von irgendjemanden reviewt und kommt irgendwann zu mir zurück, sondern es ist dieses, ich habe nochmal diesen expliziten Moment und jetzt führe ich nochmal jemanden durch. Theo hat es vor uns gesagt, diese Nachvollziehbarkeit von dem Code, diese Verständlichkeit von dem Code, der da entstanden ist, wenn dann jemand sagt, warte mal hier, Variablenbenennung, Struktur und Dinge, die mir so auffallen, die es Zukunfts Theo leichter machen mit seinem eigenen Code wieder umzugehen, die helfen ja auch ungemein weiter, das ist ja eine Erfahrung, die wir in den letzten Jahren bei Sandstorm ganz viel gemacht haben, je länger unsere Projekte existieren, dass es sich total lohnt, in diese Qualität reinzugehen und die Qualität sozusagen permanent da hoch zu halten, weil wenn wir heute uns Projekte angucken, die wir vor 5 Jahren oder so gemacht haben und dann sehen, hui hui hui, es hat sich einfach die Zeit weiter gedreht. Jetzt bin ich ein bisschen abgeschwoffen, ich war bei diesem Aspekt, ich gucke es mir halt nochmal an und nicht nur so, hier ist mein Merge und das sind die Dateien, die ich geändert habe, das ist mein Feature, da ist jetzt nichts drin, was da nicht reingehört, sondern dieses, ich erkläre jemanden nochmal die Logik und im Zweifelsfall komme ich ja dann auch an Punkten vorbei, wo ich sage, aha, weil ich ja das am besten kenne, genauso wie du es gerade beschrieben hast und vielleicht fällt mir dann noch auf, ah warte mal, vielleicht hätte ich es doch lieber so machen sollen. Ist da schon mal was bei euch rausgekommen, wo ihr dann gesagt habt, und dann seid ihr nochmal hingegangen und habt es angepasst?
Theo
Glaube ich persönlich, bei mir in der Vergangenheit waren die meisten Sachen, die bei mir nach einem Code-Review rausgekommen sind, tatsächlich, dass ich an irgendeiner Stelle noch Kommentare oder so vergessen habe. Also es ist tatsächlich selten, dass ich den Code angefasst habe, behaupte ich mal. Aber wie gesagt, ich präferiere ohnehin den Per-Programming-Ansatz, aber meistens war es eher wirklich ein Verständlichkeitsthema, was bei mir rausgekommen ist. Ich würde gleich erstmal an Klaus geben, ich würde dann tatsächlich ganz gern nochmal kurz erklären, warum mich Klaus Null-Safety-Issue so getriggert hat, weil ich glaube, ich weiß nicht, was das Problem ist. Pass auf, das Null-Safety-Ding, das ist nur ein Punkt.
Klaus (Florian)
Pass auf, das Null-Safety-Ding, das ist nur ein Punkt. Ich bin ja nicht sicher, ob jemals in einem Code Review rausgekommen ist, dass das Null-Safety-Problem da war. Aber es könnte halt theoretisch ein Problem sein, aber es ist austauschbar. Das spezielle Issue ist total austauschbar. Ja, das ist schon klar. Genau. Also klar kann das ein Compiler besser als, ist schon logisch, als ein Mensch. Aber ja, genau, bei mir, ob da schon mal was rausgefallen ist. Also üblicherweise fallen die ersten Sachen raus, wenn ich mich auf das, also selbst für ein Code Review, das versuche ich trotzdem schon mir wenigstens fünf Minuten vorher, das einmal, wie ich das jetzt machen würde, wie ich das jetzt erklären würde, mir so klar zu machen. Und dabei passieren tatsächlich schon die ersten Verbesserungen. Das ist so meine Erfahrung in der Vorbereitung. Du schaust das nochmal durch und denkst dir, ja, das habe ich hier deshalb gemacht. Und was habe ich hier gemacht? Was? Warum? Das ist so üblicherweise der Modus. Da passiert schon sozusagen das erste Aussieben.
Theo
Genau. Ja. Es geht mir auch so, ich finde tatsächlich, den Code nochmal in einer anderen Umgebung sehen, also typischerweise, ich schreibe den in meiner IDE und dann sehe ich ihn nochmal in GitLab. Das hilft schon total, selbst nochmal eine völlig andere Perspektive auf den Code zu bekommen. Also das mache ich auch grundsätzlich. Und was mir dann halt, also was tatsächlich für mich noch so ein Ding ist, was mir aufgefallen ist, wenn ich Code Reviews einfordern möchte, achte ich etwas stärker darauf oder ja besser darauf, dass ich, sage ich mal, kleinere Incremente habe, die ich zeigen kann. Also im Idealfall gelingt mir das, sprich, ich mache kleinere in sich abgeschlossene Commits, die ich im Service-Fall auch mal zeigen kann oder versuche generell mein Merch-Request nicht so riesig zu halten, also ich versuche tendenziell inzwischen nicht mehr Branches zu haben, die jetzt ewig laufen und wo ich dann einen Feature über zwei Wochen tüftele und dann wird es superschwer, das irgendwann wieder in den Main-Branch reinzubekommen. Das versuche ich eher so ein bisschen zu vermeiden und zu gucken, kann ich diese Arbeit in kleinere Incremente aufteilen, weil das macht es dann auch viel, viel leichter, jemandem zu erklären, was ich da getan habe. Also vielleicht noch so als Werkzeug im Code-Review-Werkzeugkasten, aber ja, die Erfahrung, die du gemacht hast, Klaus, die habe ich auch gemacht, dass dieses sich vorher noch mal eine andere Umgebung angucken, super hilfreich ist.
Tobias
Mhm. Du wolltest noch was zu den Nall.
Theo
Ich bin jetzt schon gespannt, wenn das der Elefant in the Room ist. Ich habe gerade versucht, nebenbei noch mal zu reflektieren, warum ich da so anspringe. Ich glaube, die Gefahr, aber das ist eher so eine Thought Train, die halt bei mir los läuft. Die Gefahr, die ich sehe, wenn jemand die Annahme hat, dass jemand die ganzen Logikfehler immer catcht. Bei einem Code Review sehe ich so ein bisschen die Gefahr, dass jemand, sage ich mal, diese Ownership in diesem Moment abgibt, so nach dem Motto, na ja, ich habe ja ein Code Review mit jemandem gemacht und wenn der oder die keine Logikfehler entdeckt hat und ich Runtime Fehler habe, dann ist es ja nicht mehr meine Schuld, so nach dem Motto. Weißt du, es geht ja auch gar nicht um Schuld und Runtime Fehler wirst du haben, die wirst du kaum vermeiden können und die eine Sprache, sage ich mal, ist ein bisschen besser dafür geeignet, die zu vermeiden als die andere. Also wenn ich jetzt in JavaScript meinen Code schreibe, dann sind Runtime Fehler wahrscheinlich vorprogrammiert. Ich weiß nicht, was ich da wissen möchte.
Tobias
Klaus (Florian)
Wenn das der Elefant in the Room ist...
Tobias
Du musst jetzt auf spezifische Beispiele eingehen.
Theo
Wenn ich stattdessen TypeScript nehme, beispielsweise, habe ich schon mal die Chance, dass durch die statische Typechecking mir eine ganze Reihe Fehler vielleicht nicht unterkommen. Und wenn ich eine Sprache habe, die Null als Konzept gar nicht kennt, dann habe ich das Problem Null Safety schon mal komplett eliminiert, beispielsweise.
Tobias
Vielleicht da ganz kurz eingehakt, das würde ich auch unter dem Aspekt Qualitätsverbesserung bei uns sehen. Und ich glaube, das ist ein größerer Trend, mit dem wir mitmachen sozusagen, dass sich diese ganze JavaScript-Welt eigentlich auf TypeScript irgendwie wegen Typ-Sicherheit geeinigt hat. Vielleicht zu viel gesagt, aber ich würde sagen, für unsere Projekte ist TypeScript heute Standard. Ja, absolut. Ja. Weil es sozusagen in der Sprache inhärent bestimmte Fehlerklassen aussieht.
Theo
Genau, also das sind so Sachen, die man sonst typischerweise versucht hätte mit einem Unitest oder so vielleicht zu erschlagen, aber die Chance, dass einem da was durch die Lappen geht, ist eben sehr, sehr groß und diese Typ-Sicherheit hat ja noch viele andere Vorteile in dem Moment, wo deine Sprache statisch analysiert wird, hast du halt eben so Sachen wie Jump to Definition und so, also diese ganzen netten Sachen, die man in die EDE gerne möchte, dass man sich anzeigen kann, wo wird der Code denn überhaupt verwendet, das kommt quasi alles aus der Schachtel und das ist natürlich extrem, extrem wertvoll, also ich weiß nicht jeder, glaube ich, der schon mal in einer größeren JavaScript-Codebase oder generell in einer dynamischen Sprache ohne Typisierungen gearbeitet hat, der kann, glaube ich, nachvollziehen, wie schmerzhaft das sein kann unter Umständen und irgendwann weißt du einfach nicht mehr, hey, das, was ich hier verwende, dieser Code, was darf die Funktion denn für Parameter bekommen? Ich habe keine Ahnung, also schmeiß mal irgendwas rein und in 50% der Fälle geht es vielleicht gut und in den anderen 50% geht deine Anwendung auf die Bretter, das ist genau der Grund, warum ich so geträge, weil ich glaube, dass Werkzeug sich dort mehr Sicherheit, es gibt andere Werkzeuge, sich diese Sicherheit zu verschaffen, als das Code Review, aber natürlich kann das Code Review auch helfen, Klaus, ich glaube, du hast da völlig recht, deswegen, es ist nur so ein, ich wäre sozusagen da vorsichtig, mich da zu doll drauf zu verlassen, dass gerade diese Fehler gecatcht werden bei einem Code Review, weil einem, glaube ich, eine falsche Sicherheit gesetzt wird. Ja, so hatte ich.
Tobias
Ich glaube, ich eine falsche Sicherheit, so hatte ich Klaus auch tatsächlich nicht nicht verstanden und ich glaube, diese Anke.
Theo
Okay, dann du kommst bei mir an.
Tobias
Da muss ich jetzt mal eine Lanze für Klaus brechen.
Klaus (Florian)
Also ich finde, ich glaube, es geht halt auch darum, also Qualitäts- oder Qualitätsbewusstsein bedeutet ja nie, dass Fehler nicht passieren werden. Das ist ja quasi ausgeschlossen, also das ist ja per Definition der Realität quasi, das passiert. Aber es gibt halt Tools, die das minimieren. Und wenn ich keinen Compiler habe, ist ein Code Review echt eine gute Sache.
Tobias
Genau. Und ich glaube, worauf wir uns einigen können, wenn ich jetzt viel so für und wieder gehört habe, ist mit ist besser als ohne. Also mit Code Review ist besser als ohne. Wir haben für uns bestimmte Erfahrungen gemacht, das hattest du ja für uns gesagt. Für uns würden wir sagen, ein asynchrones Code Review ist besser als gar kein Code Review, ein synchrones Code Review ist besser als ein, das ist häufig, red jetzt mal, durchschnittlich gesehen, besser als ein asynchrones. Und wahrscheinlich ist Pair Programming die steile These. Besser als kein Pair Programming. Und vielleicht ist es besser, wenn Code gemeinsam entsteht, als wenn er erst nachdem er schon entstanden ist, gereviewt wird.
Theo
Also da bin ich mir nicht sicher, wie individuell das ist, aber ich persönlich würde das Statement so unterschreiben für meine Use-Cases.
Klaus (Florian)
Also immer die Pens und so, aber ich auch.
Tobias
Jetzt setze ich mal die Tobi-Brille Kapazitätsplanung bei uns auf und würde sagen, vielleicht seit einem Jahr, vielleicht auch schon ein bisschen länger, aber das hat auch in unserer Kapazitätsplanung zu einem Umdenkengefühl dahingehend, dass wir, wenn wir uns angucken, welche Projekte haben wir denn aktuell, welche haben wir in der Pipeline und wie puzzeln wir unsere Teams da zusammen, dass wir möglichst gucken, können wir mindestens zwei Leute zusammen in ein Projekt stecken, um die Chance, um das leichter zu machen, solche Techniken anzuwenden. Wir sind halt zu zweit im Projekt, dann können wir uns in der spezifischen Teamkonstellation halt entscheiden. Machen wir per Programming oder arbeiten wir an unterschiedlichen Themen und kommen dann wieder zusammen und dadurch, dass es eben nicht nur das Ergebnis einer Person ist, sondern in einem Abstimmungsprozess, die Qualität festgelegt wird, ist das Ergebnis hoffentlich Software von höherer Qualität. Würde ich schon sagen, ja. Ich würde mal, wir hatten jetzt einiges über Code Reviews erzählt oder gesprochen, wir haben über per Programming gesprochen. Ich habe mir noch zwei Sachen, ich habe noch zwei Themenbereiche, die ich gerne noch mit reinbringen würde.
Theo
schon sagen ja ich würde mal
Tobias
Eine Sache zum Thema Code Review, ich glaube Theo, du hattest das kurz gesagt, dieses Thema Projektübergreifend. Das habt ihr, ich vermute jetzt einfach mal, ihr habt da beide schon Erfahrungen mitgemacht, dass jemand, der nicht in eurem Projekt ist, euch euren Code gereviewt hat? Oder andersherum, ihr habt das für jemanden gemacht? Ja. Ja. Ist das auch nützlich und wie ist das anders? Klaus, möchtest du?
Klaus (Florian)
Ja, ich sage also ja. Es hilft total viel, diese Menschen, die nicht im Projekt sind, die haben so inhärente Annahmen einfach nicht. Und das ist super hilfreich. Also Sachen, die für mich und die andere Person, die im Projekt ist, total selbstverständlich sind und sozusagen zum Alltag geworden sind, dass die nochmal mit dieser Naivitätsbrille überprüft werden und das so gefragt wird, warum ist das eigentlich so? Ist das gesetzt? Muss das so? Wäre das nicht besser, wenn das weg wäre? Und also diese Art von Fragen, die kann total hilfreich sein, ja.
Tobias
quasi Projekt Blindheit.
Theo
Ja, würde ich auch so unterschreiben. Und ich glaube, es kann auch nochmal dieses Phänomen des Codeverständlichkeits, dieser Codeverständlichkeitsproblematik so ein bisschen intensivieren, weil in dem Moment, wo man quasi von dem Code vielleicht noch gar keine Ecken oder so gesehen hat, wird es nochmal sehr viel schneller klar, wenn ich jetzt ein Schnipselcode sehe, ob der für sich sprechend nachvollziehbar ist oder ob das eine gigantische Funktion ist, die ich überhaupt nicht überblicken kann, wo Dinge passieren, die für mich irgendwie große Geheimnisse darstellen, wo vielleicht der eine oder andere Kommentar dann doch sehr, sehr hilfreich wäre. Ich habe den Eindruck, dass das in einem projektübergreifenden Code Review noch stärker auffällt, weil die andere Person vielleicht sonst die Domäne schon so gut kennt und das Projekt und vielleicht sogar auch den Code, dass es ihr leichter fällt, nachzuvollziehen, was an der Stelle passiert und warum das so ist, nur wenn man jetzt, sage ich mal, da diesen Truckfaktor verhindern will und sagen will, hey, jetzt kommt mal jemand Projektfremdes, der im Zweifelsfall, wenn alle Stränge reißen, weil vielleicht alle Projektbeteiligten krank sind und ganz dringend irgendein Problem angefasst werden muss, dass auch eine projektfremde Person sich da relativ schnell einfinden kann, da hilft es, wenn auch eine solche immer mal wieder auf den Code guckt.
Tobias
Das hätte ich jetzt auch als Beispiel noch eingeworfen, wo ich sagen würde, das kann spezifisch für uns sein und unsere Art, wie wir uns als Agentur aufgestellt haben und unsere Projekte organisieren. Aber genau das, was du beschrieben hast, ist ein Thema für uns. Es kann vorkommen, dadurch, dass unsere Projekte nicht mit fünf oder mehr Leuten durchgängig gestafft sind, sondern eher eins, zwei, drei ist schon ein sehr großes Projekt für uns. Wo ich sage, es kann vorkommen, dass einer davon im Urlaub ist und der andere ist krank und dann ist keiner mehr da, der sich komplett in dem Projekt auskennt. Und dann spielt es uns total in die Hände, wenn die Kurdqualität hoch ist, die Kurdnachvollziehbarkeit hoch ist und jemand Außenstehendes, wenn gerade in dem Augenblick ein Produktivsystem ein Problem hat, reingucken kann und sich dann viel leichter zurechtfindet. Klammer auf, ist auch schon vorgekommen. Klammer zu. Du hast Kommentare angesprochen, dann habe ich jetzt noch ein drittes Schlagwort in unserem Qualitätswerkzeugkasten.
Theo
Dann testen wir auch noch.
Tobias
Was haben wir? Tests. Verstehe ich nicht. Tests. Das kann ich ja gerne mal aufschreiben, mal gucken, ob wir dazu heute noch kommen. Kommentare. Wir hatten zu dem Thema, wie kommentiert man denn Code und was ist dabei hilfreich und nicht? Die Diskussion, wie gesagt, ich mit meiner hauptsächlich nicht entwickelnden Brille, dieses guter Code ist ja verständlich oder ist guter Code ja nicht verständlich? Und dann, glaube ich, sind wir in der Diskussion bei dem Thema Why-Kommentare vorbeigekommen, die quasi nicht erklären, was der Code tut, sondern die haben zum Zweck eher zu erklären, warum der Code etwas tut oder warum ein Problem auf eine bestimmte Art und Weise gelöst wurde und haben damit auch, ich sag mal, das kann sozusagen vorkommen und nützlich sein, eine einzige Zeile mit vielen Zeilen Kommentar zu versehen, damit jemand, der da in Zukunft an der Stelle vorbeikommt und sich denkt, hä, warum ist denn das so unüblich gelöst oder warum ist das so hacky oder, wenn der einen Kommentar darüber findet, wo er halt erklärt ist, hey, wir hatten folgendes Problem und deswegen muss das auf diese Art und Weise gelöst werden und das bedingt das und das und das, ja, das ist ein Wissen, das kann ich aus dem Code nicht rauslesen.
Theo
Ja, 100 Prozent. Stimme ich dir absolut zu. Also ich würde auch sagen, dass das mit die wichtigste Kommentarklasse ist, neben vielleicht Kommentaren, die so eine gewisse Grundarchitektur beschreiben, also die so ein bisschen darauf eingeht, wie einzelne Bausteine miteinander interagieren. Und die schreibt man dann oft in eine Datei und verweist in vielleicht andere Dateien, die damit irgendwie zusammenhängen, einfach nur darauf, hey, hier, wenn du mehr erfahren möchtest, wie dieser Baustein in das Gesamtkunstwerk passt, dann geh mal bitte in Datei XY, da haben wir das nochmal zusammengeschrieben. Das sind so die zwei großen Kommentarklassen, die ich persönlich als sehr, sehr wertvoll empfinde, wo man glaube ich eher aufpassen sollte, ist, dass man, was du schon gesagt hast, dass man nicht kommentiert, was der Code tut, weil Code, den wir schreiben, der ist in erster Linie dazu da, dass ihn Menschen lesen können. Das heißt, idealerweise versuchen wir uns möglichst viel Mühe zu geben, dass der Code selbst ausdrucksstark genug ist, das abzubilden, indem wir beispielsweise aussagekräftige variablen Namen nutzen und nicht einfach nur irgendwelche Buchstaben, außer vielleicht einen ganz, ganz kleinen Lambda-Funktion, aber selbst da würde ich eher dafür plädieren mit ordentlichen, ja, also eine kleine anonyme Funktion, die man an einer Stelle direkt deklariert und wieder aufruft, so würde ich jetzt mal ganz grob zusammenfassen, zum Beispiel innerhalb einer anderen sogenannten Higher-Order-Function beispielsweise, also die meisten sollten so Sachen wie Map-Filter und Reduce, also das ist ja ein technischer Podcast, also viele, die Software selbst entwickeln, kennen beispielsweise mit großer Wahrscheinlichkeit Map-Filter, Reduce oder Fold, wie es auch oft genannt wird und das sind sogenannte Higher-Order-Functions, also Funktionen, die andere Funktionen als Parameter nehmen oder zurückgeben und da kann es sehr sinnvoll sein, die Funktionen, die man da zum Beispiel als Parameter übergibt, beim Funktionsaufruf von Map in dem Fall zum Beispiel hinzuschreiben, das macht man typischerweise und das ist dann eine sogenannte Lambda-Funktion, das ist mal sehr nicht akademisch so zu erklären.
Klaus (Florian)
mal sehr nicht akademisch zu erklären.
Theo
Genau, aber jedenfalls... Du hattest über zwei Arten.
Tobias
Du hattest über zwei Anfragen den Y-Kommentar. Und was war der andere?
Theo
Der andere ist, sag ich mal, so der Greater Scheme of Things. Genau, also dieser Architekturkommentar, der im Code mir ein Bild davon gibt, in was für einer Form von Konstrukt ich mich gerade bewege und welche Bausteine das vielleicht hat und wie die wiederum zusammenspielen. Das kann extrem hilfreich sein. Ja? Nee, mach mal deinen Satz zu Ende.
Tobias
Nee, machen wir den Satz zu Ende?
Theo
Die Kommentarklasse, die es manchmal auch gibt, insbesondere von Menschen, die noch nicht so viele Kommentare geschrieben oder gelesen haben, ist die Art Kommentar, die einfach nur beschreibt, was der Code selber schon beschreibt. Und da sozusagen war mein Argument, dass das in der Regel sehr... Das ist eher redundant. ... eher blöde Kommentare sind. Es ist extrem redundant. Es hat die Tendenz dazu, sehr schnell out of date zu sein. Der Code verändert sich, aber der Kommentar wird nicht mit angefasst. Was generell ein Problem von Kommentaren leider ist, aber in dem Fall noch mal verstärkt. Und es fügt sozusagen der Situation erst mal nichts hinzu. Es gibt für mich so eine kleine Ausnahme. Manchmal kann es so ein visueller Indikator sein, der bestimmte Dinge, wenn du jetzt aus irgendeinem Grund eine sehr lange Funktion schreiben musst, was im besten Fall nicht passiert. Und die, sag ich mal, in einzelne Abschnitte zu untergliedern. Jetzt kommt der Abschnitt, der das tut, jetzt kommt der Abschnitt, der das tut. Um sozusagen so eine Art Grobüberblick zu geben, ohne zu sehr ins Detail zu gehen. Das ist so ein Edge-Case, der in Ausnahmefällen für mich auch okay sein kann. Aber im Normalfall würde ich eher sagen, dass ich, vielleicht auch der
Tobias
Genau, du hast es ja schön beschrieben. Wir schreiben den Code, damit er von Menschen gelesen werden kann. Genau, korrekt. Das lasse ich mal kurz mit einem ein paar Sekunden Schweigen so für sich stehen, finde ich schön.
Theo
Das schneide ich dann aber raus, das Spalten.
Tobias
Das kann ich vielleicht an der Stelle direkt mal einschieben, bevor ich zu meinem eigentlichen Einschub dann zurückkehre und hoffentlich mich an den rekursiven Aufruf erinnere. Wir machen ja heute die Podcast-Folge in der Kombination ich plus die beiden, die sie dann nachbearbeiten. Also ihr seid ja die, die das dann, tja, die was auch immer dann draus machen. Ich bin gespannt, jetzt habt ihr die Folge selber mit, sozusagen mit erschaffen. Was dann davon, ja, wie viele Denkpausen der Theo oder der Klaus oder wer auch immer von euch beiden, dass ihr dann einfach eure Aufgabe übernimmt.
Theo
Also ich kann dir ein kleines Geheimnis verraten, Tobi, wenn ich Podcasts mit dir postproduze, dann mache ich die Pause manchmal ein bisschen kürzer. Tatsächlich. Ich hoffe, du siehst es mir nach, aber es ist einfach vom Hörgefühl, diese Pausen sind wichtig und das, was danach kommt, in der Regel sehr wertvoll, aber manchmal ist die Pause ein bisschen lang.
Tobias
Ich hoffe, du siehst es mir nach, aber es ist einfach vom Hörgefühl, diese Pauten sind wichtig und das, was danach kommt, in der Regel sehr wertvoll, aber manchmal ist die Pause ein bisschen lang. Ich nehme mir das an. Danke, danke für das Feedback, Theo.
Theo
Du brauchst nichts zu verändern, wir kümmern uns darum, alles gut. Du behältst deine Denkpausen bei.
Tobias
Wir kümmern uns darum, alles gut, du behältst deine Denkpausen bei.
Klaus (Florian)
Genau. Genau. Für die hörende Person, die denkt, warte mal, ist jetzt zu Ende, ist Internet kaputt? Scheiße. Kopfhörer? Ja, genau. Ja, genau. Das war's.
Tobias
Ja, genau. Was in einem Face-to-Face-Setting, wo man mir ansieht, dass ich in Stand-by verfallen bin. Ich wollte den Klaus fragen, jetzt kommt der rekursive Aufruf, du hast ja mit Projekten auch zu tun gehabt, die schon existiert haben, bevor du zu Sandstorm gekommen bist. Das heißt, da war schon Code da, über welche Art von Kommentaren bist du denn wirklich gestolpert? Jetzt gucken wir mal unter den Teppich.
Theo
Jetzt gucken wir mal unter den Tablet.
Klaus (Florian)
Also, bevor ich bei Sandstorm war in diesem Projekt, da habe ich ein Projekt übernommen, was irgendwie so halbwegs funktioniert hat, um irgendwie eine Bestellung aufzugeben. Und da war das aber so, das war in PHP geschrieben. Ich meine tatsächlich...
Tobias
Senstorm-Projekte, oder? Senstorm-Projekte, okay, ich will gar nicht über-
Klaus (Florian)
andere Projekte. Okay. Schade. Es wäre echt schön.
Tobias
Kannst du gerne? Das war nicht die Intention meiner Frage. Ich wollte heute unsere eigenen Projekte auswählen.
Klaus (Florian)
Ich hatte eine Codebase übernommen, die das Konzept Loop nicht kannte. Das bedeutet, die Person hat einfach einen Codeblock von einem Tag kopiert für alle sieben Wochen Tage, fünf Wochen Tage, die bestellt werden konnte. Das war wirklich nervig, das zu lesen und zu ändern. Genau. Aber alles gut bei Sandstorm. Bei Sandstorm wird für gewöhnlich sehr gut Maintainter Code übergeben und das auch nicht einfach so vor die Füße geworfen und sagen, hier, übernimm das jetzt mal bitte, sondern in einem Projekt habe ich quasi mit dem Leon, hat mich der Leon angebordet in das Projekt und der Leon schreibt sehr gute Kommentare und auch sehr wachsam Kommentare, auch für Future Reference und mit Hinblick auf vielleicht mache ich mal eine Elternzeit und so und der Leon ist jetzt schon eine Weile in Elternzeit und es geht mir heute noch so, es ist Schnack letzte Woche passiert, dass ich an einer Stelle vorbeigekommen bin, die ich vorher noch nicht gesehen hatte in dem Projekt und aber ein Kommentar von Leon dran war, warum das so ist, wie es ist und das ist super.
Tobias
hilfreich. Es gibt sie also tatsächlich in the wild.
Klaus (Florian)
Ja genau. Ich habe das Gefühl, dass wenn ich jetzt in Elternzeit gehen würde, dass ich dann mir erstmal noch ein paar Tage nehmen müsste, um Kommentare zu schreiben. Und das zeigt, dass es da auf jeden Fall, bei mir gibt es da auf jeden Fall noch richtig viel Lernpotenzial, das auch gleich mitzumachen. So, das ist, ich glaube, das ist eine echt wertvolle, wertvolle Skill. Und das, was Theo vorne meinte mit, ja, es gibt so redundante Kommentare voll, da bin ich voll bei dir. Ich glaube, dass das aber bei, also gerade bei so Leuten wie mir, die so noch, sagen wir mal, noch nicht so lange entwickeln, ist das so Teil des Mount Stupid, glaube ich. Also, ich glaube, das macht trotzdem was, wenn man sagt, okay, ich habe jetzt diesen Skill und ich schreibe jetzt hier mal Kommentare dran, einfach das zu einem Habit zu machen, Kommentare dran zu schreiben. Ich glaube, mit Kommentaren ist es wie mit fast allen anderen Sachen auch in der Softwareentwicklung, je öfter ich das mache, desto besser wird es meistens.
Theo
Ja, also ich glaube, es birgt halt nur wirklich die Gefahr, dass sozusagen dann da Kommentare stehen, die mehr Schaden anrichten im Zweifelsfall, als dass sie helfen, also gerade wenn sie dann out of date sind, was da halt schnell passieren kann. Also ich glaube tatsächlich, dieser Habit, was du sagst, die Why-Kommentare beispielsweise direkt zu schreiben, halte ich auch für sehr, sehr wertvoll. Bei den Architektonischen ist es typischerweise so, da muss man sich so ein bisschen zwingen oder zumindest geht es mir so, dass ich dann immer, wenn ich was fertig habe, mich dann nochmal zwingen muss, sozusagen das ganze große nochmal rauszoomen, nochmal zusammenbetrachten und dann da mich tatsächlich dazu zu zwingen, da an den entsprechenden Stellen die Kommentare hinzuschreiben. Ja, also es ist auf jeden Fall nicht einfach und auch wir bei Sansom haben alles andere als immer nur den perfekten Code, ich glaube jeder von uns hat mal Code geschrieben, auf den er in dem Moment jetzt vielleicht nicht stolz war, weil es aus pragmatischer Sicht aber notwendig war, weil es das Projekt aus irgendeinem Grund verlangt hatte. Aber ich glaube, dass das Streben danach es besser zu machen und das, was wir jetzt ja auch sehr stark akzentuieren, so insbesondere im letzten Jahr, ich glaube, das ist das Wesentliche, dass wir uns einfach alle darüber bewusst sind, was unser gemeinsames Ziel ist und dass wir uns dem immer mehr entgegen bewegen, das ist glaube ich total gut, also das fühlt sich auch gerade dieses Jahr, spürt man das sehr intensiv und das fühlt sich echt gut an für mich.
Tobias
Da haben wir die Ecke Kommentare auch nochmal beleuchtet. Sehr schön. Theo, du hattest vorhin Tests reingeworfen. Was soll denn das bitte mit Qualität zu tun haben?
Theo
Naja, ich glaube, also die Fragestellung automatisierte Tests, ich glaube, Anno 2020 haben die meisten Personen davon schon irgendwie gehört, dass das wohl angeblich ganz gut sein soll. Ich würde aus meiner praktischen Erfahrung sagen, ja, das ist extrem wertvoll, also alleine Testsuit zu haben, kann erstmal total helfen, auch wieder jemandem, der aus einem Projekt, aus einem anderen Projekt stammt und in ein neues Projekt reinkommt, erstmal zu verstehen, wie funktionieren denn die Sachen, weil Tests auch eine Art von Dokumentation sind, die man lesen kann und wo man sehr gut nachvollziehen kann, wie wird denn der Code, die eigentliche Codebase tatsächlich verwendet und mit welchen Ergebnissen, welche Funktionen hat der Code vielleicht, also da passiert schon total viel und es gibt eben verschiedene Testklassen, die entsprechend in der Lage sind, verschiedene Problemstellungen in irgendeiner Form automatisiert zu überprüfen. Vielen Dank für's Zuhören, bis zum nächsten Mal.
Tobias
Wenn wir jetzt das Thema Tests sozusagen jetzt nicht so vertiefen, dass wir jetzt die ganzen Testklassen und so durchgehen, sondern wenn wir Hatt ich nicht vor, hatte ich nicht vor. Du hast gerade was, was quasi wertvoll wäre für diese Podcast-Folge und ich glaube, was wertvoll ist, hast du was oder du, Theo, du, Klaus, habt ihr was, wo ihr sagt, da hat sich für euch im letzten Jahr bei Sandstorm was weiterentwickelt, wie wir Tests schreiben, lesen, damit umgehen, was auch immer?
Theo
Ich überlege gerade, was quasi wertvoll wäre für diese Podcast-Folge und ich glaube, was wertvoll ist, hast du was oder du, Theo, du, Klaus, habt ihr was, wo ihr sagt, da hat sich für euch im letzten Jahr bei Sandstorm was weiterentwickelt, wie wir Testschreiben lesen, damit umgehen, was auch immer? Also Klaus, hast du was? Nee, ich bin gerade ganz inbrünstig. Also ja, also ich würde immer die Klammer aufmachen, das ist halt meine Erfahrung. Ich habe ja sozusagen nur eine Perspektive. Das heißt, ich kann jetzt nicht für alle anderen 30 Sandstormies da an der Stelle sprechen, sondern ich kann immer nur das beschreiben, was ich selbst erlebe und was ganz konkret in meinen Projekten passiert ist, dass wir sehr viel mehr testgetrieben arbeiten. Das bedeutet, wir haben die Tests geschrieben, bevor wir den eigentlichen Code implementiert haben. Das Ganze zusammen auch noch mit so einem Grundansatz von sogenannten Behavior-Driven Development, also wo man sozusagen erstmal das Verhalten dessen, was der Code eigentlich abbilden soll, in den Vordergrund stellt. Auch hier möchte ich jetzt nicht so tief einsteigen, kann aber sehr das Buch BDD in Action empfehlen von Manning Publications, können wir auch nochmal die Showdowns packen. Da stehen sehr, sehr viele interessante Ideen drin, wie man das tun kann. Anyway, testgetriebene Entwicklungen habe ich die Erfahrung gemacht, ist insbesondere Impair Programming unfassbar wertvoll, weil man, bevor man Code schreibt, auf einer ganz anderen konzeptionellen Ebene nochmal zusammenkommt und das in der Regel dazu führt, dass der Code, den man dann im Anschluss schreibt, aus meiner Sicht, dass der Qualitativ sehr, sehr, sehr viel hochwertiger ist, als wenn wir erst den Code schreiben würden und dann im Anschluss irgendwie versuchen würden, einen Test drumherum zu bauen. Natürlich, je erfahrener man ist, kann man das wahrscheinlich tun, weil man, sage ich mal, weiß, wie Code...
Tobias
Nee, ich bin gerade ganz im...
Theo
wie gute Coder-Architektur aussehen kann und wie sie eventuell auch gut testbar ist. Aber meiner Erfahrung nach ist der Weg andersrum, also wirklich erst den Test zu schreiben extrem hilfreich. Und ich würde eigentlich jetzt immer, wenn ich die Möglichkeit habe, versuchen, immer erst Tests zu schreiben und dann die Implementierung nachgestellt zu machen. Das ist extrem wertvoll, insbesondere im Her-Programming meiner Erfahrung nach.
Tobias
Jetzt juckt's mich in den Fingern meine eigene Frage zu beantworten.
Klaus (Florian)
Ich lasse mal den Klaus. Nee, nee, beantworte mal deine engen Frage. Ist gut. Fällt ja schwer, dem, was Theo gesagt hat, noch eins draufzusetzen.
Tobias
einen habe ich noch, einen habe ich noch. Was mir gerade dadurch ein Sinn ging, Theo, als du das beschrieben hast, war, damit dieses Test-Driven-Development funktioniert, brauche ich ja sozusagen Infrastruktur drum rum. Hast du das Test Suite genannt oder dieses Setup, ich brauche irgendwas, was Tests ausführt und idealerweise ist das nicht kompliziert, sondern leicht. Und da habe ich an unsere Projekte mit NEOS gedacht, wo wir dieses Jahr ganz viel und ganz viel getrieben auch durch Erik, der da reingeguckt hat und Sebastian, ja, uns einen Test, wie nennt man das? Test-Stack, Test-Möglichkeit. Wird es Test-Setup? Test-Setup, danke schön. Gebaut haben, was es eben leicht macht, Testgetrieben zu entwickeln oder auch überhaupt Tests zu schreiben, wo ich persönlich vor nem Jahr noch immer da saß, mich am Kopf gekratzt und gefragt hab, ich hab ne, in Anführungszeichen, einfache Website, was will ich denn da testen?
Theo
Der Testsetter!
Tobias
Aber da hat sich mein Horizont unglaublich erweitert im letzten Jahr und ist eher ein Rabbit Hole geworden, also sozusagen der Kaninchenbau, wo ich sage, wenn ich jetzt einmal, wo diese Tür aufgestoßen ist, ich kann ja alles testen.
Theo
Ja, also ich glaube das ist für mich persönlich aber auch noch der größte Painpoint generell, ist Test Setup und gute Testschreiben. Also ich glaube da ist unfassbar viel Lernpotenzial. Das ist im Grunde noch mal wie Programmieren lernen, weil es andere Abstraktionen gibt und allein die Testklassen, die ich vorhin angesprochen habe, sehr mitbestimmen, wie dein Test Setup aussehen muss. Also beispielsweise in den meisten Situationen ist ein Unit Test Setup extrem leicht hinzustellen. Also das ist in den meisten Sprachen gar kein Problem. Aber sobald es dann an sogenannte Integration Tests geht, wo mehrere Bestandteile einer Anwendung getestet werden, vielleicht auch eine Datenbank mit getestet wird und sowas, da wird es schon deutlich komplizierter. Bis hin zum End-to-End-Test, wo quasi ein kompletter Roundtrip über eine Anwendung gemacht wird. Und das ist tatsächlich noch was das technologieübergreifend, sage ich mal, schnell, einigermaßen schnell aufzubauen, stabil zu kriegen und an den Punkt zu kommen, dass auch das Test Schreiben selber leicht von der Hand geht, das ist für mich ehrlich gesagt immer noch die größte Herausforderung. Ich glaube, die Lösung, die wir für Neos und ich glaube, es geht auch in Symphony, oder ich weiß, es geht auch in Symphony, diese End-to-End-Test-Tools, die du vorhin meintest, die wir gebaut haben, die geht schon in eine gute Richtung, ist auch nicht ganz ohne die zu installieren nach wie vor. Also da muss man sich schon durch eine ziemlich dicke Rhythmie kämpfen. Aber ich sag mal, da sind zumindest die meisten Fragen beantwortet und wenn man irgendwo hängen bleibt, kommt man meistens voran, so in der Regel. Aber ich würde trotzdem nicht sagen, dass es einfach ist, an diesen Punkt zu kommen. Und ich finde auch, dass es nicht einfach ist, an den Punkt zu kommen, wirklich gute Tests zu schreiben. Also wir haben, ich kann auch ganz persönlich aus Erfahrung sagen, dass wir in einem größeren Projekt, in dem wir in den letzten Jahren gearbeitet haben, da haben wir auch immer wieder vor allen Dingen End-to-End-Tests geschrieben und haben gedacht, wir machen Behavior-Driven-Development, haben aber jetzt nach Lektüre dieses Buches, was ich vorhin genannt habe, festgestellt. Na ja, eigentlich sind wir von vielen Best Practices so weit entfernt, viel weiter kann man eigentlich gar nicht entfernt sein. Und die Best Practices, die es da gibt, sind auch total nachvollziehbar. Aber die muss man eben auch erstmal kennen und dann muss man auch erstmal ein Gefühl dafür kriegen, wie man die aufs Projekt anwendet. Und da bin ich persönlich noch total in einem Lernprozess, der total Spaß macht. Und ich sage mal, jeder Test ist besser als kein Test, meistens. Aber also das ist seitens, die Tests gehen ständig kaputt und ich muss ständig die Tests fixen, dann kann ein Test auch harmvoll sein, wenn er schlecht geschrieben ist, aber ja.
Tobias
Aber das ist ja genau die Antwort auf meine Frage. Für dich hat sich dann riesen, ist eine Tür aufgegangen in den Bereich Test Setup und Behavior Driven Development, Test Driven Development, wo du sagst, boah, da ist mir was bewusst geworden, was wir noch viel besser machen können. Und du hast Ansatzpunkte, du hast vor uns das Buch erwähnt, wo du auch sagst, hey, aus dir heraus, intrinsisch heraus, hast du Bock, da besser drin zu werden, weil du da ganz viel Benefindt. Vielen Dank für's Zuhören, bis zum nächsten Mal.
Theo
absolut ja und das ist also ich habe auch das gefühl wenn ich mehr erfahrungen gesammelt habe und so eine gewisse grundsattelfestigkeit erreicht hat möchte ich das auch viel stärker bei uns im team noch streuen das ist so ist eigentlich so mein großes learning thema aktuell was ich dann irgendwann wieder auch zurück ins team fließen lassen möchte also mache ich jetzt zum teil schon aber ich bin halt quasi noch begrenzt in dem was ich geben kann weil ich noch so viel selber lernen möchte an der stelle
Tobias
Du hast schon so viel zu geben, Theo.
Theo
Das bedeutet mir viel, Tobi, dass du mir das sagst. Das ist eine Denkpause.
Tobias
Ja, ich will ja überlegen, ob ich das noch ein bisschen nachwirken lasse oder ob ich Klaus... Ach so, okay. Jaja, schneide ich ja eh noch. ... für Klaus dann schon fragen, wie deine Erfahrungen waren, was sich beim Thema Test, Testing im letzten Jahr verändert hat bei Sandstorm.
Klaus (Florian)
Jo, also so grundsätzlich, wenn ich das mal ganz rauszoome, ich habe früher mal im Studium und so in der Qualitätssicherung eines metallverarbeitenden Betriebs gearbeitet und wir haben da ganz viel Teile gemessen, wir haben super viele Gewinde kontrolliert und so, also das bedeutet, sitzt manchmal wirklich acht Stunden am Tag da und prüfst Gewinde, du schraubst Gewinde in den Ring rein, wo es rein muss und dann in den Ring, wo es nicht rein darf. Also genau, so eine Sache, das ist wirklich super stumpf und dann gibt es aber auch Messmaschinen, wo man dann so irgendwie Durchmesser misst und so und für mich ist dieses, das Testing-Thema ist so am nächsten an dem dran, also. Das klingt irgendwie super negativ. Nee, nee, nee, nee, nee, gar nicht, das Ding ist eben so in diesem ganzen Metall-Business, da ist ja die Qualitätssicherung so, die ist ja super strikt durch Normen festgelegt und da gibt es so ein ganz klares Regelwerk, was muss sein, damit dieser Qualitätsstandard eingehalten ist und auf Softwareentwicklung das umzubrechen, das ist gar nicht so leicht, also weil es einfach, es gibt schon auch ISO für Qualitätsmerkmale von Software-Systemen, so 91, 26 und sowas, das gibt es schon, aber das ist irgendwie, das ist nicht das Gleiche und Tests sind für mich gefühlt schon am nächsten an dem dran, zu sagen, okay, ich habe hier eine Grundfunktionalität an meinem, in Anführungszeichen Teil, Metallteil, nämlich an meinem Stück Software und ich muss das jetzt genau überprüfen, kann das das, wenn ich es aufrufe, kann diese Funktion, wenn ich der das und das reingebe, macht die, was sie soll und insofern kann das, also ein grüner Test, kann was sehr, sehr Befriedigendes sein. Absolut, das kann ich nur unterschreiben. Wow, für die Hörerinnen und Hörer, ein Intro für einen Satz, naja.
Theo
Das kann ich nur unterschreiben.
Tobias
Für die Hörerinnen und Hörer. Vier Minuten Intro für einen Satz. Na ja. Das ist jetzt ein grüner Test.
Theo
sind ein grüner Test? Also automatisierte Tests laufen typischerweise in einem sogenannten Test-Runner, den kann man quasi einfach starten. Das macht man zum Beispiel über die Kommandozeile oder in der IDE gibt es irgendwo ein schönes Knöpfchen. Und also Test heißt ja Test, weil er irgendetwas testest und ein Test kann entweder fehlschlagen oder er kann erfolgreich sein. Und das heißt, dass ich in einem Test, ich habe Code, den ich testen möchte. Das heißt, ich rufe diesen Code typischerweise auf, in irgendeiner Form. In einem Unit-Test ist das ganz einfach, indem ich tatsächlich die Funktion... Das Ergebnis des Tests ist grüner.
Tobias
Das Ergebnis des Tests ist grün im Sinne von bestanden.
Theo
Das ist korrekt. Dazu wäre ich gleich zu kommen. Wie möchtest du mir unterstellen, dass ich zu ausschweifend argumentiere? Dann tut es mir an dieser Stelle leid.
Tobias
Ich wollte nur das Missverständnis vermeiden und jetzt mache ich einen thematischen Schwenk. Wir haben ja das Thema 2028 und nachhaltige Software auch und da könnte ja ein grüner Test auch sein, ein Test auf wie nachhaltig ist denn unsere Software. Aber in dem Kontext hier geht es tatsächlich um ein Testfall ist bestanden oder dann ist er grün oder ist es nicht bestanden und ist er rot.
Theo
Wenn er rot ist, habe ich typischerweise im besten Fall noch Informationen darüber, was da konkret schiefgegangen ist und man ja theoretisch kann man alle möglichen Sachen automatisieren. Ich sage mal, der Regelfall ist, dass man in irgendeiner Form die Logik des Codes prüft und dass eben der Code tut, was er soll, aber wie du schon sagst, man kann genauso theoretisch auch Performance-Tests laufen lassen. Also es gibt im Prinzip noch ganz, ganz viele Kassen Accessibility-Tests automatisiert. Es gibt alles, aber ich sage mal, je spezifischer die Testkategorie, desto seltener wird es gemacht, behaupte ich jetzt einfach mal, gerade weil zum Beispiel ein Performance-Test für die typische Web-Anwendung wahrscheinlich relativ irrelevant ist. Wenn ich eine Systemsoftware, ich treibe irgendwelche Treiber für eine Rakete oder so, dann ist es wahrscheinlich deutlich wichtiger, dass da bestimmte Performance- und Security-Tests etc., sage ich mal, grün sind und dass ich die schreibe bei einer klassischen Web-Anwendung, konzentriere ich mich eher auf andere Kategorien, aber die Klasse, die du gerade meintest, die wird hoffentlich für uns deutlich interessanter, die Klasse des, wie nachhaltig ist denn das, was wir da schreiben.
Tobias
Wollt ihr zu dem Thema, was hat sich in letzter Zeit zum Thema Testing bei uns verändert, noch was anmerken? Sonst würde ich zum nächsten Thema gehen.
Theo
Ja, ich glaube, wir können zum nächsten Thema.
Tobias
Weil wir hatten in der Einleitung gesagt, die Fragen, die wir momentan in der Morgenrunde uns allen stellen, ist, möchte jemand Code Review per Programming machen oder ein Shaping? Und jetzt haben wir wieder so einen erklärungswürdigen Begriff. Shaping?
Klaus (Florian)
Ich kann mich dran erinnern, dass ich eine Onboarding-Conversation mit dem Tobi, der zufällig gerade hier dabei ist, hatte zum Thema Shaping. Und ich glaube der Tobi kann das super erklären.
Theo
Schön den Ball zurückgespielt.
Tobias
den nehme ich doch gerne auf, den Ball. Danke, Klaus. Oh Gott. Shaping ist ein Begriff, der sich, ich sag mal, bei uns so etabliert hat, kommt aus dem Buch Shape Up von Basecamp. Oder heißen sie wieder 37signals? Da fragst du. Tja.
Theo
Tja. Glaub ich die falschen. Ist aber auch nicht.
Tobias
Ist aber auch nicht so entscheidend. Wir können Shape Up verlinken. Ich glaube, wir haben es im Podcast auch an der einen oder anderen Stelle schon mal angesprochen, ob sie jetzt Basecamp heißen oder so die Seiten Signals. Die Leute, die da Software entwickeln, die gleichnamige Software, Basecamp, haben ihre Software- und Projektproduktentwicklungsmethodik darin beschrieben und Teil davon ist, wenn sie ein neues Feature planen, dann wird das Thema geshaped. Geshaped heißt, es wird aufgeschrieben, was gehört alles dazu, was ist das Problem, was ich lösen möchte, was ist die grobe Lösung, was ist drin und Teil der Lösung, was ist explizit nicht drin, was ist out of scope, was sind Rabbit Holes, also diese Kaninchenbauer, die in das Unendliche weitergehen, die schon absehbar sind und wo man deswegen vorher schon sagen kann, Achtung, da aufpassen, wenn man dann an die Implementierung geht. Da kommt es her. Für uns, würde ich behaupten, ist der Begriff Shaping genau diese Planung, ich möchte mir jetzt ein Feature vornehmen und ich gehe das vorher mal durch. Ich mache mir einen Plan, wie ich vorgehe. Ich steige nicht direkt in den Code ein, sondern ich überlege mir, was hat das für Auswirkungen auf Architektur, welche Stellen will ich anfassen, wie sieht die Lösung aus und so weiter. Wie kann ich das vielleicht testen, was sind Implikationen für andere Stellen im Projekt und so weiter und so weiter. Wie viel Zeit haben wir zur Verfügung? Gibt es eine Budget-Vorgabe vom Kunden oder ist das sozusagen, wir geben uns selber eine Zeitvorgabe, weil Zeit nicht unendlich ist. Für mich ist das Thema dazu gekommen, weil wir gemerkt haben, das ist wie per Programming, nur per Planning eigentlich. Ich hole mir jemanden als Buddy, als Partner drin dazu, um auch schon in dieser Vor-Coding-Phase ein besseres Konzept zu erstellen, weil wir es gemeinsam machen. Seht ihr das auch so?
Theo
Also ich hab gerade ein bisschen drüber nachgedacht. Also ja, also aus meiner Sicht ja. Hintergrund ist, ich kann mich ehrlich gesagt nicht erinnern, also ich weiß, dass dieser Begriff Shafing bei uns total oft verwendet wird. Aber lustigerweise kann ich mich gerade an keine Situation erinnern, in der dieser Begriff in meinen Projekten explizit gefallen wäre in den letzten Jahren. Also ich glaube, alles was du beschrieben hast, machen wir. Aber ich glaube, es ist selten bei uns eine Runde losgegangen, in der ich beteiligt war, die sozusagen mit dem Wort Shaping begonnen hat. Deswegen ist das für mich immer noch, ist sozusagen dieses Shaping seltsamerweise, obwohl ich alles, was du beschrieben hast, gerade beschrieben hast, tue, ist es für mich so abstrakt, weil ich sozusagen das Gefühl habe, ich hab's bei Senstorm noch nie gemacht, obwohl ich's wahrscheinlich schon gemacht hab. Ist ganz spannend.
Tobias
Wie habt ihr das in dem Projekt, in dem du mit Robert jetzt eine Weile zusammengearbeitet, wie habt ihr das da genannt? Also, ihr habt ja genau das getan.
Theo
Ja, absolut. Ich glaube, das war halt einfach Konzeption. Das war halt ein Meeting zu dem, was wir da tun. Ja, genau. Ohne dass jetzt das Wort Shaping gefallen ist. Ich glaube, deswegen habe ich das Gefühl, ich habe es noch nie gemacht, obwohl ich es eigentlich auch mache. Und auch total wichtig finde. Also alles, was du gerade beschrieben hast, kannst du dich total unterschreiben.
Klaus (Florian)
Ja, same, same. Bei mir ist auch ganz konkret so, das ist gar nicht so lange her. Da hatte ich, habe ich, hätte ich profitiert, wenn ich ein sauberes Shaping gemacht hätte und bin echt eine Weile lang in einem konkreten Problem absolut in eine ungünstige Richtung gelaufen und habe es erst relativ spät realisiert. Und dann haben wir sozusagen, als ich dann gemerkt habe, okay, hier ist echt schon Zeit vergangen, die eigentlich sollte das Ticket vielleicht schon fertig sein. Ich muss hier mal echt mir noch jemanden holen. Und dann habe ich mal. Und dann haben wir da mal noch sozusagen ein nachgeordnetes Shaping gemacht. Und also ich hätte mir super viel Ärger erspart an der Stelle, wenn ich wenn ich das Shaping eher gemacht hätte beziehungsweise das explizit gesagt hätte. Hier gibt es noch Untiefen und ich kenne die gar nicht, wenn ich einfach losgerannt wäre und gedacht hätte Ja, einen groben Plan habe ich. Ich konnte mal los, sondern hier mal ganz klar formuliert hätte Wo sind denn hier Untiefen Rabbit Holes? Wo kann man richtig hinfallen? Das wäre, das wäre, glaube ich, eher aufgefallen. Insofern kann Shaping. Also das fühlt sich ja erst mal so an wie OK, ich habe jetzt ein neues Ticket. Ich schäpe das erst mal eine Stunde. Das ist ja wie eine Stunde extra Geld investiert sozusagen. Das kann aber im Zweifel tatsächlich dazu führen, dass man Geld spart, wenn man nicht unnötigerweise stundenlang in die falsche Richtung rennt.
Theo
Ich würde behaupten, das tut es immer. Ich glaube, das ist nie rausgeschmissenes Geld oder rausgeschmissene Zeit. Selbst auf privater Ebene, wenn ich jetzt sozusagen im kleinen Tasks angehe und sei denn noch so klein, ist das erste, was ich mache, mein Problem in Teilprobleme zu zergliedern und die einzelnen Bestandteile zu verstehen und mir auch sozusagen schon mal so eine grob priorisierte Liste an Schritten gewahrt zu machen, die ich durchlaufen muss, um hoffentlich zum Ziel zu kommen. Und da vielleicht noch mal ganz kurz so der Rückblick noch mal auf diese TDD, BDD, also Test Driven, Behavior Driven Design Geschichte, die ich vorhin ansprach. Das kann wahnsinnig helfen, innerhalb dieses Prozesses sozusagen auch da schon Dinge zu definieren, die man dann später gleich noch in einen Test gießt und die einen dann weiter leiten durch den Prozess des Feature-erschaffens beispielsweise. Also das haben wir in dem letzten Projekt ganz intensiv am Ende getan, dass wir wirklich auch mit unserer Product Ownerin zusammen, also mit Sabine, das kann ich nicht einigen, die ist ja bei uns, haben wir dann zusammen tatsächlich teilweise da gesessen und haben Behavior Stories geschrieben, also das ist quasi wirklich natürliche Sprache, das ist erstmal kein Code oder so, den man dann schreibt, die einfach nur beschrieben hat, was der Code, den wir dann später irgendwann mal schreiben, tun muss und dann haben wir im Nachgang den dahinter liegenden Test Case implementiert und dann haben wir den eigentlichen Code geschrieben und aber es war von vornherein sozusagen ganz genau klar, wo wir eigentlich hinwollen, weil wir das schon ausformuliert hatten, das war mega hilfreich. Also ich glaube, sich vor dem Programmieren Gedanken zu machen, was man da eigentlich programmieren will, ist immer erstmal ein guter Anblick.
Tobias
Ganz spannend, wenn ich gerade darüber reflektiere, ist das ein Glaubenssatz, dass wenn eine entwickelnde Person keinen Code produziert in dem Moment, dass sie dann nicht produktiv ist? Wenn ich mir überlege, wo wir gerade ein Fokus drauf legen, besser zu werden, dass wir sagen, diese Konzeption, die ist, egal wie klein das Ticket ist, es sollte immer eine Konzeptionsphase geben. Und wenn die, ich übertreibe jetzt mal, 10 Sekunden ist, weil ich sage, ah, ich habe das Problem gelesen, ich überlege mir, was ich tue, und je größer natürlich das Thema ist, desto expliziter und mehr Raum verdient sie auch und braucht sie auch, genauso wie hinten raus, das Thema, ich habe Code geschrieben und den teste ich dann auch noch, dass es nicht eben nicht dieses Drangeflanschte ist, sondern ich kann es eigentlich auch andersrum, also es macht vielleicht sogar Sinn, das andersrum zu machen, weil die Anforderung, diese User Story beschreibt ja das erwartete Verhalten des Systems, was ja quasi der ultimative Testcase ist. Als User möchte ich auf diesen, möchte ich, weiß ich nicht, hier auf Kaufen klicken und dann habe ich eine Bestellung ausgelöst.
Theo
Ja tatsächlich, ich würde es sogar noch generischer meistens formulieren, also ich möchte Produkt XY kaufen. Wie das sozusagen hinter den Kulissen passiert, das ist schon wieder unter Umständen schon ein Implementierungsdetail. Aber ja, absolut, also und ich glaube ja, es kann ein Glaubenssatz sein, ich hoffe und glaube nicht, dass es bei Sandstorm einer ist, also ich, vielleicht bei einzelnen, also in einzelnen Situationen, vielleicht doch, vielleicht, hm, vielleicht kommt das vor. Gute Frage. In dem Fall in anderen Unternehmen, auch in meiner älteren Arbeitshistorie habe ich das definitiv sehr erlebt, dass gerade so Sachen wie Tests, Konzeptionen und so sehr auf den Prüfstand gestellt wurden. Ich glaube, da gibt es dann schon dieses Phänomen, dass Menschen denken Programmierer in Werden für Lines of Code die Stunde bezahlt. Also das gibt es glaube ich schon, ja, ziemlich.
Tobias
Ja, also ich will gar nicht alle über einen Kamm scheren, ich will es gar nicht pauschalisieren, aber ich merke ja bei uns, wir, um unsere Gewohnheiten da zu verändern, haben wir es ja zum Beispiel in die Morgenrunde einfließen lassen, als hey, da zu sagen, ich möchte mit jemanden zusammen hier ein Shaping von einem Thema machen, ist erwünscht, ist gut, notwendig. Wir profitieren alle davon, wenn wir das machen, weil wir ja auch mittlerweile, haben wir vor uns auch schon gesagt, Projekte haben, die über viele Jahre laufen, Klaus, du bist ja auch in Projekten unterwegs, die schon lange, also viele Jahre, Jahre laufen und je höher dort die Qualität ist, auf die du stößt, desto einfacher kannst du Veränderungen am System vornehmen. Absolut. Vielen Dank für's Zuschauen, bis zum nächsten Mal, tschüss, tschüss, tschüss, tschüss.
Klaus (Florian)
Und der Umkehrschluss gilt natürlich auch, wenn was nicht gut maintained ist, also wenn man irgendwie auf was Externes zurückgreifen muss und das ist nicht so gut maintained, dann kann das auch passieren, dass eine Änderung von einer CSS-Klasse dauert, weil es schwer ist, die Stelle zu finden, wo das geändert werden muss, das gilt in die andere Richtung genauso.
Tobias
Genau, und dann sind wir beim Thema technische Schuld, die, wenn ich ein Projekt auf der grünen Wiese in dem Moment, wo ich es starte, starte ich mit hoffentlich noch keine technischen Schuld, aber spätestens, wenn ich irgendwas eingebaut habe, fange ich an, die anzuhäufen und nach Jahren im Projekt, also mir ist noch kein Projekt untergekommen, wo keine technische Schuld drinsteckt, zumal ja auch, und das ist ja auch die Realität unseres Softwareentwicklungsdaseins, die Ressourcen im Sinne von Geld und Zeit sind begrenzt, also muss ich irgendwo immer, ich muss irgendwo immer Abstriche machen, das geht nicht anders. Wir werden nie den Idealzustand erreichen. Damit haben wir die Themen, die ich auf dem Zettel habe zum Thema Qualität, wo ich so auf dem Schirm habe, da legen wir gerade einen Fokus drauf, da hat sich in den letzten Monaten, haben sich da Dinge verändert, wir experimentieren und schärfen das weiter. Wir haben schon gesagt, wir haben angefangen mit der Frage, möchte jemand ein synchrones Code Review, haben das ergänzt um, möchte jemand Pair Programming machen, möchte jemand Shaping machen. Ich gehe davon aus, das wird sich auch in der Zukunft weiter verändern. Habt ihr noch Sachen bei euch auf dem Zettel, die ihr jetzt ansprechen wollt? Ich fliege nochmal drüber. Klaus, du hattest schon gesagt, du hast einen großen Zettel, da haben wir noch gar nicht so viel. Ich bin echt neugierig, was da draufsteht.
Klaus (Florian)
Versprochen, ich bin echt neugierig, was da drauf steht. Nee, es ist alles fein. Es ist gut. Ich bin super zufrieden mit mit dem Outcome. Es ist wahrscheinlich ist der Zettel eine Hilfe für zu lange Schweigepausen gewesen. Aber es ist okay.
Tobias
Ich bin echt nervig. Alle Zuhörerinnen und Zuhörer wollen wissen, was auf deinem Zettel steht.
Klaus (Florian)
Alle Zuhörerinnen und Zuhörer wollen wissen, was auf deinem Zettel steht. Ich habe also ich habe hier versucht, diesen Spagat zwischen wie ist es denn in der, sagen wir mal, in der produzierenden Welt, die so jetzt so anfassbare Teile produziert und habe dann versucht, so die Metaphern zu finden. Was ist denn die Entsprechung in der Softwarewelt und so? Und es ist aber fein, dass das gar nicht so...
Tobias
Das war das Beispiel, was du vor uns brachtest, mit dem hier Gewinde testen? Ja, zum Beispiel, genau.
Klaus (Florian)
Ja, zum Beispiel, genau. Ich habe hier irgendwas über Qualitäts-Management-Handbücher geschrieben, über Audits, über Wartung und solche Sachen und habe dann immer versucht, die Entsprechung im Software-Game zu finden. Aber es ist alles gut.
Tobias
Ich hatte, als du das beschrieben hast, ging mir so ein Gedanke durch den Kopf, Unterschied Manufaktur, was wir ja überwiegend sind, wir stellen ein Einzelstück her, versus Massenfertigung, was ja in so einem, wenn ich im Metallverabendungsgewerbe bin und eine Million Schrauben produziere, da ist das Invest in Qualität ja sehr gut messbar, wenn ich nach 100 Stück feststelle. Ich habe 30 Prozent Ausschuss und dafür habe ich dann 900.000, weil ich es gefixt habe, die dann gut rauskommen, versus ich habe den Invest genau für ein Produkt, was ich abliefere. Und die Entsprechung gibt es ja in der Softwarewelt auch. Wenn ich eine Software-Assist-Service betreibe, wo ich sage, da habe ich viele, viele, viele, viele Instanzen oder Kunden drauf, die im Kern die gleiche Software verwenden, so wie ich es auch in der Massenfertigung in der Produktion habe.
Klaus (Florian)
Absolut. Und also bei meinen beiden Projekten, die ich betreue, ist es auch tatsächlich, gibt es da so einen Unterschied. Das eine Projekt ist so wirklich, das sind zwar mehrere Instanzen von Webseiten sozusagen, die fühlen sich aber so manufakturischer an in ihrer Infrastruktur und auch in dem Datendurchsatz und so weiter, der da passiert. Und das andere, da reden wir über andere Dimensionen von Datensätzen, die da durchlaufen. Und dementsprechend, es gibt da schon metaphorische Äquivalente sozusagen zwischen diesen beiden Welten.
Tobias
Schönes Wort, metaphorische Äquivalente. Das hat mich zum Nachdenken gebracht, ob das aber Auswirkungen haben sollte auf die Art und Weise, wie Qualität ja, gemanagt wird. Weil die Erwartungshaltung ist ja auch an ein Einzelstück, dass es qualitativ hochwertig ist.
Klaus (Florian)
Ja, absolut. Ich glaube, die Unterschiede ergeben sich da eher mehr in der Infrastruktur. Also bei größeren Systemen, wo mehrere verschiedene Datenbanktypen auch miteinander kommunizieren, ist es einfach auch notwendiger, da mal noch einen anderen Test zu machen, als bei einer Manufaktur. Also da geben sich einfach ganz andere Anforderungen, aber im Idealfall...
Tobias
Und was mir gerade auch noch einfällt ist, der Vergleich hinkt insofern, wenn ich ein Einzelstück herstelle, ich sitze gerade an einem Tisch, nehme mal das Beispiel, ich beauftrage einen Schreiner einen Tisch herzustellen oder einen Tischler, oder eine Tischlerin, dann wird das hergestellt, wird geguckt, passt die Qualität, ich nehme es ab, fertig. Dann ist sozusagen der Prozess abgeschlossen. Was wir ja tatsächlich haben, selbst wenn wir, wenn das Produkt individuell ist, machen wir ja häufig Releases, das heißt da kommt ja dieser wiederkehrende Aspekt doch schon mit rein. Also wir haben ja nicht, wir stellen eine Software, dann testen wir die durch, dann wird die übergeben und dann fassen wir sie nicht mehr an. Wisst ihr was ich meine? Das ist
Theo
Ja, und ich glaube, das ist generell so ein bisschen, also die Art von Qualität, über die wir sprechen. Also ich sag mal, es gibt ja, wir reden jetzt ganz konkret über Softwarequalität, also vor allen Dingen über das, was hinter den Kulissen passiert. Da wäre das Äquivalent, was weiß ich, in einem elektronischen Gerät, wie die elektronischen Komponenten verbaut sind, aber selbst das hinkt, weil die in erster Linie wahrscheinlich einfach nur dem natürlichen physischen Verfall anheimfallen und da vielleicht einfach keine robusten Teile gewählt wurden, aber das ist, sag ich mal, sehr kalkulierbar. Und bei uns ist ja sozusagen aber vor allen Dingen der Aspekt dessen, wie kann das gewartet werden, wie kann, also dieses kontinuierliche, was du gerade meintest, Tobi, wie kann das gepflegt werden, wie kann das weiterentwickelt werden, wohingegen ist auf der anderen Seite die Qualität, die dein Tisch hat, wenn er da steht, ist ja die Qualität dessen, ich hab einen schönen Tisch und den kann ich gut benutzen. Das kann ja für die Endnutzer unserer Software auch so sein, selbst wenn der Code da hinten auf gut Deutsch gesagt total beschissen aussieht, kann ja für Endnutzer die Qualität in Anführungsstrichen total gut sein, weil wir vielleicht trotzdem geschafft haben, eine tolle UX zu machen, also eine User Experience, sodass die Nutzer das gut benutzen können. Die Frage ist halt nur, für wie lange oder wann stößt das System an seine Grenzen. Ich glaube, das ist auch nochmal so eine große Diskrepanz. Wir betrachten gerade vor allen Dingen Qualität hinter den Kulissen.
Tobias
Ja, diese Schlagworte, Erweiterbarkeit, Wartbarkeit, die ja auch, und da schlage ich wieder den Bogen in unserem 2028 Thema nachhaltige Software eine große Rolle spielen, wenn ich hier diesen Tisch mir angucke und ich stelle jetzt fest als User, ich hätte jetzt hier gerne noch eine Erweiterung. Ich hätte gerne, dass der eine neue Funktion hat, ich möchte ihn jetzt nach oben und nach unten verschieben können und das fällt mir hinterher ein. Aber das ist ja das, was wir tagtäglich erleben, wir bauen eine Software für bestimmte Anforderungen und dann kommt eine neue Antwort dazu. Ich habe schon lange diese Metapher im Kopf, Software als Haus, ich habe mir überlegt, ob ich mal einen Blogpost dazu schreibe oder wie ich das mache, aber mal gucken, seid gespannt, auf jeden Fall wieder einschalten, Cliffhanger. Wir waren bei der Frage, habt ihr jetzt noch was auf dem Zettel, worüber ihr jetzt unbedingt reden wollt, was jetzt der Rückblick, also Rückblick im Sinne von, was hat ihr in letzter Zeit verändert, diesbezüglich angeht?
Theo
also ich glaube ich bin auch fein drüber fliegen
Tobias
bin auch fein drüber fliegen. Dann habe ich noch ein Thema, was, wenn ich nach vorne blicke, mir hier eingerahmt habe auf meinem digitalen Zettel. Und zwar hatte der Chris jetzt mal in einem Wochenrückblick schrägstrich Forum, was vorgestellt, was wir glaube ich noch nicht besonders viel nutzen und zwar statische Code-Analyse. War der dabei, als er Chris das vorgestellt hat?
Klaus (Florian)
Nee. Ich glaube ich auch nicht, aber ich bin, war das Wochenkreuzblick oder war das? Ja, ja, ja. Ah nee, da war ich nicht da.
Tobias
Oh, dann habe ich ja aber, dann sei es angeteasert, da kommt was auf euch zu. Das ist eine Podcast-Folge quasi. Ist tatsächlich inspiriert vor allem von einem Kunden, weil die gesagt haben, oh hier Riesensystem und Qualität ist ein Thema und die fokussieren sich gerade auf das Thema statische Code-Analyse, d.h. das, was Chris vorgestellt hat, war in der IDE und auch in der Entwicklungsumgebung, wo der Code geschrieben wird, als auch in der Continuous Integration-Umgebung laufen statische Code-Tests durch, die nach bestimmten Problemen suchen, die sich automatisiert finden lassen. Ich glaube, das Beispiel, das ihr vor uns hattet, hier mit Null Safety, könnte damit ein Kind...
Theo
könnte damit reingehen? Genau, also statische Typisierung, also mir fallen jetzt so ArcTalk im Grunde zwei große Themenblöcke ein, die glaube ich viele nutzen und viele kennen, das wäre eben einmal die statische Typisierung, wenn du in einem entsprechenden Sprache dich bewegst, die das hat, also die in irgendeiner Form transpiliert oder kompiliert wird und statische Typisierung machen kann und der zweite Aspekt, was viele glaube ich nutzen, ist Linting, also sozusagen eine Form von Codeanalyse, die überprüft, ob der Code bestimmten Regeln gerecht wird, die man beispielsweise als Organisation selbst bestimmen kann.
Tobias
Genau, genau, und das hatte Chris vorgestellt anhand von Beispielen und ich glaube, Sonalint war so ein Tool, was die da einsetzen. In der kommerziellen Version gibt es auch Open Source und ich sehe das auf uns zukommen, dass wir auch das in unsere Projekte viel stärker noch mit einbauen, um Dinge, die sich eben automatisiert finden lassen, ja, halt.
Theo
Also bin ich gespannt, weil ich jetzt konkret nicht genau weiß, worum es da bei Chris ging. Weil ich würde behaupten, es gibt bestimmte Tag Stacks, in denen ist Linting mehr oder weniger standardmäßig schon mit drin. Also ich sag mal, fast alles, was wir jetzt so im Frontend, im Bereich der Single-Page-Applications beispielsweise mit React oder so machen, da haben wir eigentlich immer einen Linta mit drin standardmäßig. Jetzt haben wir zumgiving.
Tobias
In seinem Beispiel ging es um ein Java-Projekt und der hatte das gleich auch für PHP, ich glaube PHP Stan hieß das, mit rausgesucht und ja, also so viel mal als Ausblick, ich glaube, das wird auch ein Thema, mit dem wir uns in Zukunft, das ist angestoßen. Oh ja, das wird spannend. .
Theo
angestoßen. Ja, das wird spannend. Das ist ein spannendes Thema. Man muss, glaube ich, immer nur super vorsichtig sein. Wenn wir jetzt zumindest auf dieser Linting-Ebene, kann es halt schnell passieren, dass man sich in, sage ich mal, in nicht wirklich zielführenden Diskussionen verliert. Einfach, dass man über Themen diskutiert und über Regeln, über Linting-Regeln, die am Ende einfach sehr, sehr wenig Auswirkung auf das eigentliche Produkt haben und die wenig mit Qualität zu tun haben. Jetzt mal als ein ganz blödes Beispiel ist so diese Frage Semikolons oder keine Semikolons in einem JavaScript-Projekt oder TypeScript-Projekt. Das ist einfach eine Fragestellung, über die würde ich einfach nicht diskutieren wollen. Da sollte man sich für eine Sache entscheiden und fertig, weil der Impact ist am Ende gleich null. Und ich glaube, das ist so ein bisschen die Gefahr, dass man sich da sehr in Details verliert. Auf der anderen Seite natürlich gibt es bestimmte Regeln, die vielleicht trotzdem total wertvoll sein können. Aber das ist tatsächlich einer der Gründe, warum ich mich wenig in den letzten Jahren mit Linting beschäftigt habe, ist einfach, weil ich das Gefühl habe, dass der Impact nicht so gigantisch ist.
Tobias
Dass der Impact nicht so gigantisch ist. Ja, genau. Es geht ja sozusagen weniger um Code-Formatierung oder solche Geschichten, wo ich sage, da soll es halt einheitliche Regeln im Projekt geben und muss ich nicht diskutieren, ob ich Leerzeichen oder Tapsen nehme. Das macht das Ding automatisch und gut ist. Die Beispiele waren viel fortgeschrittener. Da waren Regeln drin. Da hört jetzt wirklich mein technisches Verständnis auf. Ich mache mal so ein Beispiel, das Ding erkennt halt, du verwendest eine Variable in der Funktion und hast die Option, dass die irgendwie geändert wird außerhalb oder irgendein Zeug. Ja, genau. Und wenn dir das Ding beim Schreiben schon sagt, ah, guck mal hier, possible security issue. Ja. Ja, nice. Also, ja.
Theo
Ja, also dieses Thema Immutability und Veränderungen von Werten, das wäre jetzt auch so eins der Beispiele gewesen, wenn ich sage, die können glaube ich viel bringen, das haben wir auch tatsächlich nachträglich nochmal in einem Projekt gemacht, weil wir da Probleme hatten mit so mutierten Werten. Also ja, es gibt diese Cases auf jeden Fall. Ich glaube, es ist halt wichtig, dass man oder mein Gefühl ist, dass sozusagen die Problemstellung zuerst da sein sollte, bevor man die Lösung sucht. Man kann ja sozusagen sich diesem Thema auf zwei Wegen nähern. Einmal man nimmt eine Linter und guckt, was kann der theoretisch alles für regeln? Was gibt es für Linting Plugins und was können die für regeln? Und dann knall ich da alles rein und muss ganz viele Einzelentscheidungen treffen. Das halte ich für eher gefährlich. Aber auf der anderen Seite zu sagen, wir haben ein immer wiederkehrendes Problem in unserem Code und wir können dieses automatisiert abfangen. Und dann nehmen wir das Tool und nehmen uns genau diese eine Sache raus, die wir gerade konkret brauchen. Das kann, glaube ich, total hilfreich sein.
Tobias
Wie das bei allen Themen ist, die wir heute besprochen haben, wohl überlegt und dosiert einsetzen. Alleine für sich sind sie kein Allheilmittel und schon gar kein Garant für Qualität und ich könnte mich in jedem einzelnen Thema wahrscheinlich bis zum Exzess verkünsteln, ohne den gefühlten Mehrwert nach außen für andere zu erhöhen.
Theo
Also generell nicht nur nach außen, sondern auch eine gewisse Messbarkeit ist dann möglicherweise gar nicht vorhanden. Ich glaube, so viele Sachen auf dem Niveau, was wir jetzt so gesagt haben, Testing und so, wenn man das messen wollte, wäre das sicherlich möglich da festzustellen, was das dem Projekt bringt, irgendwann auch in Zahlen, wobei es schwierig ist, weil vieles ja auf die Zukunft immer ausgerichtet ist mit der Qualitätssicherung. Aber ich glaube, über die Zeit könnte man da sicherlich trotzdem Beobachtungen machen und das geht dann halt bei manchen Sachen ab einem bestimmten Punkt einfach nicht mehr. Das war jetzt irgendwie ein bisschen zu sehr verschwurbelt. Ich glaube, man konnte nachvollziehen, wo ich hin will, aber schön war es nicht, sind wir uns einig.
Tobias
Ich meine, wir sind uns ziemlich einig.
Theo
Da sind wir uns einig. Bist du dir auch einig? Ich bin einig. Ich glaube, wir sind jetzt so knapp an der Zwei-Stunden-Marke.
Tobias
Und ich hatte auch das Gefühl, ich habe im Schlusswort gesagt...
Theo
Hat er auch das Gefühl, ich habe im Schlusswort gesagt? Ist das so? Okay, dann mach noch mal.
Klaus (Florian)
Sag nochmal das Schusswort, ich hab das gar nicht mitbekommen.
Tobias
Nee, ich habe nicht gesagt Schluss, sondern ich hatte mein Schlussplädoyer gehalten quasi. Ach so. Ach so. Und dann wollte Theo das nochmal bestärken, Formuliermehr, Vorlesung, Formulier ist so. Ich habe das Gefühl, ich habe alles gesagt, was ich loswerden wollte in dieser Folge zum Thema Softwarequalität, wie wir da uns voranexperimentieren, worauf wir gerade unseren Fokus legen, wie wir da auch vorgehen, uns als Team zu verbessern und uns gegenseitig an unsere Standards zu erinnern, unsere Gewohnheiten zu verändern, dahingehend, dass die Qualität, die wir abliefern, besser wird, ohne dass unsere Software dadurch exorbitant teurer wird. Das ist das Spannungsfeld, in dem wir uns bewegen. Und ja, ich habe nichts mehr auf dem Zettel. Wollt ihr noch was ergänzen? Nö.
Klaus (Florian)
Ich fand's sehr schön. Ich möchte nichts ergänzen.
Tobias
Dann bedanke ich mich auf jeden Fall bei dir, Florian Klaus, für dein Podcast-Debüt vor dem Mikrofon. Ja.
Klaus (Florian)
Ja, ich danke auch vielmals, das hat Spaß gemacht.
Tobias
ich freue mich schon auf die nächste folge mit dir teo auch an dich möchte ich ein dank auspressen es hat auch mir wieder sehr viel spaß gemacht mit dir heute
Theo
Ich möchte mich auch bei euch bedanken.
Tobias
Ihr merkt, die Halbwertzeit dieses Podcastes ist überschritten. Danke an alle Hörerinnen und Hörer unseres Podcasts. Wir sind wie immer gespannt von euch zu hören. Wie fandet ihr die Folge? Was fällt euch noch ein zum Thema Softwarequalität und wie sie verbessert werden kann und soll? Ja, erreicht uns über Twitter, über E-Mail. Das packen wir wieder in die Show Notes, wie immer. Und dann sagen wir danke fürs Zuhören bis zur nächsten Folge vom Sandpapier. Macht's gut, tschüss, tschüss, tschüss.
Theo
Danke an alle Hörerinnen und Hörer.
