Macht der Craft

Notizen

Dieser Episode beinhaltet keine Notizen

Transkript

Alex: [00:00:10.65] Hallo und herzlich willkommen bei der Macht der Kraft.

Matthias: [00:00:13.83] Wir sind wieder da, mit einer neuen Folge im Gepäck.

Alex: [00:00:16.62] Heute geht es nicht nur um Codes schreiben.

Matthias: [00:00:20.43] Sondern auch, wie wir unsere Arbeit verrichten.

Alex: [00:00:23.61] Es geht um Effizienz, um sichere und saubere, aber auch effiziente Anwendungen und Arbeitsweisen.

Matthias: [00:00:30.97] Viel Spaß beim Lernen.

Alex: [00:00:33.55] Los geht’s.

off: [00:00:35.64] Die Macht der Craft arbeitet für dich.

Alex: [00:00:40.51] Heute geht es um Effizienz, wie wir effizienter arbeiten können und was das mit sauberen Code zu tun hat. Was ist deine Sicht auf das Thema Effizienz? Wie siehst du das?

Matthias: [00:00:55.18] Ich finde, Effizienz ist was Gutes. Je mehr Effizienz ich an den Tag legen kann, also desto effizienter ich arbeiten kann, desto besser fühlt sich für mich an, weil dann weiß ich, ich verschwende keine Zeit. Ich mache quasi das Richtige in der angemessenen Zeit, also die es braucht und verschwende eben keine Zeit. Also für mich feine Sache. Effizienz, was gutes.

Alex: [00:01:23.02] Ja, genau. Und es geht vor allem nicht nur um effizienteres Code, also Code, die schneller läuft. Darüber werden wir auch natürlich reden. Es geht auch darum, wie wir uns organisieren, wie wir, welche Tools, welche Methoden wir nutzen bei der Entwicklung, die uns dazu helfen und erlauben, schneller und besser arbeiten zu können, weniger Fehler zu machen usw. und so fort. Es sind für mich zwei unterschiedliche Richtungen, in die wir Effizienz heute aufteilen möchten. Und fangen wir mit die Effizienz beim Coden. Was ist das für dich? Was bedeutet Effizienz oder effizienter Code?

Matthias: [00:02:11.74] Genau. Also effektiver Code ist für mich, wenn der Code seine Aufgabe erfüllt. Also soll heißen tut was er soll, muss dafür aber nicht perfekt sein, in dem Sinne, dass er bis ins kleinste Detail optimiert wurde.

Alex: [00:02:28.00] Okay, Ja, gehe ich mit. Für mich bedeutet das eben, dass wir den Code so schreiben. Das ist, wie du sagst, die die Aufgabe erfüllt, das sie erfüllen soll und dass wir uns um Performance und solche Sachen kümmern, wenn sie tatsächlich ein Problem darstellen. Da kommen wir noch genauer drauf. Aber nicht wir müssen der Code nicht in Anführungszeichen, wie du sagst, perfekt machen. Was auch immer dieses perfekt bedeutet. Da kann man wahrscheinlich auch lange darüber diskutieren, was perfekte Code ist. Aber darum geht es nicht. Unser Ziel soll, Code zu produzieren oder Anwendungen zu schreiben, die das tun, was unsere Kunden brauchen und nicht alles. Wie gesagt, in Anführungszeichen perfekt zu programmieren.

Matthias: [00:03:20.67] Wir reden jetzt nicht darüber, dass der Code irgendwie schlecht sein soll oder gar nicht verbessert werden soll oder so. Aber.

Alex: [00:03:27.60] Nein, nein.

Matthias: [00:03:28.26] Es geht halt um ein Verhältnis. Also wenn ich einfach die Aufgabe im Prinzip schon erfüllt habe, mit einem zufriedenstellenden Code Qualität und dann anfange, irgendwie zwei Wochen dranzuhängen, um das letzte Fünkchen Perfektion rauszuholen, dass es dann das muss in meinen Augen einfach halt dann so weit geht, dass man schon fast von verschwendeten Ressourcen reden könnte.

Alex: [00:03:54.57] Das wäre zu viel des Guten.

Matthias: [00:03:56.70] Genau. Ja.

Alex: [00:03:57.81] Ich kann mich dran erinnern, nur als ich mal mit C zu tun hatte. C ist ja eine tolle Sprache, da kann man ganz viel Zeug machen und man kann in C verständlichen Code schreiben. Man kann das, aber man kann es so optimieren. Auf auf Performanz und was auch immer trimmen, dass es danach diesen Code nicht mehr verstanden wird und das ist, was ich gerne vermeiden würde. Also für mich hat Performance zum Beispiel als ein sehr wichtiger Aspekt, aber wir müssen an der Performance drehen, wenn Performance Probleme haben. Code Lesbarkeit zum Beispiel ist für mich relevanter im ersten Wurf, als dass wir die schnellste Anwendung alle Zeiten schreiben.

Matthias: [00:04:42.99] Vor allem gerade beim Thema Performance kommt ja noch dazu, dass unter Umständen eine Performance Optimierung gar keine Auswirkung auf die Gesamt-Performance hat, weil hintendran der Flaschenhals hängt. Also gerade Performance Optimierungen müssen ja wirklich gezielt an Problemstellen angewendet werden und nicht per se, weil reasons.

Alex: [00:05:06.96] Der andere Aspekt ist, dass wir effizienter in unsere Prozesse werden, dass wir Toolings oder Methoden verwenden, die uns dabei helfen, besser arbeiten zu können. Nicht zu vergessen, uns besser zu organisieren usw. und so fort. Das wäre für mich der zweite Aspekt. Wie siehst du das?

Matthias: [00:05:29.22] Ja, es ist sehr wichtig für mich persönlich. Auch je mehr Beteiligte an einem Entwicklungsprojekt, desto wichtiger es in meinen Augen. Also eine Person kann sich vielleicht noch komplett ohne Organisation selbst organisieren, sozusagen. Aber schon ab zwei Mitgliedern wird es irgendwann nicht mehr ganz so trivial. Gerade jetzt, in Zeiten, wo wir nicht mehr uns die ganze Zeit gegenübersitzen und man einfach mal so Hey, was machst du gerade ist, sondern wo halt schon eine gewisse Hürde erst mal da ist, um überhaupt Kommunikation zu Teammitgliedern zu haben, finde ich. Das wird es dann sehr schnell sehr, sehr wichtig.

Alex: [00:06:11.55] Dann fangen wir vielleicht mit das Thema Coding. Und das erste, was ich ansprechen möchte, wäre das das Thema Beware of premature Optimization. Was hast du zu zu sagen?

