Wir müssen jetzt noch ein paar neue Features reinpacken und wenn wir das haben, dann können wir quasi refecto und das ist meiner Meinung nach eine riesengroße Lüge. Dein Podcast rund um Softwareentwicklung und aktueller Tech News. Herzlich Willkommen. Ja, herzlich Willkommen zur neuen Folge des Coding Bodies Podcast. Schön, dass du wieder
eingeschaltet hast. Wir sind natürlich wieder mit am Start. Einerseits meine Wenigkeit Tino und natürlich auch wieder fantastische Fabi, Fabi, Grüß dich neue Folge. Halli Hallo. Und hast du Bock, kann losgehen. Die Sonne scheint einfach super jetzt hier im Podcast aufzunehmen.
Ich meine es hat die letzten Wochen gefühlt nur geregnet, der Regen ist vorbei, genau der Regen ist vorbei, die ersten Sonnenstrahlen kommen raus, da wird es natürlich Zeit einfach wieder in der Bude. Zu setzen und Podcasts aufzunehmen. Da kommt man nicht drum. Drin, ne. Bude zu sitzen, ja. Das gehört einfach als Entwickler dazu, wirklich
dauerhaft drin zu sitzen. Nein, wir haben natürlich ein spannendes Thema mitgebracht, deswegen freue ich mich sehr auf diese Folge, wir haben es ja auch schon mal angeteasert oder gemerkt, dass dieses Thema einfach wirklich wichtig ist und deswegen wollen wir heute ja über da da, da, da Riff. Reden. Ich dachte da, da, da. Da da, Nein, das war nur ein Trommelwirbel, hab ich jetzt
nicht so hingekriegt. Nein, also das Thema ist refactoring hab ich Bock drauf, lass uns da mal ein bisschen drüber quatschen was ist eigentlich refactoring, was sind die vor und Nachteile oder auch Herausforderungen dabei und warum erachten wir als sehr wichtig, deswegen würde ich dir jetzt mal das Wort geben und fang doch einfach mal an, erklär doch mal unserer Community was refactoring ist. Ja, ich mach glaub ich einfach kurz.
Bei Refactoring handelt es sich darum, dass man die Qualität seines Codes erhöht, ohne. Dass die. Funktionalität verändert wird. Und das ist prinzipiell eigentlich schon Factory. Die Frage. Ist ja eigentlich, das war wirklich sehr kurz und knapp. Aber ja, das trifft es eigentlich ganz gut. Kannst du das noch ein bisschen weiter ausführen, damit das Bild vielleicht noch ein bisschen klarer wird?
Und zum Beispiel auch mal nennen, warum du denn denkst, dass es wichtig zum Beispiel dadurch die Code Qualität zu erhöhen. Und wie erhöhe ich denn dadurch die Qualität? Aber was meinst du jetzt mit
genauer ausführen? Also es kann natürlich also meine, also wieso muss man überhaupt defekt, dann kann man sich ja vielleicht fragen, wenn man also es gibt ja keine, sich hinstellen und sagen, mach doch gleich von Anfang an richtig, da musst du nicht defekt da, da musst du deine Code Qualität nicht erhöhen wenn du schon am Anfang auf deine Qualität achtest, richtig so, das könnte man ja durchaus in Raum werfen,
ne? Hatte ich witzigerweise sogar mal ein Gespräch mit einem mit einem Projektmanager, der mich tatsächlich auch genau das gefragt hat, weil da ging es nämlich darum, dass wir, dass wir sozusagen unsere Anwendungen defekt, dann mussten, muss man regelmäßig machen, Spoiler Alarm und da war dann so ein bisschen die Diskussion, dass er, glaube ich selber n bißchen in die Bredouille geraten ist, weil irgendwie was fertig werden musste und dann hat er irgendwie
gemerkt, dass ein paar Entwickler.
Im Team reflektiert haben und sozusagen den Fortschritt, der also die Funktionalität, wie ich ja meinte, Ne nicht vorangebracht habe, nicht verändert haben von der Anwendung aber halt die Code Qualität erhöht haben, so wie ich das ja gerade eben schon so von der Definition meinte und dadurch, dass es aber nicht funktional voranging, hat er glaube ich so ein bisschen ist er also der Projektmanager n bisschen schwitzen gekommen weil irgendwas gedrängt hat und.
Weil an zu dem Zeitpunkt das Projekt an sich. Auf dem Papier nicht weiter. Vorwärts kommt nicht genau genau also wie gesagt, die Funktionalität geht nicht weiter, erhöht die Code Qualität, was natürlich wichtig ist. Darüber wollen wir jetzt reden, aber es war auf jeden Fall so dieses Gespräch im Raum ne einfach aus dem Grund, dass ihm halt damit der Schuh gedrückt hat. Manche nennen es vielleicht Deadline, manche nennen es irgendwie anders. Meilenstein. Ja, also.
Das Erreichen von. Meilenstein genau. Und natürlich kommt dann irgendwie so ein bisschen, sag ich mal, das Gespräch auf. Ja, warum können jetzt nicht alle mal ein bisschen hier Gas geben und n bisschen ne n bisschen machen, bitte, dass wir weiterkommen anstatt jetzt die Qualität zu erhöhen und da kam dann irgendwann in diesem Gespräch die Frage von ihm. Ja, aber wenn man jetzt zum Beispiel sagt, OK, wenn ich jetzt komplett ein neues Projekt aufsetze, muss ich dann irgendwann zwangsläufig
irgendwann recht? Dann, und die Antwort war halt ja, das muss man halt machen, weil du gar nicht drum herum kommst, dass du, also du kannst es nicht schaffen, die ganze Zeit perfekt alles zu coden, weil du ja teilweise auch gar nicht weißt, wo solls denn hingehen, dann kommen neue Anforderungen, der Code ändert sich, du musst vielleicht irgendwelche Strukturen in deinem Code umstellen und dann kommt es halt dazu, dass du irgendwann regelmäßig mal wieder
gucken musst. Oh, hier ist was was verbesserungswürdig ist. Ne und? Naja, da kommt das zum Beispiel auch schneller oder ist das passiert? Ja schnell mal genau, wo man dann doch nochmal durch seinen alten Code durchschaut, aber zu deinem Beispiel oder zu deine Erfahrungen, die du da gemacht hast. Was war das denn jetzt? Ein kritischer Punkt, dass ihr lange nicht reflektiert hattet und deswegen ein erhöhter refecto Aufwand aufkam?
Oder war es eigentlich eine Sache von maximal ein 2 Tagen und die wollte euch quasi schon nicht? Eingestehen, sag ich mal. Na also, es ging glaube ich schon so. Also der Aufwand des Refactoring was wir hatten hat sich glaube ich über ein 2 Wochen hingezogen und das war immer ungefähr ein Drittel des Teams saß dann da dran und ich hab das auch n bisschen gepusht an der Stelle, weil mir das halt auch schon länger aufgefallen ist, dass man
das hätte machen müssen. Und das ist dann halt irgendwie
einfach. Irgendwann musst du halt mal sagen, OK, jetzt wird es gemacht, weil das Problem ist ja meistens, dass gerade in solchen Projekten im Arbeitsumfeld gerne mal gesagt wird, ja, das machen wir dann später, ne, das wird dann irgendwann mal gemacht, das wird irgendwann refecto, irgendwann wird die Qualität erhöht, aber erstmal müssen wir jetzt noch was liefern, wir müssen jetzt noch ein paar neue Features reinpacken und wenn wir das haben, dann können wir quasi
reflektieren, und das ist meiner Meinung nach eine riesengroße Lüge. Weil man das halt einfach nicht konsequent durchzieht, weil du immer was zu tun hast. Es kommen immer wieder neue Sachen, die irgendwie reinkommen müssen und dann bist du halt irgendwann an dem Punkt, wo du sagst, also irgendwann musst du halt mal sagen, jetzt zieht die Reißleine, jetzt wird reflected ne und es geht ja um nochmal n bisschen drauf zurückzukommen, was du gefragt hast.
Ne, wieso muss man denn überhaupt perfekt, dann kann nicht von vornherein alles richtig machen. Angenommen Du arbeitest im Team ne und sagen wir mal wir beide. Ne arbeiten im Team, arbeiten an 2 verschiedenen Stellen im Code. Ich schreib irgendwas, du schreibst irgendwas so vielleicht parallel, vielleicht schreiben wir Code teile die sehr sehr ähnlich sind, weil es gerade zufälligerweise so ist. Ne und jetzt kommt irgendwann ein Dritter.
Und guckt sich das an. Und denkt sich irgendwie, warte mal, da ist eine Funktion, die S sehr ähnlich zu dieser Funktion. Vielleicht kann ich ja irgendwie ein kleines Refactoring machen, ne? Also Refactoring hat ja verschiedene verschiedene Punkte, ein Punkt davon ist ja zum Beispiel Redundanz zu beseitigen und wenn du merkst, dass zum Beispiel eine Funktion oder funktions teil redundant irgendwo im Code rumliegt, dann kannst du halt diesen teilnehmen
extrahieren. Sodass, wenn eine Änderung an diesem Code teil stattfindet, dass du dann nicht in diesem Punkt kommst. Du sagst OK, ich hab jetzt den Code teil verändert, aber es gibt quasi noch einen sehr ähnlichen oder gleichen Code teil der woanders liegt und der ist dann sozusagen nicht angepasst oder halt in dem Falle danach fehlerhaft. Ne, das heißt?
Fehleranfällig. Genau das heißt das, dass das sind ja so bestimmte Sachen und sowas kann halt auftreten, das kannst du im Vorfeld nicht unbedingt planen. Du kannst nicht sagen, ja, ich schreibe jetzt diesen Code und diesen Code, dann müsste man also dann hast du ja vielleicht
n utopisch. Hohe Absprachen, Aufwand, wo man dann sagt, OK, jeder muss jetzt irgendwie besprechen, was irgendwie jede Funktion, die ja implementiert muss, abgesprochen werden, ne, und deswegen ist es halt einfach so, dass man einfach regelmäßig reflektieren muss, damit kann man von vornherein direkt ins Projekt starten, in egal wo man ist, man kann immer direkt sagen, OK, jetzt geht irgendwas los und irgendwann müssen wir mal defekt, dann die Frage ist nur
meiner Meinung nach. In welchen Schritten möchte machen regelmäßig immer n bisschen oder in längeren? Abschnitt Bang dann machen, aber das ist ja genau der Punkt oder das, was ich jetzt noch sagen wollte ist, weil du meintest du hattest das schon länger so das Gefühl, oh da müssten wir mal reflect, dann wurde es weiter aufgeschoben, aufgeschoben und am Ende war es ein Aufwand von ein 2 Wochen.
Klar jetzt nur für ein Drittel des Teams aber dennoch ne, also würdest du sagen man hätte definitiv früher Reflektoren müssen, damit das auch einfach schneller erledigt ist. Also hat sich das wirklich aufsummiert oder lag es einfach nur und defector Aufwand war gleich wie vor meinetwegen ihr hättet das 2 Monate früher gemacht.
Ja, gute Frage. Also das war tatsächlich ist auch ein bisschen schwierig manchmal so, ich glaube, da gibt es nicht so die hundertprozentige Antwort, zumindest in diesem Fall nicht, weil es gab, also wir hatten einen bestimmten Stand und wussten aber zu diesem Zeitpunkt auch nicht hundertprozentig, wo es dann genau weitergeht, ne, irgendwann hat sich heraus kristallisiert.
OK, es wäre aber auf jeden Fall wichtig, dass wir unsere Struktur des Codes generell, also ein bisschen, ich sag mal, das war schon eher so ein Teil auf architektonischer Ebene und umbauen wollten. Und das hat sich dann irgendwann herauskristallisiert, dass auch Sinn macht.
Und dann kam der Punkt, wo wir gesagt haben, o, wir machen das mal bloß, dass wir dann im Team ein gesamtes Grundverständnis für alle schaffen, wollten, wir s machen wollten, weil es bringt ja nichts, wenn du sagst, die Hälfte des Teams weiß jetzt so, wie es läuft und wie man das Refektorium möchte und die andere Hälfte des Teams arbeitet nach dem Refactoring beispielsweise genauso weiter wie vorher und dann kannst du eigentlich, dann bringt es ja nichts.
Dann arbeiten 2 t, also 2 Teile des Teams in völlig unterschiedliche Richtungen. Und dann ist der Code hinterher.
Kraut und Rüben ne, aber wir mussten halt irgendwie diesen diesen diesen Zeitpunkt finden oder diesen Termin erstmal machen, diesen Workshop, worauf dann halt auch erstmal wieder vielleicht keiner so richtig Lust hat, muss sich hinsetzen und muss nachdenken und und das war irgendwie auch so n bisschen Punkt. Also man braucht natürlich die Zeit und die Zeit muss man sich dann irgendwann nehmen und dann haben wir sozusagen alle im Team Brainstorming darüber
nachgedacht, wie wir das machen wollen. Und dann? Danach ging es halt eigentlich erst richtig los, ne? Ich frage, weil ich hab halt die Erfahrung gemacht, dass oftmals so ist, wenn man schneller in diese in diesem Zyklus kommt oder sagt, OK ich reflecta jetzt, ich dreh jetzt noch mal die Runde und schaue nochmal alles durch und optimiere und steige ja damit hoffentlich auch die Code Qualität, dass es für die weiterführende Entwicklung halt auch viele Verbesserungen mit sich bringt.
Also das heißt ja nicht, dass dieser Aufwand nicht statt oder irgendwie mit steigt, sozusagen ne, weil wenn du jetzt zum Beispiel. Funktionen, reflectors, Schnittstellen oder Whatever kann es ja sein, dass die neuen Features, die du implementierst, sich viel besser und leichter implementieren lassen oder im Worst case du noch auf dem alten Code aufsetzend das Weiterentwickelst und das auch alles dann wieder reflektiert werden muss, wenn du einmal dann
anfängst. Und so skaliert das ja quasi dann auch oftmals mit der Aufwand ja definitiv keine gute Sache ist. Deswegen hab ich gefragt, ob du einschätzen würdest, dass es hätte viel schneller erledigt werden können. Wenn es natürlich jetzt ne Entscheidung in der Architektur ist oder so, dann wird wahrscheinlich auch gleich bleiben, weil es ja wahrscheinlich ja ein sehr grundlegender Umbau war dann.
Aber im Allgemeinen, wenn es um einfache, quasi Optimierung der Funktionalitäten ist der Schnittstellen, dann finde ich, dass es meistens wirklich besser ist, relativ schnell in diesem System in diesem reflector Zyklus zu kommen, um halt einfach sich auf das Leben danach leichter zu machen. Ja, auf jeden Fall. Also das, wir hatten ja auch im in der Test Driven Development Folge auch darüber geredet, dass gerade Test Driven Development ja genau diesen refactoring Part
jedes Mal mit drin hat. Ne, und dann? Sorgt er auch? Dafür, dass du regelmäßig das machst. Es kommt halt immer drauf an, weil für mich ist es so, dass es so unterschiedliche Arten von Refactoring gibt, und zwar entweder du reflectors nur eine Funktion oder eine Klasse oder halt wie gesagt dann auch ne, vielleicht auch ne ganze die ganze Software, die die Architektur dieser Software n bisschen unterschiedliche Ebenen und in dem Fall was ich jetzt gerade.
Eingeführt hatte. Da ging es halt wirklich darum, dass sich dann langsam herauskristallisiert hat, dass es besser ist, dann nochmal ein bisschen zu wechseln.
Und wenn du aber zum Beispiel am Anfang sag ich jetzt mal ne andere Annahme getroffen hast, weil die Anforderungen von der von der Software auch anders sind und sich dann aber ändern, dann kann es halt einfach dazu führen, dass man sowas machen muss, das sind da manchmal größere Umbauten, das stimmt, aber wie du auch schon meintest, je länger man damit wartet, desto länger zieht sich das am Ende trotzdem, auch wenn es erstmal ein größerer Aufwand ist, ne?
Ja, also zum Beispiel, wenn man jetzt sagt, OK, man hat 10 Klassen und muss die grundlegend, sag ich jetzt mal refecto irgendein Beispiel zu bringen und dann sagst du ja, wir machen das noch, wir machen das noch und dann hast du aber irgendwann 15 Klassen, sag ich jetzt mal, wo du das machen musst. Ne ist jetzt sehr effektiv gewesen, aber ich hoffe du konntest das Beispiel nachvollziehen. Aber wir können ja ein reales Beispiel bringen aus unserem aktuellen Projekt, von der
Arbeit aus. Da war das ja so, dass wir uns entschieden haben, unsere kompletten Test zu reflektieren, aber auch im Sinne von, dass wir das Test Framework umgestellt haben, und das ist ja schon ein großer Aufwand gewesen durch alle, also wirklich alle testen, neu zu schreiben beziehungsweise nochmal durchzugucken und quasi in das neue Framework zu überführen, wo sich auch Leute denken könnten, warum eigentlich, also warum macht ihr das?
Die Tests laufen, also das alte Test Framework hat funktioniert. Ja, nur haben wir festgestellt, je länger man damit arbeitet, so na, war vielleicht nicht die richtige Entscheidung. Hätten doch lieber das andere Framework nehmen müssen und ja, am Ende haben wir es ja umgebaut, zum Beispiel deshalb, weil es einfach wesentlich performanter war und die Tests
schneller liefen. Ja, jetzt kann man sich ja denken, ja gut, läuft halt n paar Sekunden schneller oder so, aber was das auch für den Aufwand beziehungsweise in der Summe dann ausmacht, weil wie gesagt Test driven wir lassen
nicht sehr oft. Laufen die Tests ne, also was du da denn hinten raus wieder an Zeit sparst hätte man sagen können, lass es einfach, also so früh wie möglich hätte man diesen Umbau machen müssen, auch wenn natürlich dann erstmal keine Features implementiert, sondern ja eigentlich nur seine Test Abdeckung neu aufsetzt sozusagen.
Ja, aber das ist, das ist ein guter Punkt, weil gerade dieser, weil du das gerade ansprichst, so dieses aufschieben, ne was was finde ich immer sehr, sehr wichtig ist. An dieser Stelle ist, dass man, wenn man sagt.
Okay wir müssen jetzt erst mal vorankommen, ne, und beispielsweise wir sagen ja, lass mal das Refactoring noch n bisschen, wir müssen jetzt erstmal feature ABC machen und wenn wir das haben so das Problem ist, wenn du dann aber sag ich mal an den Punkt kommst und sagst ich hab jetzt Feature ABC fertig und sagst jetzt würde ich gerne Reflektoren und dann hat heißt es aber vielleicht jetzt müssen wir noch DF machen und dann können wir weitermachen und dieses aufschieben ne und
irgendwann hat bist du in diesem in diesem Modus das sozusagen. Du sogenannte technische Schuld aufbaust, weil du dann vielleicht noch mal ein Workaround gemacht hast und Bekanntlicherweise bleiben Workarounds für immer in der
Software drin. Nee, aber also das, das ist halt das Problem, das heißt du in, ich sag jetzt mal, wenn man, wenn man jetzt von so einem, ich sag mal Zyklus spricht, es waren zum Beispiel sagt, OK, du hast jetzt eine bestimmte Menge an Features, die neu reinkommen, aber du hast nicht, dann kommen die, der nächste Zyklus ist, kommen also wieder n neue Menge an Features rein, du Effekt das nicht und am Ende hast du quasi für jeden für jeden in die für jeden Zyklus wo du diese diese
wo du nicht defekt. Das erhöht sich ja. Der Aufwand des Refactoring und zusätzlich kommen wir aber trotzdem regelmäßig über Features.
Das heißt, wenn du sagst, du brauchst keine Ahnung Monat für alle Features und hast dann keine Zeit mehr, bräuchtest du aber ein sozusagen Monat und eine Woche für Feature und Refactoring, dann brauchst du im nächsten Zyklus wieder einen Monat für die Features, aber vielleicht 2 Wochen für das Refactoring. Und irgendwann mal unwahrscheinlicher, dass das irgendwie gleichzeitig alles noch hinkriegt. Genau rechtzeitig.
Und irgendwann kommt man vielleicht an den Punkt, wo man dann, und dann kommt dieser Big Bang, von dem du geredet hast. Ne, dass du vielleicht den ganzen Zyklus einfach nur für das Refactoring brauchst und dann kommt wieder jemand und sagt, ihr habt ja gar nichts geschafft. So, und das ist halt das Allerschlimmste finde ich, weil wenn du dann sozusagen als Entwickler hörst.
Ja, ihr habt ja nichts geschafft und du denkst dir pass auf das, was wir gerade geschafft haben ist, dass wir überhaupt für die Zukunft eine Grundlage gelegt haben, dass diese Software überhaupt noch weiter existieren darf, das ist halt der finde ich, dass das krasse, weil da denkt niemand daran, ne, sozusagen dieses. Ich denk mal n bisschen weiter und überleg mir mal, soll diese Software denn überhaupt noch in Zukunft existieren oder wollen wir so lange Features machen bis
das Ding implodiert? Weißt du und. Das ja, das ist ein echt guter Punkt. Aber also ich bin da voll auf deiner Seite, ne, aber ich erwische mich auch selbst dabei, dass manchmal.
Wenn dann halt im Projekt Stress aufkommt, man sich auch verleiten lässt zu sagen, ja, OK, wir machen jetzt die und die Funktionalität bauen wir noch ein, aber dann werden wir wirklich mal reflektieren, weil du weißt eigentlich schon, du hast es wirklich vor Augen, du hast am besten schon eine to do Liste eingelegt, was alles gemacht werden muss, ne und die guckst du dir jeden Tag an und denkst dir, na gut, aber jetzt noch Feature AB und dann dann wirklich so, also man das ist
halt auch schwer da so richtig konsequent zu sein finde ich manchmal. Weil du ja wirklich keine Ahnung kommt dein Produkt oder zu dir und sagt Hey, müssen das jetzt wirklich in dieser Iteration mal fertig kriegen so ne und im Hinterkopf hast du o meine ich würde aber echt gerne vorher noch einmal durchgefallen, weil das gefällt mir gar nicht mehr
so wie der Code aktuell ist. Also in diesen diesen Modus kann man halt schneller reinfallen als man denkt, also es ist halt leicht gesagt zu sagen ne machen wir jetzt nicht wie dann weil irgendwann kommt halt auch mal der Projekt Stress unter, dieser reicht der Druck von außen da drauf ne. Aber meinst du nicht, dass es rein theoretisch. Eigentlich. Mit inbegriffen sein sollte, dass man sagt ich also Software zu schreiben beinhaltet eine gewisse Art von Refactoring. Ja, sollte es also.
Das ist ja dann aber auch wieder eine planungs Sache. Dass du dir die Zeit halt dafür aktiv einplanen und quasi das Wissen im Team oder auch im Projekt herrscht. Dass das damit drin ist, also dass das nicht nur Features beinhaltet, sondern auch die Wartung der Software, halt ne. Also ich hab mal gehört, dass man ungefähr im Normalfall, und das ist absolut realistisch, 20 bis 30% initial schon immer, immer wenn Software Entwicklung stattfindet, für das Refactoring
einplanen muss. So, und da sind wir dann zum Beispiel auch wieder an diesem Punkt, weil ich ja meinte, dass ein Drittel des Teams bei mir in dem Beispiel, was ich vorhin genannt hab, was mir, was mir passiert ist, haben. Wir hat ja ein Drittel des Teams daran gearbeitet und rein theoretisch, und das war nur für über 2 Wochen. Die müssen dauerhaft dann eigentlich. Das rein theoretisch muss dauerhaft passieren und daran
denkt halt immer keiner so und. Aber da würde mich wirklich mal Hand aufs Herz interessieren, bei wie vielen Leuten das so läuft. Also ich bin da wirklich ganz bei dir und das sollte so auch sein, weil das macht dir das Leben wie gesagt langfristig auch echt besser ne, aber ich glaube, dass das selten der Fall ist, dass du so viel Zeit dafür eingeräumt bekommst. Wenn du es dir nicht aktiv nimmst und dafür kämpfst halt ne, deswegen ja dann.
Muss man sich glaube ich, einfach mal hinstellen und sagen, Nein, das schaffen wir nicht, das geht nicht, ich ja, weiß ich nicht, ich bin ich, ich hab da schon so viel erlebt, dass also aber auch, also weißt du diese.
Meistens hast du die Entwickler, die sagen ja, das stimmt so, das ist ja, alle sind quasi einer Meinung, nur dann kommen irgendwie sag ich jetzt mal so aus Management kreisen oder so mal blöd gesagt, weil die halt ganz andere ist ja logisch ne die haben ganz andere Blickwinkel auf die Dinge und da treffen manchmal Welten aufeinander, das ist eigentlich manchmal ganz schön. Doof, ganz schön doof.
Wäre ja gut, Missverständnisse gibt es immer ne, ich würde aber sagen wir haben das ja ausführlich diskutiert, warum es wichtig ist. Und auch Vorteile genannt. Genau, ich würde sagen, lass uns die Folge hier beenden, ich denke wir haben das Refactoring ordentlich besprochen. Ja, ansonsten, wenn ihr da draußen als Zuhörerinnen und Zuhörer noch ein bisschen mehr über Factoring wissen wollt oder euch nochmal ein paar Themen interessieren, dann einfach mal.
Schreibt uns einfach bei Instagram. Wie gesagt, wenn euch generell auch Themen im Podcast interessieren, einfach immer her damit wir. Gehen da gerne auf eure Wünsche drauf ein und ansonsten guckt einfach mal. Ja, einfach auf unsere anderen Plattformen, die links zu den anderen Plattformen findet ihr in den Show Notes. Vergesst nicht, den Podcast ZU liken und euren Freunden und Freundinnen zu empfehlen, falls euch. Die Folge? Gefallen hat und in diesem Sinne hoffen wir, dass wir uns beim
nächsten Mal wieder hören. Und macht euch noch einen schönen Tag. In diesem Sinne eure. Cordis gemeinsam besser.