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.