Matthias: [00:06:26.96] Naja, ich meine, wir haben es ja vorhin im Prinzip schon schon angerissen. Also man sollte halt in meinen Augen versuchen zu vermeiden, dass man unnötige Ressourcen in Sachen steckt, die nicht unbedingt notwendig sind, um jetzt ein Ziel zu erreichen.

Alex: [00:06:48.21] Wo ziehst du die Grenze?

Matthias: [00:06:50.36] Ja, das ist natürlich immer ein sehr persönliches Ding. Ich für mich persönlich mache so was schon mal davon abhängig. Also wenn ich jetzt in dem Sprint Kontext zum Beispiel arbeite, wie viel Zeit ich noch habe, also letztendlich und wenn noch andere Themen offen sind, würde ich erst mal, also als mal unter der Prämisse, dass die Aufgabe, die ich gerade habe, im Prinzip eigentlich abgeschlossen ist. Und alles, was ich jetzt darüber hinaus machen würde, wäre eine Verbesserung, sage ich mal, dann würde ich erst mal gucken, Gibt es andere Sachen, die noch wichtiger sind als diese Verbesserung? Und falls ja, dann würde ich erst mal die weiterarbeiten. Und wenn nein, dann kann ich mir überlegen, ob ich überhaupt eine Idee habe, wie ich es weiter verbessern kann oder ob das jetzt ein mehr, eine Vermutung ist. Es muss irgendwie besser gehen und da muss ich jetzt erst mal recherchieren oder keine Ahnung. Naja, also das ist glaube ich sehr abhängig von der Situation.

Alex: [00:07:50.79] Hm, also für mich hat das sehr viel zu tun mit nicht übertreiben. Das heißt, wir müssen schon so arbeiten, dass wir gewisse Qualitätsstandards erfüllen, dass unser Code sauber ist, dass unser Code veränderbar ist, dass unser Code erweiterbar ist, dass unser Code effizient ist, aber bis zu einem bestimmten Grad. Das bedeutet, wenn der Aufwand dem Ergebnis nicht mehr gemäß ist, im Sinne von Ich muss viel mehr Aufwand investieren für einen sehr kleineren Verbesserungen in Anführungszeichen, dann es ist Zeit für mich aufzuhören. Wichtig ist, sich die Frage zu stellen Habe ich das Problem eigentlich, die ich gerade lösen will? Kann ich das Problem belegen? Habe ich Zahlen? Habe ich Meldungen von meinen Kunden, dass da tatsächlich ein Problem besteht? Erst dann würde ich da tatsächlich Hand anlegen und das dann verändern. Ja, klassisches Beispiel haben wir schon immer wieder erwähnt, ist das Thema Performance. Schau mal, dass dein Code lesbar und veränderbar und usw. ist. Und wenn du tatsächlich so. Das heißt nicht, dass wir Performance völlig ignorieren sollen. Nein, das nicht. Aber ich lege erst einmal mehr Wert auf andere Aspekte und versuche ich so performant auf die Reihe zu bekommen, wie es geht, ohne jetzt übermäßig viel Zeit dafür anzuwenden. Und erst wenn wir tatsächlich feststellen, die Anwendung braucht zu lang für irgendwas und wir das mit Zahlen belegen können, mit Kunden Rückmeldungen kann man Zeit dafür investieren, aber nicht vorher. Aber wie gesagt, einen gewissen Grad an diese qualitative Merkmale muss sowieso vorhanden sein, damit ich erst ausliefern kann, damit ich mein Issue oder meine Anwendung als in Anführungszeichen fertig betrachten kann. Und alles andere kann man später machen, falls der Fall eintrifft, für die wir mit diese Optimierung entgegenwirken möchte. Da ist für mich Balance der wichtige Faktor.

Matthias: [00:10:15.20] Wobei das natürlich dann der Nutzen ist. Natürlich auch. Es kann ja im Prinzip auch noch mal eine was was ich verbesserte Erweiterbarkeit zum Beispiel sein oder so also aber wenn es leicht möglich ist und man mit geringem Aufwand diese Verbesserungen draufsetzen kann, warum nicht?

Alex: [00:10:33.91] Ja, was ich meine ist, wenn wir die Techniken und Methoden, die wir kennen, für Erweiterbarkeit zum Beispiel anwenden, dann hat unsere Anwendung schon eine gewisse Qualität in dem Bereich, eine gewisse Erweiterbarkeit. Und wir müssen jetzt nicht einen Monat extra dazu spendieren, um es erweiterbarer zu machen. Das ist was ich meine.

Matthias: [00:10:56.96] Klar, klar, absolut. Wie gesagt, deswegen habe ich auch gemeint, es ist irgendwie immer von der Situation abhängig. Also was muss ich investieren und was ist das, was ich da rausziehen kann dafür? Also sind wir uns ja letztlich einig.

Alex: [00:11:09.92] Wie schon so oft.

Matthias: [00:11:11.09] Wie schon so oft.

Alex: [00:11:13.22] Aufgefallen wir streiten nicht allzu oft und es ist auch gut.

Matthias: [00:11:19.10] Ein Herz und eine Seele.

Alex: [00:11:20.75] Ja, ja. Okay, dann. Was ist das nächste Thema?

Matthias: [00:11:26.72] Ja, also auf meiner Liste steht hier Mocks. Also im Prinzip, wie kann ich oder was bringen mir Mocks an Entwicklungseffizienz und also kann ich einfach auch gleich mal anfangen. Wenn ich mein System testen will, dann bin ich ja letztendlich darauf angewiesen, immer wieder auch Fremdkomponenten – seien es meine eigenen Klassen, die ich sonst in meinem System so erstellt habe oder seiens irgendwie Klassen aus Dritt libraries, die ich verwende, die muss ich irgendwie in meinem Code bereitstellen. Und wir haben ja schon ein paar Folgen über Testing und auch im Speziellen über Mocking gemacht. Also wer noch mehr Details will, kann sich ja gerne diese Folgen anhören. Aber im Grunde Mocking ist das Prinzip, dass ich diese Abhängigkeiten, die meine Klasse, die ich gerade testen will, verwendet, dass ich die eben ersetze durch meine Mocks und den Mocks kann ich dann sagen, wie sie sich verhalten sollen und somit kann ich meinen meinen Code unabhängig von dem Code anderer testen, weil ich die volle Kontrolle über die Bestandteile habe, die außerhalb meines Codes existieren.

Alex: [00:12:43.26] Wunderbar. Ich würde es in einen Satz mal verkürzen. Des Mocking erlaubt uns, unsere Klassen in Isolation zu testen.

Matthias: [00:12:55.44] Wenn man das so verkürzt darstellen möchte, ist das gut. Ist natürlich möglich.

Alex: [00:13:01.56] Heißt eben, Ich möchte jetzt nur meine Klasse testen, nicht alle Abhängigkeiten, die meine Klasse hat. Und deswegen tue ich diese Abhängigkeiten durch Attrappen ersetzen.

Matthias: [00:13:13.35] Attrappen müssen ein gutes Wort dafür. Und ich meine, letztendlich liegt es auf der Hand, warum uns das Effizienz liefert. Also Entwicklungs Effizienz ist fürs Coding für mich das Hauptding ist Ich habe früher zum Beispiel ganz früher, als ich mit Tests angefangen habe, habe und von Mocking noch nicht mal gehört habe, habe ich immer wieder das Problem gehabt, dass meine Tests rot war. Und in dem Test von meiner Klasse war aber dann irgendein Fehler, weil in irgendeiner Klasse, die benutzt wird, irgendwas schiefgelaufen ist. Irgendeine Konfiguration vielleicht nicht, da war irgendwas und das hatte ja eigentlich gar nichts mit dem Code zu tun, den ich testen wollte. Das heißt, ich muss zuerst mal jetzt herausfinden, wie kann ich denn jetzt dafür sorgen, dass diese Konfiguration da ist? Lass den Test wieder laufen, dann ist er mal grün. Okay, Alles klar. Dann gibt es ein Update von der Library. Auf einmal gibt es den Konfigurationsparameter nicht mehr. Mein Test ist wieder rot, aber das hat letztendlich ja nie etwas mit meinem Code zu tun, sondern immer nur mit einer Änderung. Und an der Stelle, auf die ich vielleicht nicht mehr Einfluss habe. Und wenn ich aber die volle Kontrolle über all diese Abhängigkeiten habe, dann wird der Test genau dann rot, wenn in meinem Code etwas schief läuft. Und das ist der entscheidende Vorteil in meinen Augen von der Nutzung von Mocks. Und letztendlich für mich ist das der ganz klare Effizienzboost an der Stelle.

Alex: [00:14:39.24] Man muss dazu sagen natürlich, diese Moocks verwendet man verstärkt, wenn wir auf der Uni Test Ebene von der Testpyramide uns befinden, wenn wir konkret eine Klasse oder eine Funktion oder auf dieser Ebene uns befinden. Nun wollen wir die Abhängigkeiten ausklammern, sozusagen. Natürlich, wenn wir Integrationstests durchführen, wo es genau darum geht, dass diese Konfigurationsparameter, dass diese miteinander arbeiten, von unterschiedliche Komponenten prüfen, Dafür werden wir sie nicht, weil wir eben diese Kommunikation oder diese Zusammenarbeiten testen wollen. Aber wenn wir isoliert eine Komponente testen möchten, dann sind Mocks das Tool der Wahl.

Matthias: [00:15:26.28] Sehr schön.

Alex: [00:15:27.48] Was hast du für Erfahrungen mit Mocks – so?

Matthias: [00:15:29.49] Im Prinzip eigentlich ganz gute. Also wer noch nie damit gearbeitet hat, wird am Anfang vielleicht erst mal ein bisschen Zeit brauchen, um das Prinzip zu verstehen, wie Mocks in einem Testing Framework zum Beispiel funktionieren. Aber wenn man glaube ich die erste Hürde mal überwunden hat, dann wird es natürlich und dann will man es glaube ich, auch nicht mehr anders machen.

Alex: [00:15:56.07] Wunderbar. Als nächstes eine meiner Lieblingsprinzipien heißt YAGNI – YAGNI bedeutet „you aint gonna need it“, also so viel wie Du wirst es nicht brauchen. Und das hat auch sehr viel mit Optimierung um mit Verbesserung, um mit Front up descisions – heißt, wir tendieren dazu, zu viele Probleme auf einmal lösen zu möchten, ohne zu wissen, ob wir dieses Problem tatsächlich haben oder nicht. Und das macht unsere Anwendung komplizierter, aufgeblähter, größer, komplexer. Und das können wir vermeiden, indem wir uns immer wieder den Satz in Erinnerung rufen Du wirst das nicht brauchen.

Matthias: [00:16:47.94] Vermutlich zumindest.

Alex: [00:16:49.42] Ja, um ich lasse mich gern revidieren. Später, wenn ich brauche, dann implementiere ich dann, wenn ich weiß, dass ich es brauche, aber nicht alles von Anfang an bis zum letzten Detail abdecken müssen, sondern ich decke ab, alles, was meine Anforderungen sind. Und natürlich mache ich mir Gedanken über rechts und links. Aber ich verwende dann keine Woche, um alle möglichen Fällen, die mir einfallen, da reinzubringen, wenn ich nicht weiß, dass ich sie auch brauche, dass sie auch passieren können. Und das bedeutet in meinen Augen diese „you aint gonna need it“. Ja implementiere erst mal nur das, was du brauchst, was deine Anforderungen von dir verlangen und nicht mehr.

Matthias: [00:17:35.61] Klingt sinnvoll. Und ja, wie du schon gesagt hast, es ist in meinen Augen auch eng verwandt. Zum Beispiel auch mit der Geschichte, wo wir am Anfang drüber geredet haben: „Beware of premature optimization“, weil auch da kann man letztlich den Satz anwenden Du wirst es vermutlich nicht brauchen. Erst wenn es wirklich konkret wird, dann macht man sich ran. Und was mir so als Beispiel halt einfallen würde, wäre es so, was mir auch selbst schon unterlaufen ist. So die Annahme, wenn ich eine neue Anwendung entwickle. Ich brauche ja mit Sicherheit irgendwie eine Userauthentifizierung, die baue ich halt einfach schon mal, da steckt da mega Aufwand rein und lass sie es ein halbes Jahr später sein oder das ist nur eine Woche später sein. Kommt auf einmal die Entscheidung. Ja, wir werden die Userifizierung über keine Ahnung oAutho, ja Klassiker wird nicht über uns laufen. So Klassiker. Also das heißt, ich habe umsonst Arbeit reingesteckt. Ich habe. Vielleicht kann ich den Benefit noch rausziehen. Ich habe es mal gemacht. Ich weiß jetzt, wie’s geht im Framework meiner Wahl, aber letztendlich ist es halt trotzdem aus Sicht des Projekts erst mal ein bisschen verschwendete Zeit gewesen.

Alex: [00:19:00.38] Also nicht übertreiben, nicht zu viel Front up. Und das hat sehr viel mit das Thema inkrementelle Entwicklung zu tun. Was für mich bedeutet dieses inkrementelles Arbeiten bei der Entwicklung lernen wir über unser Problem. Wir haben. Wenn wir anfangen, haben wir nur ein eingeschränktes Wissen über die Anwendung, die wir schreiben wollen. Und mit der Zeit – Je mehr wir daran arbeiten, desto besser verstehen, wie es sie und verstehen wir die Anforderungen, die wir haben und verstehen wir hoffentlich, was unsere Kunden gerne hätten. Und das ist für mich, was diese inkrementelle Entwicklung bedeutet. Wir verbringen nicht drei Monate, bevor wir anfangen, indem wir alles bis ins kleine Detail planen und designen und entscheiden, sondern wir verwenden am Anfang sehr viel weniger Zeit dafür, um fangen an mit dem Wissen, die wir zu dem Zeitpunkt haben. Das bedeutet nicht, dass wir kein Design machen vorab, aber wir machen nicht alles bis ins letzte Detail und dann nach und nach. Je weiter wir im Projekt kommen, desto mehr werden wir verstehen und wissen über die Erwartungen, über die Anforderung nur, wie unsere Anwendung zu arbeiten hat. Und das kann man nach und nach immer dann rein tun, wenn es relevant, wenn es bekannt wird. Das bedeutet aber auch, wir müssen entsprechend arbeiten, dass diese Änderungen, Anpassungen, Erweiterungen auch machbar sind. Siehe Änderbarkeit, Erweiterbarkeit, Lesbarkeit. Du weißt schon, was ich meine.

Matthias: [00:20:52.31] So kommt alles zusammen. Ja.

Alex: [00:20:54.44] Und eben mal nicht alles am Anfang bis ins kleinste Detail vorplanen. Das hat sich gezeigt. Das funktioniert nicht, weil der Wissen, die wir am Anfang haben, nicht vollständig ist. Ja und nach und nach das zu ergänzen, anzupassen ist für mich die bessere Alternative.

off: [00:21:17.62] Ja.

Matthias: [00:21:18.34] Da würde ich auch zustimmen. Letztendlich. Aber vollkommen was hinzufügen. Wieder lächerlich. Ähm, ja. Ich meine letztendlich, wir haben jetzt ja schon an mehreren Stellen auch drüber geredet, dass wir Freunde von agilen Methoden und den damit verbundenen inkrementellen Vorgehen ist. Und ja, also würde ich tatsächlich einfach mal so stehen lassen.

Alex: [00:21:43.98] Also ich kann mich dran erinnern, haben wir ein 150 seitigen Dokument bekommen, wo es bis in alle Details beschrieben war, was die Anwendung zu leisten hat und wie es zu implementieren war. Was glaubst du, wie viel Prozent der Fälle dieses Dokument Bestand hatte bis zum Ende des Projekts?

Matthias: [00:22:09.25] Das ist eine Fangfrage. Hat dieses Projekt ein Ende gefunden?

Alex: [00:22:15.87] Gegenfrage Ja, bei manchen sehr abrupt.

Matthias: [00:22:21.51] Dann aber ist es wirklich fertig geworden?

Alex: [00:22:23.88] Ja, viele, Viele schon. Natürlich.

Matthias: [00:22:25.80] Viele. Okay. Ja, ich würde sagen, nicht viel, weil letztendlich ändert sich ständig überall alles. Also, warum sollte es bei dem 150 seitigen Dokument anders gewesen sein?

Alex: [00:22:38.19] Ja, also, ich sag es mal plakativ. Für die Anwendungen, die wir geschrieben haben. 0 % Nie. Ich hab’s noch nie erlebt, dass dieses Dokument, die am Anfang entstanden war, das Projekt Leben überlebt hat. Ja, es gab immer Änderungen. Es gab immer irgendwas, was falsch verstanden wurde. Es gab immer irgendwas, was dazu kam. Es gab immer irgendetwas, was sich verändert. Immer.

Matthias: [00:23:05.64] Ja. Oder irgendetwas, was halt einfach nicht so funktioniert, wie es geplant war.

Alex: [00:23:09.78] Auch auch die Architektur-Ideen, die da eingestreut wurden, waren nicht immer so zu implementieren, wie die gedacht war.

Matthias: [00:23:21.13] Ja, es kommt immer anders.

Alex: [00:23:22.95] Als man denkt. Und dann ist dieser Aufwand, um es auf unsere Folge zu münzen, nicht effizient. Wenn wir Zeit verwenden für irgendwas, was wir nicht wissen, das sehen wir gar nicht wissen können. Nimm das, was du weißt und arbeite damit und der Rest komm nach und nach. Dein Verständnis wird mit der Zeit wachsen und dann kannst du entsprechend reagieren. Wenn du all diese sauberen Code Geschichten halt mal verinnerlicht hast, wenn du deinen Code leichter ändern kannst oder leichter erweitern kannst, dann ist es kein großes Problem, auf diese Veränderung zu reagieren. Mit dieser Unwissenheit zu leben, sozusagen. Also noch mal all diese. Vorab planen vorab Entscheidungen Ja, bis zu einem gewissen Grad. Das, was wir kennen, das was wir wissen zu dem Zeitpunkt, ist gut, Das lassen wir alles einfließen. Das berücksichtigen wir alles. Aber wir müssen nicht an einem Tag die Welt retten. Das ist ein Prozess, ein inkrementelle Prozess.

Matthias: [00:24:35.67] Dann habe ich noch einen Punkt auf meiner Liste. Und zwar inversion of Control.

Alex: [00:24:41.34] Was ist das?

Matthias: [00:24:42.81] Ja, also Inversion of Control ist im Prinzip. Also, es gibt es in mehreren Facetten, sage ich mal. Ich glaube, vermutlich das bekannteste wird die Dependency Injection sein, wo ich einfach vom Prinzip her mal kurz erklärt Abhängigkeiten von außen in meine Klassen und Objekte rein gibt, anstatt sie von innen reinzuziehen. Um es jetzt auch mal in einem Satz zu machen Ja.

Alex: [00:25:13.44] Also Inversion of Control Container ist eine Technologie, die uns erlaubt, unsere Abhängigkeiten anders handzuhaben. Ja, und wie du gesagt hast, anstatt dass ich meine Abhängigkeiten selber erstelle. Es gibt ein Drittsystem, das sich darum kümmert, dass ich diese Abhängigkeiten bekomme, wenn ich sie brauche. Das ist gut, weil es uns befreit, weil wir uns nicht darum kümmern müssen. Wir können effizienter und schneller arbeiten, weil wir wissen, dass dieses System da ist und dass, wenn wir irgendwas brauchen, deklarieren wir es in zum Beispiel einen Konstruktor. Und wir kriegen vom System all diese Objekte, die wir brauchen, schon fertig generiert, konfiguriert, sodass wir uns nicht drum kümmern müssen. Das ist für mich der Vorteil, den wir bei der Sache haben. Wir müssen uns nicht drum kümmern. Die Abhängigkeitkette ist gelockert. Also wir sind nicht direkt abhängig von irgendwelche Klassen, sondern arbeiten wir wahrscheinlich mit Interfaces. Und wir brauchen gar nicht wissen, welche konkrete Implementierung dahinter steckt, sondern diese Inversion-of-Controll-Container ist in der Lage, anhand der Interfaces, die ich brauche, mir die entsprechende Objekt zu liefern, sodass ich mich gar nicht drum kümmern muss.

Matthias: [00:26:39.93] Genau noch was anderes, weil vielleicht fragt sich jetzt so mancher, was bringt mir das jetzt eigentlich, dass diese Abhängigkeiten von draußen kommen, statt dass ich mir einfach mit new rein hole zum Beispiel. Und in meinen Augen wird der Vorteil dann richtig klar, wenn man quasi Abhängigkeiten hat, die wiederum Abhängigkeiten haben, die auch konfiguriert werden müssen mit weiteren Abhängigkeiten. Und dann wird ganz schnell aus einem New Database Connection wird dann ganz schnell ein zehn zeilige Code Block, wo fünf andere Objekte noch instanziert werden müssen. Und das ist ja letztendlich nicht nur fehleranfällig, sondern auch irgendwie lästig, weil ich muss Details kennen usw. und so fort. Und mit der Dependency Injection kann ich halt einfach sagen, ich brauche eine Datenbank. Framework meiner Wahl kümmert dich darum, dass ich die bekomme und da wird es dann richtig interessant. Und zweiter Punkt, wo es das hat mir ja vorhin auch das Thema Mocks. Das war glaub ich unser zweiter Punkt über den wir geredet haben es so eine Constructor Injection wie es was letztendlich eine Umsetzung der Dependency Injection hier ist ermöglicht es mir ja dann auch in Tests Sachen rein zu geben, nämlich zum Beispiel Mocks, wo ich diese verketteten Abhängigkeiten, die unten drunter dranhängen, über die ich gerade geredet habe, einfach ignorieren kann, weil ich sage ja quasi meinem Mock, was er auf seinem Interface machen soll, wenn ich ihn anspreche. Da finde ich, kommt es richtig raus, warum Dependency Injection so wertvoll ist, vor allem im Sinne von Entwickler Effizienz. Und jetzt stellt man sich noch vor, die Datenbank Connection, die ich grad als Beispiel genommen habe, wird auch noch an mehreren Stellen im Code neu erstellt, was jetzt vielleicht kein realistischer Use Case ist, aber wer weiß. Und auf einmal muss ich, wenn sich irgendwas ändert, an zig Stellen dann anfangen es zu ändern. Auch das ist etwas, was mir so Independence Injection abnehmen kann, weil ich da quasi einmal meine Dependency irgendwo definiere, sei es als Bean oder sonst irgendwas. Und das Framework kümmert sich eben um den Rest.

Alex: [00:28:55.68] Alles, was wir bis jetzt besprochen haben. Ging es eher darum, wie können wir unsere Coding Tätigkeiten effizienter zu werden, Wie können wir effizienter testen, nicht optimieren, wenn wir es nicht brauchen? Inkrementelle Entwicklung also das ist alles. Es sind alles Sachen, die uns helfen, effizienter Code zu schreiben. Aber es gibt auch Themen, die wir uns annehmen sollten. Manche davon klingen vielleicht trivial, aber wir möchten trotzdem mal kurz darüber sprechen, welches Sie sind. Und warum sind Sie wichtig? Noch vielleicht der eine oder andere Anekdote. Und das. Erste und für mich sehr wichtige Aspekt ist. Version Control Systems heißt, irgendeinem Versionierung Stuhl zu verwenden. Ich kann mich früher erinnern, es ist schon sehr lange her zu sagen, um auch sagen, da hatten wir ein Verzeichnis irgendwo in irgendwelchen Laufwerk, wo wir unsere Ressourcen reingepackt haben, da kamen alle Entwickler drauf und wir haben uns alle ausgetobt und unser Code hinterlegt. Was natürlich viele Probleme mit sich brachte. Wir mussten Absprachen treffen. Ja, super. Ich bearbeite jetzt die Datei xyZ eine anfassen, weil wenn ich meine Änderungen mache und irgendjemand später andere Änderungen gemacht hat und Speichern bügelt er meine Änderung weg. Also völlig chaotisch. Da ergaben sich Konstellationen, an denen ich nicht mehr denken möchte und ein Version-Control-System ermöglicht viel effizienter zu arbeiten. Wie Matthias?

Matthias: [00:30:43.39] Naja, letztendlich kann ich halt unabhängig arbeiten, also jedes Versionstool. Also sei es GIT, sei SVN oder schlag mich tot, wie sie alle heißen. Alle kennen irgendwie das Konzept von Gib mir einen Teil, also den Code zum Stand „Jetzt“ mach mir irgendwie eine Kopie davon. Sei es jetzt den Git, einen Branch oder irgendein anderes Konzept und dann kann ich darauf meine Änderungen machen. Und wenn ich die gemacht habe, kann ich das Ganze eben in den Hauptteil des Codes zurück mergen. Und nicht nur das. Letztendlich bietet es mir die Möglichkeit, Sachen rückgängig zu machen. Ich kann über Tags zum Beispiel Versionssprünge markieren. Also wenn ich einen eine Änderung an meinem an meiner Anwendung gemacht habe, die neue Features hinzufügt, zum Beispiel, dann kann ich eben das Ganze auch mit einem mit dem Tag, mit einer Version versehen, zum Beispiel. Alles so Geschichten.

Alex: [00:31:52.48] Was für mich sehr, sehr wichtig ist, hast du gesagt. Wir bekommen eine Historie der Änderungen an unsere Anwendung. Ja, dazu vielleicht ja unsere Commit-Nachrichten-Folge – Conventional Commits.

Matthias: [00:32:08.62] Kleiner Werbeblock Link in der Description und.

Alex: [00:32:15.23] Ja, durch diese Historie sehe ich, wie mein Projekt sich entwickelt hat. Probleme und Konflikte werden mir gezeigt. Ich muss sie noch lösen, aber es wird nicht einfach irgendetwas drübergebügelt. Und dann sind die Änderungen, die ich gemacht habe, weg, weil du irgendwas gespeichert hast. Also dieses Problem ist aus der Welt. Wir haben eine eine Stelle, wo in Anführungszeichen die die Codewahrheit sich befindet und wir können uns mit Kopien davon vergnügen, wie wir möchten. Wenn wir wieder auf diese zentrale Stelle gehen, wird einfach drauf aufgepasst, dass keine Konflikte stehen, dass keine Probleme geschehen, dass wir keinen Code von irgendjemand anders überschreiben. Die Historie wird gepflegt. Das ist wirklich ein sehr mächtiges Instrument, die uns erlaubt, jede beliebige Stand, unsere Anwendung über die Zeit behandeln zu können. Ich kann jederzeit auf einen früheren Stand zurückkommen, wie du gesagt hast. Ich kann aber auch so Sachen machen wie unterschiedliche Kopien für die unterschiedliche Versionen, die ich beim Kunden zum Beispiel draußen habe, Wenn ich mehr als eine Version habe, so dass vereinfacht mir die einfach mit die Versionierung und die Stände und die Historie von meiner Anwendung ungemein. Und ich muss mich um Sachen, wo ich früher immer Angst haben mussten, dass wir irgendwas kaputt machen, habe ich mich nicht mehr darum kümmern. Das wird einfach vom System. Also grundsätzlich diese Version Kontrollsystem ist für mich die Grundlage, die mir Sicherheit bietet. Ich kann jederzeit zu jeder Stand zurückkommen, die ich will. Und ich habe die Historie, wie mein Projekt sich geändert hat im Laufe der Zeit.

Matthias: [00:34:10.79] Und ich kann gleichzeitig arbeiten, also alle im Team.

Alex: [00:34:13.49] Ja.

Matthias: [00:34:14.48] Natürlich ohne Angst vor unmittelbaren Konflikten zu haben. Dass beim Zusammenführen des Codes Konflikte entstehen können, das ist eh klar. Aber die kann man ja lösen.

Alex: [00:34:25.25] Genau. Was hättest du noch.

Matthias: [00:34:28.70] Jetzt zu dem Thema.

Alex: [00:34:30.20] Oder zum nächsten?

Matthias: [00:34:31.55] Wir können gerne zum nächsten übergehen.

Alex: [00:34:34.22] Gerne. Das wäre?

Matthias: [00:34:35.36] Das wäre das Issue-Tracking und da gibt es für mich ja mehrere Punkte, warum das wichtig ist. Also ich hatte ganz am Anfang quasi auf deine erste Frage oder zweite Frage scho gesagt, dass ich glaube, dass je größer ein Team ist, an so einer Anwendung arbeitet wird, desto wichtiger wird gerade auch so Thema Issue Tracking. Und da kann ich auch ein bisschen aus Erfahrung erzählen, weil ich hatte in meinem Team anfangs auch das Problem, dass wir zum Beispiel das ist auch wieder der Zeit so ein bisschen geschuldet – Corona – Man sitzt sich nicht mehr gegenüber, hatte ich vorhin ja auch schon erwähnt. Viel Homeoffice, dass man nicht wusste, wer an was arbeitet. Also es wir hatten zwar ein Issue-Board, in dem Issues auch hingen, aber Leute haben sich halt nicht zugewiesen, haben es nicht ins „Doing“ gezogen usw. und so fort. Und da hat man halt gemerkt, dass das sehr ineffizient ist, weil wenn jetzt jemand mit seinem Thema fertig ist, weiß er jetzt natürlich net per se an dem nächsten Thema: Arbeitet jetzt schon jemand dran oder nicht? Also heißt es muss erst mal wieder irgendwie im Chat geschrieben werden, Hey, macht das schon jemand blabla. Und dann haben wir uns irgendwie darauf geeinigt Oh hey, wir müssen es jetzt sichtbar machen. Irgendwie. Und ganz einfache Ding erstmal also Doing Spalte eingefügt in das Board und die Issues werden halt zurückgezogen. Und siehe da, auf einmal konnte jeder zu jederzeit sehen, wer an was arbeitet und somit viel besser entscheiden, was er denn als nächstes machen würde, wenn er mit seiner Aufgabe fertig ist. Und ja, wenn das kein Effizienzgewinn ist, was dann?

Alex: [00:36:26.42] Das, was du alles erwähnt hast, ist für mich Projekt Organisation. Wie organisieren wir uns, in Team zu arbeiten? Das Tracken hilft uns dabei ungemein, keine Frage. Aber auch, was für mich wichtig ist. Die Issue sind eine Art Dokumentation, meine Anforderungen und auch eine Art irgendwas nicht zu vergessen. Also ich verwende diese Issues, um zum Beispiel wir haben es mal, als wir über Kommentare gesprochen haben, ja To do Kommentare völlig unnötig. Ich schreibe keinen To Do Kommentar in meinen Code. Ich schreibe einen Issue, das ist dokumentiert. Wir haben dieses Problem oder wir haben das und das noch zu erledigen. Wir haben hier technische Schulen. Wir haben da eine Anforderung, hat sich geändert. Das haben wir alles in unserer Issue-Tracker und können jederzeit darauf zugreifen und gucken, was passiert ist. Und ist das erledigt, so ist das nicht erledigt. Muss man das machen, muss man das nicht machen? Es ist eine Entlastung. Ich muss nicht an alles denken und mich an alles erinnern, sondern habe ich einen Ort, wo ich nachgucken kann? Was ist die nächste Aufgabe, die ansteht? Und das ist für mich, was für meine Effizienz halt sorgt. Ich muss all diese Sachen nicht bei mir im Kopf behalten und ständig darüber nachdenken, sondern habe ich Kapazitäten frei, um tatsächlich zu entwickeln.

Matthias: [00:37:55.97] Auch ein interessanter Punkt und es würde tatsächlich auch einem Einzelkämpfer ja nicht schaden.

Alex: [00:38:01.16] Nö, natürlich nicht.

Matthias: [00:38:03.11] In meinem Szenario könnte man noch argumentieren ein Jemand, der alleine an einer Anwendung arbeitet, muss sich ja nicht absprechen, der weiß schon, was er macht. Und natürlich kommt da dein Punkt trotzdem zum Tragen.

Alex: [00:38:15.79] Das tut mir persönlich sehr viel bringen, weil ich eben all diese Geschichten auslagern kann. Die sind an einer Stelle dokumentiert, klar, und ich muss nicht sie dauernd in mein internes Speicher behandeln. Und ich kann Speicher Ressourcen freigeben in meinem Gehirn für andere Sachen. Und vor allem wir arbeiten meistens in Teams, nicht alleine. Wissen es auch alle anderen. Wenn ich gerade mit irgendwas beschäftigt bin, dann seh ich dieses Problem oder dieses Issue auch irgendjemand anders nehmen. Man muss man vielleicht Rücksprache halten, was auch immer, aber könnte auch von jemand anders erlebt werden, Auch wenn ich den Issue reingemacht habe, wenn ich das nicht mache und keiner davon weiß, wird es auch keiner erledigen.

Matthias: [00:38:59.89] Unwahrscheinlich. Und dass das To do erledigt wird, ist fast genauso unwahrscheinlich.

Alex: [00:39:05.95] Genau. Aber das hilft ungemein. Eben sich diese Freiheit zu schaffen, um arbeiten zu können. Für mich gehört einfach dazu.

Matthias: [00:39:19.68] Er ist ein sehr guter Punkt. Also einfach wirklich den eigenen Kopf befreien von so einem Zeug finde ich gut.

Alex: [00:39:27.43] Dann hätten wir auch noch ein Thema. Die durchaus interessant ist. Die uns hilft auch, wenn manchmal so aussieht, als ob das Zeuch nur mehr Arbeit machen würde. Das ist Code Coverage Analyse, ein Tool, die die Codeabdeckung prüft. Warum ist das wichtig? Was hilft uns das überhaupt?

Matthias: [00:39:53.40] Zuallererst möchte ich sagen, dass dies ein sehr kontroverses Thema ist. Also Code Coverage ist kann ein gutes Mittel sein, um die Qualität des eigenen Codes sicherzustellen. Aber es ist halt auch nur ein Hilfsmittel. Also weil ich kann halt auch eine Codecoverage von 100 liefern, wenn die Tests eigentlich nichts machen. Also das ist ja. Eigentlich gar kein Problem. Und deswegen muss man, finde ich, bei Code-Coverage muss man ein bisschen aufpassen. Aber wenn man das Ganze natürlich einsetzt, weil man Bock hat, gute Anwendungen zu bauen, ist es eine super Sache und kann da letztendlich mir auch helfen effizienter zu arbeiten, weil ich letztendlich an dem Code Coverage Reports sehr gut ablesen kann. Welche Teile meiner Anwendung sind gut abgedeckt? Viele Tools bieten sogar solche Geschichten an. Die zeigen einem an, wie oft eine Zeile durch Tests durchlaufen worden ist. Und ich kann Stellen identifizieren, die vielleicht nicht so gut abgedeckt sind. Und dann kann ich mir darüber Gedanken machen. Werde es vielleicht sinnvoll, die besser abzudecken. Oder was spricht dagegen? Also warum ist das nicht abgedeckt? Es gibt so Geschichten, die kann man vielleicht auch nicht mit vertretbarem Aufwand abdecken. Also was mir zum Beispiel persönlich immer wieder unterkommt, sind so Szenarien wie Die Festplatte läuft voll Schreibfehler, den kannst du vielleicht unter Umständen nicht einfach so simulieren. Mag sein, dass es Systeme gibt, wo es gut geht. Vielleicht gibt es auch so ziemlich, wo es nicht gut geht. Und da muss man halt dann wieder aufpassen, dass man nicht wieder in diese Falle tappt. Zu viel Zeit aufzuwenden, um etwas abzutesten, was eventuell in 1000 Jahren einmal vorkommt oder so war übertrieben gesagt. Und da muss man eben auch abwägen. Also Code Coverage, gute Sache. Ich persönlich versuche bei meinen Anwendungen immer eine Code Coverage Größe 80 zu haben, aber ich reiß mir kein Bein aus, um die 100 haben. Ich bin auch im Zweifel mit 96 zufrieden.

Alex: [00:42:13.21] Okay, da kann man nicht allzu viel hinzufügen. In dem Fall bei dir. Code Coverage ist wichtig, damit ich sehe, wo ich vielleicht noch Tests brauche.

Matthias: [00:42:23.99] Aber viel wichtiger finde ich, ich weiß, wo ich keine Tests brauche, also nicht, was heißt, wo ich keine weiteren Tests brauche. So rum besser formuliert, weil jetzt zum Beispiel. Ich habe mal eine Zeile Code, da ist ein bisschen viel Zeug drin und ich sehe, jeder dieser Fälle ist dreimal durch Tests oder fünf mal durch Tests irgendwie abgetestet, Dann passt es für mich erst mal bis irgendwann ein Issue aufpoppt. Also da wären wir wieder bei der Geschichte mit der Premature Optimization. Also erst wenn wirklich an der Stelle des Codes, der ja augenscheinlich erst mal gut genug getestet ist, wenn da ein Problem auftaucht, dann würde ich da erst überhaupt drüber nachdenken, weitere Tests hinzuzufügen.

Alex: [00:43:08.66] Okay, und zum Thema 100 % Codeabdeckung Ich bin voll bei dir. Müssen wir 100 % Codeabdeckung erreichen? Meine Antwort ist nein. Man muss aber dazu sagen je höher eigentlich, desto besser. Aber das ist nur eine Richtlinie.

Matthias: [00:43:28.98] Ja, aber wie gesagt, also die Gefahr, dass halt so eine Metrik wie Codecoverage wertlos ist, ist halt umso geringer, je mehr Leute an der Anwendung mitarbeiten, die das gleiche Mindset haben.

Alex: [00:43:45.38] Wir haben noch ein letzten Thema, das eigentlich zwei, aber die würde ich gerne einfach gemeinsam behandeln, weil sie sehr eng miteinander verknüpft sind. Sie heißen Continuous Integration und Continuous Delivery. Und was kannst du uns dazu sagen? Warum helfen uns diese Methoden, diese Techniken effizienter zu sein?

Matthias: [00:44:06.89] Also zuerst fällt mir auf, dass du gerade gemacht hast, was in der Softwareentwicklung auch gar nicht so unüblich ist. Man wirft sie CI und CD zusammen.

Alex: [00:44:17.15] Die sind nicht das gleiche, die sind nur eng.

Matthias: [00:44:19.55] Ja, nee, nee, mit Zusammenwerfen meine ich, das ist ganz häufig ja auch so ist, dass sie und sind, die in der gleichen Pipeline stattfindet. Ja und? Und auch da habe ich jetzt schon Argumente gehört, die sagen, eigentlich sollte man das trennen, weil es gehört eigentlich sowieso nicht zusammen, aber das ist wahrscheinlich ein anderes Thema. Ich fange einfach mal mit CI an, also Continuous Integration. Was wir damit erreichen wollen oder was uns das bringt, ist letztendlich, dass wir unseren Codestand. Also wir hatten es ja vorhin, dass wir Durch Versioncontrol Systeme sind wir in der Lage von unserem Code einfach wegzugehen und Änderungen vorzunehmen. Und die müssen aber ja irgendwie wieder integriert werden und das wollen wir halt möglichst automatisiert machen können. Und dafür gibt es dann eben auch sogenanntes CI-Pipelines, also Continuous Integration, Pipelines, die letztendlich dafür sorgen, dass unser Projekt zum Beispiel gebaut wird, getestet wird. Irgendwelche Codesscans drüberlaufen, die Ergebnisse irgendwohin publiziert werden. Und wenn das alles passt, und wenn es keine Probleme gibt, dann kann der Merge durchgeführt werden. Da ist es mal ganz trivial, wie Continuous Integration Pipeline beschrieben. Und wenn wir jetzt von Continuous Delivery reden, dann reden wir weniger von der Tätigkeit, den Code zusammenzuführen, sondern vielmehr von der Tätigkeit unsere Artefakte, also zum Beispiel ein jar, das bei unsere Continuous Integration Pipeline rauspurzelt und vielleicht in irgendeine ein Paket Management Tool gepackt wurde, das irgendwohin zu delivern, zu liefern. Also Continuous Delivery also. Und auch der Prozess soll möglichst automatisiert ablaufen. Das heißt, ich habe auch irgendwo eine der zum Beispiel einen Jenkins oder so was, der sich dann darum kümmert, dass unser Artefakt aus dem Paket Management wieder rausgeholt wird und zum Beispiel auf einen Server ausgeliefert wird.

Alex: [00:46:28.52] Okay.

Matthias: [00:46:29.72] So mal die grobe Beschreibung würde ich sagen.

Alex: [00:46:32.48] Und wofür ist das gut? Das klingt ja sehr viel Arbeit.

Matthias: [00:46:35.61] Ja, aber.

Alex: [00:46:37.33] So effizient klingt.

Matthias: [00:46:38.45] Das nicht. Natürlich ist es Arbeit. Stell dir mal vor, du musst das alles manuell machen. Also fangen wir bei CI an.. Das bedeutet ja, also ich und tatsächlich den Schritt oder den Prozess, den ich jetzt beschreibt, den habe ich in meinen Anfangszeiten. Und das ist noch nicht so lange her. Also wir reden hier von so vor 10 bis 12 Jahren erlebt. Also wir hatten einen, der war dafür zuständig, Sachen zu mergen. Also das war der einzige, der bei uns Sachen in den Hauptbranche gemerged hat. Also der war quasi vollzeitbeschäftigt. Der hat von fünf oder sechs Entwickler und Entwicklerinnen die Änderungen sich alle haarklein angeguckt und das manuell gemerged und dann auch manuell veröffentlicht. Und wie gesagt, der Typ hat nichts anderes mehr gemacht. Und wenn man jetzt tatsächlich überlegt, dass ich vielleicht, sagen wir, ich bin mal großzügig, wir brauchen zwei Wochen, um diese beiden Pipelines zu bauen. Nach diesen zwei Wochen ist dieser eine Typ, der vorher Vollzeit beschäftigt war, frei verfügbar, kann wieder mitarbeiten. Ich würd mal sagen, bringt uns was.

Alex: [00:47:53.30] Was. Effizienzsteigerung.

Matthias: [00:47:58.31] Also das alles händisch zu machen, ist ein unglaublich langweiliger, zeitintensiver und fehleranfälliger Prozess, den ich niemandem zumuten möchte. Das können Maschinen zehn Mal besser. Zehn, wenn es reicht, wahrscheinlich tausendmal besser, wenn es reicht.

Alex: [00:48:17.69] Tatsächlich? Also sie ist. Die sind für mich ein Automatisierungsprozess, die dazu führen, dass unsere Anwendung integriert wird und dass das dazu führt, dass unsere Anwendung deployt wird. Geliefert wird was auch immer.

Matthias: [00:48:32.03] Und das auch, wenn der eine Typ, der das alles manuell macht, krank ist. Weil dann gibt es kein da gibt’s kein Release mehr, weil.

Alex: [00:48:41.54] Natürlich muss man halt warten, das ist völlig normal. Also CI/CD ist Automatisierung. Und alles was Automatisierung ist, bedeutet eine Effizienzsteigerung, weil ich mich nicht manuell darum kümmern muss. So würde ich es jetzt mal auf den Punkt bringen. Und natürlich sind das Aufgaben, die wir immer wieder machen müssen, immer wieder machen müssen. Was du gesagt hast, das ist nicht getan. Indem wir es einmal machen, dann muss man es nicht mehr machen. Wir müssen dauern, unsere Änderungen integrieren oder miteinander zusammenlegen. Und wir müssen auch dauernd Versionen liefern, Änderungen liefern und unseren Kunden. Deswegen, wenn wir das automatisieren können, sollten wir es auch tun. Es gibt genügend Tools, die uns das erlauben und ermöglichen, vereinfachen. Also warum sollten wir sie nicht nutzen? Also ich finde es tatsächlich eine sehr gute Möglichkeit. Tja, dann sag ich so gut Matthias fass zusammen.

Matthias: [00:49:45.97] Ja. Also, was haben wir denn heut gehört? Also wir haben heut uns über Coding Techniken zum einen unterhalten, wie wir quasi unsere tägliche arbeit effizienter am code organisieren können. Haben da über zum Beispiel Mocks geredet oder die Prmature Optimization, sowas wie das YAGNI-Prinzip. Aber auf der anderen Seite eben auch über Organisatorisches. Also wie können wir unseren Prozess besser organisieren? Und darunter fallen eben so Geschichten wie das Versionskontrollsystem, dass wir unsere Issues tracken. Habe ich auch wieder was dazugelernt? Kopf freikriegen ist auch eine Form des Effizienzgewinn, der durch Issue-Tracking herbeigeführt werden kann. Das habe ich tatsächlich nie so drüber nachgedacht, aber finde ich gut. Und wie wir jetzt eben gerade noch eben gehört haben Code, Coverage, CI und CD, das glaube ich, ist noch ganz gut im Gedächtnis. Dann würde ich sagen, sind wir doch am Ende von unsere Folge heute angekommen.

Alex: [00:50:54.69] Du hast heute erfahren, wie du effizienter arbeiten kannst.

Matthias: [00:51:00.45] Dabei sind wir eben nicht nur auf die Programmiertechniken eingegangen.

Alex: [00:51:04.17] Sondern haben auch darüber gesprochen, wie unsere Arbeit besser organisiert werden kann.

Matthias: [00:51:09.72] Deswegen sei auch beim nächsten Mal einfach wieder mit dabei, wenn wir über das Thema Erweiterbarkeit sprechen.

Alex: [00:51:14.54] Ich empfehle gern diese Folge weiter, wenn sie dir gefallen hat.

Matthias: [00:51:18.69] Bis zum nächsten Mal.

Alex: [00:51:20.37] Ja.

off: [00:51:23.46] Die Macht der Craft Arbeitet für dich.