Ja, dann mach ich das. Halt trotzdem ne, aber trotzdem
würde ich zumindest im Team einmal.
Challenge. Genau.
Und. Dann ist halt wieder die Frage 1
gegen 20. Coating Boys, Dein Podcast rund
um Softwareentwicklung und aktueller Technews.
Herzlich Willkommen. Herzlich Willkommen zur neuen
Coding. Buddies Podcast Folge Es geht
wieder los. Dabei ich der Fabi und natürlich
nicht zu vergessen der fantastische Dino Dino.
Grüße dich. Moin Moin Fabi, Was geht ab?
Was geht denn ab? Ja, das geht noch.
Lass mal ne neue Podcastfolge aufnehmen.
Wir hatten ja im Vorfeld mal schon n bisschen drüber
gequatscht, was wir machen. Ich werde es mal kurz mal auf
den Punkt bringen, worum es heute geht.
Und zwar hatten wir ja schon mal n paar folgen bisher über
Cleancode gemacht, ich glaube 4 folgen sind es bisher insgesamt
über Cleancode. Und das ist ja immer alles schön
und gut, ne, also man sagt ja auch zum Beispiel OK Mensch,
hier macht bei Cleancode, dies macht bei Cleancode das wir
haben ja schon mal so n bisschen darüber geredet, wie man
Variablen und Funktionen benennt.
Beziehungsweise wie man vielleicht auch Funktionen
aufbauen sollte. Oder zum Beispiel, wie es laut
Cleancode zum Beispiel auch. Kommentare also mit Kommentaren
im Code, sozusagen. Wie es sich damit verhält.
Und zusätzlich, was auch irgendwie find ich n bisschen
mit da rein spielt, darüber haben wir auch schon mal geredet
über Refactoring von Code und ich find das immer alles ganz
interessant, weil rein theoretisch weiß man ja oder
kann man ja theoretisch sagen ey es gibt.
Prinzipien, die du vielleicht anwendest über n Paar, wie die
ich gerade genannt hab, haben wir ja schon gesprochen, werden
ja noch weitere folgen, aber prinzipiell kann man ja sagen,
OK, das sind Best practices und wenn man jetzt zum Beispiel
sagt, OK, MAN kennt diese Best practices, sie existieren.
Aber wieso zum Beispiel findet man denn trotzdem immer wieder
Code, schreibt selber mal wieder Code, die sich eben nicht an
diese Best practices oder an diesen Cleancode halten, halten
so, also wieso muss man zum Beispiel immer wieder.
Trotzdem noch mal refect, dann etwas verändern im Code, obwohl
man ja eigentlich weiß, OK, das und das, so funktioniert es
richtig, das ist quasi best practice, darüber können wir
heute mal n bisschen quatschen, oder?
Der ist eigentlich ein ganz cooles Thema, vor allem auch so
als kleines Zwischenfazit. Schon finde ich das cool, also
man kann ja im Prinzip sagen, wir haben jetzt schon 4 folgen
die Theorie erklärt. Oder wie man theoretisch clean
und Code schreibt. Und können ja jetzt mal so n
bisschen auf die Gefahren in der realen Praxis eingehen.
Genau, warum es denn halt doch nicht so einfach ist, einfach
diese Theorie umzusetzen. Ja, das find ich eigentlich ganz
cool, dann lass uns doch schauen, ob wir da einfach so
verschiedene Punkte herauskristallisieren können,
vielleicht so aus unserer eigenen Erfahrung.
Ja, da fallen mir jetzt auch. Schon so mindestens 23 ein, was
ich so aus in meinen eigenen Projekten oder in unseren
Projekten so erlebt habe. Das finde ich cool.
Unter dem Motto Theorie versus Praxis.
Genau, ich hau einfach mal den ersten Punkt raus, weil ich
denke, denen werden viele kennen, die sich in die gleiche
Situation hineinversetzen können oder schon mal waren.
Ist so dererste.in meinen Augen, dass es ganz oft mit Zeitdruck
zu tun hat. In dem Moment, wenn ich zum
Beispiel mein Projekt wirklich enorm Zeitdruck bekomme und
Sachen fertigstellen muss, also fertig programmieren muss, dass
ich dann geneigt bin, dazu eventuell nicht mehr alles nach
Best Practice zu Cohen und so super clean arbeite, sondern
anfange, Sachen rein zu zufrieden, sage ich mal, also
erstmal so dieses typische, naja, das geht ja erst mal so,
das ist jetzt erstmal eine Lösung und dann kümmern wir uns
irgendwann darum. Dieses Problem haben wir auch
schon öfter mal besprochen. Aber ich finde, das greift hier
auch wieder als Grund, warum es in der Praxis nicht so einfach
ist, immer wirklich cleancode umzusetzen.
Mind. Catsulator Equels Never oder
was? Machen wir erstmal so machen wir
es. Später, das ist denn das
Folgeproblem, was daraus entsteht, da hatten wir ja mal
ne Folge zu gemacht, aber ich finde, dass Zeitdruck halt oft n
Grund ist, überhaupt in diese Situation zu kommen, dass man
sagt, OK, das ist jetzt eigentlich nicht mehr so nach
Lehrbuch. Aber es geht halt gerade nicht
anders. Dieses typische ja, aber wir
können es gerade nicht anders machen, weil wir die Zeit nicht
haben. Deswegen finde ich so der erste
Big Point, da ist halt Zeitdruck, wie siehst denn du
das? Ja, ich, ich kenne das Problem,
was du gerade ansprichst. So den den den Punkt.
Weil das ist mir auch in einem alten Projekt schon mal
begegnet, dass man. Ja, wurden halt auch bestimmte
Sachen sollten. Schnell umgesetzt werden und das
haben wir dann auch im Team gemacht.
Das hat dann auch soweit alles funktioniert und irgendwann
bisschen später n bisschen Zeit es quasi ins Tal geflossen, sagt
man glaub ich so ne. Die ja genau jeder.
Kennt den das Sprichwort? Und dann ging es irgendwann
wirklich mal wieder an ne weil. Man hat es halt manchmal.
Man kommt nicht drum herum, das ist ja genau das, worüber es
hier gerade geht. Einfach mal wieder was zu refact
dann und haben dann einfach genau aus diesem Grund gemerkt,
OK, weil wir haben uns wieder bestimmte Files, bestimmte
Klassen angeguckt mit bestimmten Funktionsnamen, was auch immer
und haben uns mal überlegt okay. Was?
Passiert da eigentlich. Also es hat zwar funktioniert,
es war auch abgetestet, aber es war halt wirklich schwer
durchzusteigen durch den Code was da genau und wieso warum
überhaupt das passiert. Also du hast ja vielleicht in
deinem Code hast du ja bestimmte.
Wie sagt man Fachlichkeiten, die abgebildet werden?
Und wenn du diese Fachlichkeiten eigentlich überhaupt nicht
greifen kannst in deinem Code mehr, also zum Beispiel
irgendeine Funktionalität im groben und Ganzen, was dieser,
was deine Anwendung zum Beispiel machen soll.
Also ich sage jetzt mal, wenn du irgendwo, wenn sich irgendwo in
deiner Anwendung sozusagen den Login widerspiegelt, du aber
überhaupt nicht verstehst im Code, was da eigentlich
passiert, obwohl es ja eigentlich sowas sein müsste,
wie, ah ja, hier ist der Login, dann wird es halt wirklich
schwierig. Das ist natürlich jetzt n
einfaches Beispiel was ich genannt hab, aber in dem Fall
war es komplexer, aber es war auf jeden Fall diesem Zeitdruck
schon irgendwo geschuldet. Dass eben sowas aufgetreten ist,
dass wir uns irgendwann, auf dass wir irgendwann auf diesen
Code gestoßen sind und gesagt haben, boah, ich weiß gar nicht
mehr, was da los ist, was genau passiert da eigentlich?
Ne, das, das war schwierig. Aber aber ist das dann entstand
dadurch, dass sie wirklich schnell das machen musstet, oder
ist das so Iterativ gewachsen? Und dann habt ihr euch
irgendwann gefragt, sag mal, was machen wir hier eigentlich oder
gab es denn so zum Beispiel von außen Druck sowas wie, ja das
muss echt morgen fertig sein, weil.
Unser Kunde XY das jetzt braucht zum Beispiel nur mal so als
Beispiel, also kam da wirklich so Druck, also Pressure von
außen sage ich mal oder? Na ja, es ist so n bisschen
beides gewesen. Also es war jetzt nicht wirklich
so eine Art Deadline, aber man hat natürlich schon irgendwie,
sage ich jetzt mal. Einen gewissen Anspruch, wann
etwas oder wie wie schnell sozusagen Software wachsen
sollte, sag ich jetzt mal. Kam halt schon ne Menge rein und
es musste irgendwie auch umgesetzt werden und manchmal
hast du ja auch Momente wo du sagst, OK wir würden das gerne
anders machen, vielleicht aber zu dem Zeitpunkt existiert
vielleicht noch nicht die konkrete Idee, wie man es besser
macht. Beziehungsweise hat man halt
eben. Nicht die Zeit, weil das ganze
Team irgendwie an bestimmten Baustellen sitzt und daran
arbeitet. Es war aber noch glaube ich auch
noch n anderer Punkt, was sozusagen dazu geführt hat und
ich finde, dass es auch n sehr essentieller Punkt, wenn es
darum geht. Zu sagen, OK, du hast die
Theorie, wie du es sozusagen gut machst, aber die Praxis grätscht
manchmal ein bisschen dazwischen.
Und das war zum Beispiel, das waren sich sich verändernde
Anforderungen. Ne also.
Du hast zum Beispiel eine ne Anwendung und möchtest quasi
irgendwie es soll n bestimmtes Feature in diese Anwendung
reingebracht werden und jemand sagt dir dann OK, mach das
Feature so und so und dann baust du es sozusagen genauso ein wie
die Anforderung ist und dann auf einmal ändert sich die
Anforderung vielleicht nicht um 180 Grad, aber vielleicht sag
ich jetzt mal um 90 Grad, also schon, dass sich quasi
grundlegend was ändert und dann musst du halt da drin irgendwie
was verändern und das ist teilweise auch wirklich
schwierig finde ich, weil. Wie möchtest du Sachen
verändern? Damit es sozusagen erstmal
funktioniert, weil manchmal ist es ja dann auch so.
Ja komm, können wir das nicht mal eben so und so machen und
dann steht man finde ich auch so, da sitzt man zwischen 2
Stühlen, weil man sich dann sagt, Na ja gut okay, du willst
es zwar schnell haben, aber deine Änderung klingt vielleicht
trivial in diesem Moment. Code technisch ist da aber
einiges zu ändern, weil quasi die Ursprungsanforderungen.
An diese Software, die du schreiben solltest, ne ganz ganz
andere war und manchmal manchmal klingen Sachen relativ einfach
von außen so, ja dann. Weiß ich nicht.
Füg doch vielleicht noch n Attribut hinzu, ne und dann hast
du aber vielleicht das Problem, dass dieses Attribut vielleicht
oder oder pack das Attribut von Objekt A zu Objekt b.
Aber wenn deine Datenbankstruktur und deine
Relation sozusagen in dieser Datenbank ist, jetzt n bisschen
weit ausgeheult, aber wenn die jetzt zum Beispiel dann sich
komplett verändern, weil irgendwelche Constraints darauf
liegen, dann wird es irgendwann schwierig.
Also diese Anforderungen, die vorher da waren.
Falls. Du verstehst, was ich meine.
Da jeder Mitkauft das ist. Natürlich sehr bedient du und
ich auch noch dabei sind bei fabis Erklärungen, aber ich
denke schon. Ja, ich finde, das ist ein ganz
cooler Punkt mit diesen ändernden oder geänderten
Anforderungen, weil man ja oft dazu neigt.
Diese neue Änderung oder diese Abänderung der Anforderungen
dann noch quasi on top mit rein zu coden, dass man sagt okay,
ich hab jetzt ein Feature entwickelt, das hat sich jetzt
geändert, also passe ich das an, aber man geht meistens nicht
zurück und da spielt ja wieder dieser Zeitdruck oft rein das
man so weit zurückgeht noch mal zu hinterfragen ob dieser
gesamte Grundansatz den man gewählt hat sage ich mal
überhaupt jetzt noch intakt ist. Also ist das jetzt wirklich noch
die beste Lösung, das zu implementieren, oder ist das
Feature vielleicht jetzt doch so abgewandelt, dass man es hätte
ganz anders angehen müssen und dann geht man oft halt nicht den
Schritt zu sagen. Alles weg, mal radikal gesagt
und wir machen das jetzt neu, weil es ist n echt n anderes
Feature geworden und wir können das anders implementieren,
sondern neigt dazu zu sagen, OK wir nehmen das was wir haben und
ändern das ab und das ist oftmals nicht die optimale
Lösung dann am Ende. Ja, aber ich find wie gesagt, da
sind halt 22 Sachen die halt. Die ja auch gegeneinander
spielen. Ne, weil auf der einen Seite
hast du diesen zeitlichen Aspekt, weil auf der einen Seite
ne, man kann ja verstehen, dass man zum Beispiel sagt so.
Wir würden das gerne so und so umbauen.
Ne kommt die Anforderungen und dann sagst du ja klar können wir
gerne machen, aber das dauert dann vielleicht 3 Monate.
Ich übertreib jetzt n bisschen ne und dann heißt es na ja 3
Monate nee können wir gar nicht machen so und dann kommt ja
vielleicht auch noch sowas wie ja warum dauert das denn so
lange? Naja weil die Anforderungen sich
derart geändert haben ja gut, aber dann habt ihr aber eure
Software nicht so designt, dass sie wirklich gut maintenable ist
oder so. Und das ist dann auch wieder
fies. Weil also das ist, das ist halt
eine sehr, sehr schwierige Angelegenheit, weil klar auf der
einen Seite möchtest du deine Software natürlich so designen,
dass sie möglichst gut wartbar, erweiterbar ist und vielleicht
auch veränderbar, was auch immer, dass man halt quasi
schnell auf Änderungen reagieren kann.
Aber das funktioniert ja nicht immer.
Also anhand dieser Anforderungen.
Wenn jetzt wirklich die sich die Anforderungen so komplett
ändern, dann wird es halt unter Umständen wirklich schwierig.
Aber das ist ja die Front, kenne ich ja es.
Wird halt nicht immer. Es wird halt nicht immer so
gesehen, dann von außen ne, weil man hat natürlich auch wenn man
jetzt zum Beispiel nicht im Entwicklerteam drin steckt, dann
ist es natürlich teilweise schwierig das dann vielleicht
nachzuvollziehen auf der technischen Ebene, aber sowas
kommt natürlich hinzu. Ja klar, also Änderungen, die
oftmals trivial klingen, können halt einen großen Impact haben
auf die Gesamtsoftware und wenn du dann halt wirklich nach
Cleancode entwickeln willst, bist du eigentlich gezwungen,
denn halt auch dementsprechend das komplett durch zu refectern
und den Code anzupassen und das ist dann halt von außen oftmals
nicht gerne gesehen oder nicht verständlich, gerade weil das
deswegen auch meine Frage vorhin kam.
Dieser Zeitdruck von außen, weil oftmals hast du ja einen
Stakeholder der sagt so okay ich hätte gerne das und das bis da
und da so Deadlines typisch. Und wenn jetzt von da auch
dieser Änderungswunsch kommt und gleichzeitig diese Deadline
irgendwie eingehalten werden muss oder gesetzt wird, dann
wirst du natürlich auch auf wenigen Verständnis treffen.
Wenn du sagst, kann ich machen, das klingt jetzt trivial, die
Änderung. Deutet aber n paar Wochen
Entwicklungszeit. Ja.
Dann wird das halt nicht nicht sehr positiv aufgenommen, denk
ich mal. Pass auf, mir fällt, mir fällt
Grad n Beispiel ein um um das irgendwie mal n bisschen
greifbar zu machen, weil ich dachte mir so alles was man so
erklärt ist irgendwie so sehr sehr auf einer Metaebene
irgendwie bisher. Aber stell dir mal vor, jemand
sagt okay wir haben wir haben ne Software und es gibt zum
Beispiel bestimmte. Entitäten sage ich jetzt mal,
oder bestimmte Objekte oder was auch immer, wo man sagt Okay
diese Entitäten sind. Wirklich unique, also die kann
es nur einmal geben, das ist unsere Anforderung.
Und jetzt kommt zum Beispiel irgendwie eine neue Anforderung
rein und dann heißt es, wie wäre es, wenn wir auch Entitäten
kopieren können, so, und dann stehst du halt auf einmal in
einem irgendwo in einem so einem State, wo du dir denkst, also
erst hieß es, das soll Einheit, also wirklich Unix sein, also
wirklich einzigartig, so eine Entität sage ich jetzt mal.
Ne, zum Beispiel ein Username oder was auch immer, der darf
nur einmal vorkommen und dann kommt zum Beispiel jemand und
sagt ja gut, aber es wäre doch eigentlich auch okay, wenn man
irgendwie dann sozusagen user kopieren könnte, dann wäre es
halt einfacher die neu anzulegen oder was auch immer, weißt du
sowas? Und dann dann.
Dann ist es am Ende nicht nur ne copy Funktion zu implementieren,
sondern du musst halt durch deine gesamte Software gehen und
überhaupt diese ganze sag mal diese Prämisse verändern da drin
ne, weil dein ganzer Code basiert ja darauf, dass Sachen
nur einmal existieren können. Genau, aber die aber die Idee
also wie du es aussprichst ist halt super easy, dass du einfach
sagst, wie wäre es denn, wenn wir einfach auch jetzt user
kopieren können oder oder diese Entitäten, was auch immer man
dahinter hat, aber das klingt halt super trivial.
Aber unter Umständen ist es das eben nicht.
Und das ist halt manchmal so ein bisschen, finde ich die
Schwierigkeit, wo man dann zum Beispiel vielleicht sagt, Ey,
wir arbeiten nach Best Practice und versuchen alles, und dann
verändert sich auf einmal irgendetwas und dann kannst du
das Ganze nicht. Also dann kannst du es nicht
quasi nachhaltig so aufbauen, dass irgendwie alle Best
Practices cleancode auch mit Reinspielen und du musst es halt
auch Refect am Ende. Also genau, du kannst nicht
sagen wir mal nicht so schnell und das ist dann halt auch
oftmals wieder das Problem. Also es ist halt n enormer
Aufwand, denn wieder so n clean Zustand.
Mit dieser neuen Anforderung zu erreichen.
Indem man aber auch gehen sollte.
Ja. Nach Lehrbuch wirst wie gesagt
in der Praxis ist halt immer die Frage, darfst du diesen Weg zum
Beispiel gehen oder hast du die Zeit diesen Weg zu gehen.
Das ist halt wirklich, also oftmals kommt es ja immer wieder
darauf zurück, dass man vielleicht nicht diese Zeit hat,
oder? Es ja also, dass sie, sag ich
mal, diese Anforderungsänderung auch regelmäßig kommen.
Das klingt jetzt vielleicht auch ein bisschen komisch, dass man
sagt, ja, wieso, du hast doch, du weißt doch, wie die Software
sein soll, aber in der Realität ändern sich so eine Anforderung
ja auch öfter, das heißt, im Worst Case hast du es
implementiert, ein Feature, dann ändern sich die Anforderungen,
wie zum Beispiel lass doch mal diese Entitäten kopieren können,
es gibt die nicht nur einmal, wir können sie kopieren, dann
denkst du dir, Oh Mann ey, jetzt ja okay mache ich bau.
Alles um und worst case. Wie heißt das 4 Wochen später?
Ja nee war Quatsch, nee nee, das war Quatsch, ich mein dann hast
du vielleicht noch das Glück, weil wir ja auch schon so über
Versionierung gesprochen haben, dass du es vielleicht
zurücksetzen kannst, aber es vielleicht ist es ja auch nicht
war Quatsch, setzt zurück sondern war Quatsch, man kann
nur gewisse kopiert oder irgendwas weißte und dann bist
du ja in so einem Hamsterrad und jagst eigentlich immer diesem
clean Zustand hinterher und das ist halt echt schwierig manchmal
ja richtig aber. Da kommt ja zum Beispiel.
Jetzt gerade dabei sind und sagen, OK, es gibt jetzt zum
Beispiel vielleicht irgendwelche Änderungen und jetzt kommt neuer
Entwickler oder ne neue Entwicklerin in diesen in in
dieses Team rein und du hast gerade quasi so ne Änderung
eingebaut, die komplett gegen andere Anforderungen sozusagen
entgegenarbeiten und der neue Entwickler oder ne Entwicklerin
denkt sich was ist was ist das denn hier also kommt in quasi in
irgendeinem Bereich, also irgendwo rein, vielleicht auch
an der Ecke wo der Code schon ein bisschen älter ist, also
sozusagen eine gewisse Art von Legacy Code.
Die aus der Vergangenheit irgendwie existiert.
Vielleicht genau aus solchen Änderungen.
Und dann heißt es vielleicht sowas wie Leute, was habt ihr
denn hier gemacht? Ne, also das ist ja, das ist ja
Kraut und Rüben und dann denkt man sich zum Beispiel vielleicht
keine Ahnung, irgendwer. Anders zum Beispiel N
Projektmanager Heavy warte mal, ich hab gerade gehört, dass
Kraut und Rüben. Was habt ihr denn da gemacht?
Erkennt ihr, seid ihr keine guten Entwickler oder
Entwicklerinnen, dass dass sowas da rumliegt weißt du sowas kann
ja auch zum Beispiel auftreten. Ne, also dass solche.
Situationen auf einmal da sind und man dann vielleicht
irgendwie denkt, so warte mal was, dann hast du vielleicht
irgendwie Anschuldigungen, die irgendwie in der Luft stehen
oder was auch immer. Ja, weißt du was ich meine?
Ja, ja, ja, was heißt Anschuldungen?
Manchmal kommt man ja auch so stellt man sich ja, so sage ich
mal selbst vor das Gericht, ich kann das halt auch ganz gut,
dass du durch den Code schaust und immer wieder so einen Code
Passagen vorbei kommst, du dir denkst.
Das muss ich noch machen. Du, du siehst es ja selbst so,
der hat das nicht schön, das nicht cool, das muss man, ich
mein, das kennen wir ja auch aus unserem Projekt, dass wir so n
bisschen durch n Code gucken und oftmals so stellen finden, dass
es fast auch immer die gleiche denn.
So ja übrigens hier ne. Ja ja müssen wir noch machen.
Ja Scheiße schaffen wir jetzt nicht, ah müssen wir aber noch
machen, dann ist wieder dieses Later Equix Never Prinzip und
ich hoffe, dass es nicht greift, da dass wir es noch machen.
Aber das ist halt genau dieser Klassiker, dass man ja auch
selbst genervt ist davon. Ne, man will ja selbst auch
wirklich sauber coden und ne geile Software schreiben und es
passiert trotzdem und ich davon muss man mich erstmal
überzeugen, dass das niemals bei anderen passiert, das glaube ich
nicht, ehrlich gesagt, aber es kommt nämlich immer wieder zu
diesem Punkt, dass man echt mal wirklich unsauber arbeitet, weil
halt irgendwelche Randbedingungen denn so
reinkicken, dass man sagt ich kann's, ich schaff's jetzt nicht
das zu machen, oder? So einen anderen Punkt, den wir
jetzt noch nicht so so ausführlich besprochen haben,
die würde ich jetzt auch noch mal in den Ring werfen, ist
nicht nur Zeitdruck oder ändernde Anforderung, sondern
auch das Problem ja auch in eine enorme Komplexität haben können,
dass man einfaches in dem Moment gar nicht schafft, ist so simpel
und clean runter zu brechen, dass da richtig geiler Code
rauskommt, sondern man vielleicht gerade nur auf eine
Lösung kommt, wo man schon weiß, das schmeckt mir eigentlich
nicht so richtig, es ist nur okay, es funktioniert.
Man kann es auch abtesten, aber irgendwie ist es noch nicht
geil. Diesen Punkt kenn ich auch, ich
weiß nicht wie es bei dir ist, aber das sind halt so Momente,
damit lebt man dann erstmal. Aber eigentlich nervt es auch.
Aber ich find, da kommt auch tatsächlich.
Also ich finde es greifen halt also dieses Problem was wir hier
in dieser Folge besprechen finde ich ist ein sehr sehr
übergreifendes Problem aus vielen Punkten bei Angelegen.
Du hast angenommen du hast ein komplexes Projekt angenommen, du
musst dafür vielleicht auch mal eine neue Technologie verwenden.
Und du kommst irgendwann vielleicht an den Punkt.
In der Entwicklung dieser Software oder dieser Anwendung,
dass du dir denkst, wie du gerade meintest, was haben wir
denn da gemacht oder was habe ich da gemacht, vielleicht sogar
oder was hat keine Ahnung, Teamkollege und Teamkollegin da
gemacht, ist ja auch immer die Frage.
Erfahren ist man zum Beispiel. In dem Bereich also wenn du
sagst es ist n komplexes komplexes Projekt, was ja
vielleicht auch ne bestimmte. Ne bestimmte Domain mitbringt,
wo man vielleicht noch gar nicht so erfahren ist.
Vielleicht bietet das neue Framework, was man verwendet,
vielleicht ist man selber oder andere Teamkollegen Kolleginnen
doch gar nicht so erfahren da drin ne, dass man sozusagen
anhand von mangelndem Wissen gar nicht in der Lage ist eine Best
Practice zu zu erzeugen oder zu kreieren und dann hinterher
guckst du wieder drauf und denkst dir so vielleicht über
den eigenen Code was. Denn da gemacht ne, aber es kann
halt durchaus sein, dass man vielleicht auch einfach
logischerweise sich in bestimmten Punkten auch einfach
weiterentwickelt. Genauso wie man zum Beispiel
vielleicht anfängt zu programmieren, ne sagen wir mal
du bist NN Anfänger und fängst an Software zu programmieren und
kennst vielleicht bestimmte Theorien wie irgendwas
funktionieren könnte. Und versuchst es umzusetzen.
Aber kriegst es vielleicht noch nicht perfekt hin.
Also ich meine du kannst es dir auch so vorstellen, ne wenn du
jetzt keine Ahnung zum Beispiel Tennis spielst und jemand sagt
ja guck mal so funktioniert eine absolut perfekte Vorhand, das
ist die Technik, die Theorie dahinter genau so.
Legst du eine perfekte Vorhand und du gehst hin, dann wirst du
ja nicht dich auf den Platz stellen.
Sagen ja, ja, ich weiß ja, wie es geht, zack und ne perfekte
Voranschlagen so also du musst ja.
Klar, das Beispiel hast du schon mal irgendwann gebracht, oder?
Das kommt mir sehr bekannt vor mit einer perfekten Vorhand, ich
wag. Ich wag das Beispiel einfach.
Ne Zeit lang Tennis gespielt, aber.
Ah, jetzt kommt es raus. Jetzt kommt es raus, nein, aber
ich find ich find das ist immer n gutes Beispiel, das kannst du
ja theoretisch auf jede Sportart oder auf irgendwas was du lernst
kannst du es anwenden weil du hast ja ne gewisse Theorie und
du weißt vielleicht ja klar so funktioniert das auf jeden Fall,
ist ja gar kein Problem. Aber das heißt ja noch lange
nicht, dass man es hinkriegt, also zum Beispiel keine Ahnung,
wir können ja auch mal aus dem Nähkästchen plaudern, du hast
jetzt beim Snowboarden ein bisschen versucht, Switch zu
fahren, so, und das ist natürlich, du weißt okay, ich
kann die normale, quasi deine normale Frage.
Jetzt hier nicht bloßstellen. Okay.
Nein, aber deine normale Fahrtrichtung, das kennt ja
jeder. Die normale Fahrtrichtung ist
ganz easy, aber die andere Fahrtrichtung ist erst mal am
Anfang ein bisschen schwieriger, weil man sich denkt, okay, ich
weiß doch, wie es funktioniert, aber das heißt ja noch lange
nicht, dass ich es auf Anhieb First try umsetzen kann.
Ja, das stimmt absolut klar. Also du kannst es sogar quasi
auf Variante a kannst du es, du kennst auch die Theorie und
trotzdem wenn du was änderst, dann ist es auf einmal wieder
komplett ungewohnt oder geht nicht am Anfang.
Ja, weißt du, hast du recht? Auf jeden Fall.
Ich weiß jetzt nicht, ob jeder sich jetzt was mit Switchfahren
vorstellen kann, aber. An die Snowboarderin und
Snowboarder da draußen, die Wissen denke ich mal genau, was
wir meinen. Ja, absolut.
Also ich weiß genau, was du meinst.
Das ist halt, es ist auch ne Übungssache einfach um das mal
so n Überpunkt zu geben. Also man kann jetzt sich zum
Beispiel unsere Podcast folgen zum Cleancode anhören.
Das auch verstehen und es ist greifbar.
Das hoff ich zumindestens, dass es greifbar ist, was wir hier
jetzt definitiv gibt uns Feedback ansonsten in beide
Richtungen sowohl positiv als auch kritisch.
Aber es ist trotzdem ne übungssache, weil wie gesagt
jeder Code ist anders und dann ist die Komplexität
unterschiedlich. Hoch.
Und am Ende ist es dann die Übung, die dabei hilft, diese
Probleme zum Beispiel runter zu brechen und dann wirklich nen
Clean Code zu schreiben. Das kommt auch nicht von heute
auf morgen, das kommt nicht dadurch, dass man ein Buch
liest, zum Beispiel über Cleancode, falls ihr da gerne
Empfehlungen haben wollt, können wir das auch gerne mal in die
Show Notes packen. Oder halt diesen Podcast hört
oder mit anderen drüber redet. Also es ist am Ende halt
wirklich practice und deswegen ja auch diese Folge, dass man,
dass wir jetzt halt wirklich mal aufzeigen und sagen okay, es ist
halt Theorie und Praxis und in der Praxis kann man nicht immer
perfekt diese Theorie umsetzen. Richtig.
Und deswegen war uns das ja auch wichtig, jetzt diese Folge mal
aufzunehmen zu dem Thema und ich finde, das ist halt auch
wirklich wichtig, dass man da keine falsche Vorstellung von
kriegt so. Ja, ich weiß doch, wie Cleancode
funktioniert. Und trotzdem ist das hier
irgendwie Käse was ich mache. Ja dann fehlt da vielleicht
einfach noch n bisschen Übung oder es sind halt wirklich jetzt
gerade so diese Randbedingungen, die wir besprechen, die dann
halt dazu führen, dass es erstmal und wohlgemerkt erstmal
Käse ist, weil du musst dir dann halt auch die Zeit nehmen und da
sind wir wieder bei refactern dir zu sagen, mir gefällt das so
nicht, ich weiß, das geht noch besser, ich investiere jetzt
nochmal Zeit da rein. Richtig, also, es ist ja zum
Beispiel auch tatsächlich nicht nur, wenn man jetzt mal ganz
kurz noch mal ein bisschen die Codebene verlassen möchte.
Um das Ganze noch mal ein bisschen auszuweiten, weil das
finde ich auch sehr interessant. Das sind Sachen, die ich auch
schon oft im Gespräch gehört habe mit anderen, dass es zum
Beispiel um sowas geht wie also man weiß ja zum Beispiel, dass
eine Best Practice ist, dass man zum Beispiel Tests automatisiert
durchlaufen lässt, dass man das ICD Pipeline hat, dass man zum
Beispiel eine gewisse Release oder die Pleuelstrategie hat,
und trotzdem kommt es immer wieder mal vor, dass auch
durchaus man sozusagen auf Leute trifft, die sagen, ja, klar, ich
weiß, dass das so wichtig ist und dass das ne gute Praxis ist,
aber bei uns im Projekt zum Beispiel funktioniert es so
nicht so ne. Und dann ist es halt auch
manchmal so klar, es kann auf der einen Seite sein, dass es
dann eher vielleicht ne Ausrede ist, auf der anderen Seite kann
es sein, dass mangelndes Wissen an der Stelle da ist im Sinne
von wie setze ich das konkret bei meinem Projekt um.
Aber vielleicht funktioniert es tatsächlich auch einfach so
nicht, ne wie bestimmte Sachen eigentlich optimal sein sollen.
Und das ist halt find ich immer super, super interessant, aber
trotzdem find ich kann man immer gibt es find ich immer so diesen
diesen Gewissen so n gewissen Leitspruch den man sich
irgendwie selber immer mal so als Mantra sagen kann, wenn man
zum Beispiel irgendwie an den Punkt kommt wo man sagt das geht
so nicht und es ist halt besser zu sagen okay aber wie könnte
ich denn mein Wunschzustand herstellen?
Also wirklich mal mit dem mit dem Wörtchen wie darüber
nachdenken was eigentlich? Wichtig wäre, wo will ich hin
und wie kann ich das umsetzen und nicht das geht halt nicht.
Das ist ein wirklich guter Punkt, den du da ansprichst,
weil dieser Satz ist mir halt auch sehr oft schon begegnet,
wenn es so um. So genau um solche Themen wie
Cicd Testing geht so ja, wir verstehen.
Dass zum Beispiel auch Test Driven arbeiten ne coole Sache
ist. Aber und dann kommt immer dieses
berühmte aber. Ja, das ist wichtig.
Aber bei uns geht das nicht. Weil unser Problem oder unser
Projekt ist so unglaublich komplex und anders als alle
anderen, dass es am Ende nicht funktioniert.
Wir können das nicht umsetzen, wir können keiner automatisierte
Integration und die Ploimentstrategie.
Gefahren wir können nicht testen.
Also weißt du, und da denk ich mir halt immer so OK ich, ich
kann mich da super hineinversetzen, weil zum
Beispiel unser Projekt Fabi ist ja auch.
Nicht gerade so simpel gestrickt, dass man alles
perfekt umsetzen kann, wie es das Lehrbuch will.
Aber und jetzt n Positives aber. Wir haben so vieles geht um was
wirklich geht, Wege gefunden, es umzusetzen, um einfach auch
beispielsweise automatisiert testen zu können, automatisiert
deployen zu können. Ich verstehe absolut, dass jedes
Projekt seine eigene Anforderung hat und thematisch gesehen auch
in einem eigenen, in der eigenen Landschaft unterwegs ist.
Was man nicht vergleichen kann, nehmen wir beispielsweise.
Embedded projects irgendwas Hardware, Hardware getriebenes
und Web Applikationen. Natürlich ist das leichter.
Im Bereich Web Applikation umzusetzen, ohne jetzt hier
irgendwie no Front, aber es ist natürlich auch eine gewisse
Zusatzkomplexität wenn du sagst, ja, aber meine Software läuft
auf irgendeinem Steuergerät beispielsweise oder auf
irgendeinem Mikrocontroller allgemein gesagt ich.
Darauf testen ist ja was anderes als wenn ich unit Test in meiner
IDE laufen lasse. Mal als Beispiel, nur definitiv
alleine. Aber nicht heißt, dass das eine,
da geht es um, bei dem anderen geht es auf keinen Fall.
So wie geht es ja genau, sondern wie mache ich es möglich und es
gibt auch für alles Lösung und auch Frameworks die angeboten
werden. Man muss dann halt nur diesen
Aufwand betreiben, das umsetzen zu wollen.
Ich glaube, das schwierige oder was zum Beispiel auch manchmal
nicht unbedingt einfach greifbar ist, ist der Punkt, dass man man
versucht, also wie wie wir zum Beispiel auch wir, wie du schon
gesagt hast, ne, das sind Sachen dabei, die sind vielleicht nicht
immer trivial und wir versuchen ja auch immer möglichst nach
Best practice irgendwas umzusetzen, was auch manchmal
ein bisschen mehr Zeit in Anspruch nimmt.
Nur wichtig ist, glaube ich, dass man vielleicht doch nicht
damit rechnen sollte, dass die Reise dann irgendwann vorbei
ist, sondern das ist halt ein fortwährender Prozess.
Also Best Practices verändern sich ja auch und wichtig ist,
dass man dann zum Beispiel auch, würde ich sagen, zum Beispiel
auch mit der Zeit geht und sagt Okay welche Best Practice haben
wir jetzt, also, wo sind wir gerade, in welche Richtung
Steuern wir, was müssen wir umbauen, an welchem Nerv der
Zeit müssen wir gerade arbeiten, und das ist halt wichtig, weil
ich habe letztens auch zum Beispiel mitgekriegt.
Zum Beispiel? Keine Ahnung, es gibt ja auch
gerne diese, diesen dieses Mindset, so okay.
Wo kann ich zum Beispiel weiß ich nicht wissen ergattern, sage
ich jetzt mal, was auf jeden Fall sage ich jetzt mal best
practice, zeitlos ist ne, das ist schwierig, gerade in der
Softwareentwicklung, weil es gibt quasi eigentlich
fortwährend Weiterentwicklungen, genauso über Best Practices.
Genauso ist zum Beispiel Cleancode vielleicht also dieses
cleancode Buch beispielsweise ist sicherlich ein guter Ansatz,
eine gute, gutes Wissen, auf dem man aufbauen kann, aber das
bedeutet noch lange nicht, dass das jetzt das Ende.
Eines guten Codes ist also, wer weiß denn was in 5 in 10 in 20
Jahren für Code. Quasi existieren.
Das ist wichtig. Ja.
Weil also gerade das Thema Cleancode sind ja auch Ansätze,
die man verfolgen kann, und jeder muss ja sich für sich
selbst entscheiden, welche Ansätze er davon gut findet und
umsetzen möchte. Also alles, was wir hier so
besprechen in dieser Podcast Folgenreihe Cleancode sind ja
auch, sage ich mal, Ansätze, die wir gut finden, also das hat ja
alles eine Diskussionsgrundlage, es gibt auch Leute, wir hatten
ja auch den Kommentar. Jetzt an der Cleancode
Kommentarfolge. Dass ein Entwickler sehr gerne
Kommentare anschreibt an Code Blöcken, um zu beschreiben, was
da passiert. Und es ist ja auch absolut
legitim, wir haben ja quasi unsere Meinung dazu gesagt,
haben gesagt okay, wir finden es halt besser, wenn der Code sich
selbst beschreibt, was er aber nicht heißt, dass wenn jetzt ein
Entwickler. Oder in einem Entwicklerteam.
Das ist ja auch immer so ne Teamüber, also ne
teamgeschichte. Man muss sich im Team dadrauf
einigen wie man entwickeln möchte, weil wenn jeder einer
Machtkommentar ran, der andere nicht und der dritte macht n
beiden Mix aus beidem und keine Ahnung, dann hast du ja wieder
Chaos, das ist ja so ne so n Commitment im Team.
Wie möchte man das machen und wenn die Person zum Beispiel
sagt, ja wir im Team schreiben aber Kommentare daran um zu
erklären was die Funktion macht, dann ist es ja auch wieder in
Ordnung, wenn wenn das halt wirklich im gesamten Projekt so
ist. Ist doch cool, wenn wenn jemand
zu mir sagt, ja schön, dass du dabei bist und hier mit Codest.
Aber wir haben die Konvention, dass wir über eine Funktion
erklären, was Eingabe und Ausgabe ist.
So diese typischen doxygen Formate zum Beispiel.
Ja, da mache ich das halt. Trotzdem, aber trotzdem würde
ich zumindest im Team einmal. Challengen.
Genau dann ist halt wieder die Frage 1 gegen 20.
Nein, aber ich würde es auf jeden Fall auch challengen ja
klar, bei ist ja mein Standpunkt und den vertreten wir ja auch
hier im Podcast. Aber wie gesagt, um das noch mal
abzurunden, es sind halt Ansätze und wie du schon meintest, in 10
Jahren können die anders sein, dann sieht die Welt vielleicht
schon wieder ganz anders aus. Trotzdem würde ich zum Beispiel
sagen, dass dieses cleancode Buch.
Ja, wir sollten es auf jeden Fall verlinken, damit jeder
weiß, mit welches Buch wir reden.
Ist für mich trotzdem in gewisser Weise zeitlos, weil die
Ansätze wären, also diese Anregung, die man da drin
kriegt, finde ich sind zeitlos, sich mal darüber Gedanken zu
machen. Definitiv.
Also man muss quasi. Also ich glaube, dass es
sinnvoll ist, also dass es durchaus Literatur gibt, die auf
jeden Fall eine wichtige Grundlage für irgendwas schafft.
Die Frage ist, wenn du zum Beispiel sagst, es ist zeitlos,
klar im Sinne von würde ich auch so sehen, dass man sagt im Sinne
von. Du hast es.
Das ist sozusagen eine Grundlage, auf der man aufbauen
kann. Und dann ist nur die Frage, in
welche Richtung entwickelt sich zum Beispiel entwickeln sich zum
Beispiel neue Theorien, die aber sehr wahrscheinlich auf anderen
guten Theorien aufbauen? Aber das ist halt, es ist eine
sehr philosophische Frage am Ende aber wie gesagt, im
Endeffekt ist es ist es einfach wichtig, dass man da sein.
Seine eigene Linie findet aber natürlich trotzdem offen ist für
sage ich mal neue Ideen, weil zum Beispiel, um noch mal dein
Beispiel aufzugreifen, wenn ein Team sagt, ja, wir machen das,
aber so zum Beispiel, weil es schon immer so gemacht wurde, es
ist durchaus sehr, sehr wichtig, mit neuen Ideen auch noch mal
alte, sage ich mal, muss da auch noch mal zu challengen das ist
ein Auto. Das stimmt.
Wir sind jetzt auch ein bisschen abgedriftet und so ins
Philosophische gekommen, deswegen würde ich noch einen
letzten Punkt anbringen zu dem Thema, warum Praxis und Theorie
manchmal auseinanderdriften, bevor wir quasi die Folge dann
mal beenden, fabi. Was ich finde auch, also was ein
wichtiger Punkt ist oder ein Grund dafür, dass halt, Theorie
und Praxis manchmal auseinander laufen, ist halt dann auch das
Thema Code Reviews und Feedback. Wenn ich nämlich quasi für mich
allein entwickelt und es gibt keine.
Code Reviews oder ich kriege kein Feedback zu meinem Code,
dann wird es halt genauso schwer wieder in diese Best Practice
Richtung zu kommen, gerade als vielleicht noch nicht so
erfahrener Entwickler, weil ich ja nie darauf hingewiesen werde.
Pass auf das was du da gecoded hast funktioniert.
Das ist auch cool, aber man könnte es an der und der Stelle
vielleicht noch vereinfachen. Ja oder oder oder allein schon
Feedback so zu bekommen. Ja sag mal an der Stelle, das
verstehe ich nicht so ganz was du machst.
Ich sehe an den Tests es funktioniert, aber ich verstehe
den Code nicht, ist ja auch schon eine Anzeichen dafür, dass
es vielleicht einfach noch zu komplex ist.
Und ich sage ich mal so einfach Runtergebrochen wurde der Code,
dass andere Entwickler es sofort verstehen.
Und deswegen finde ich, ist das halt noch ein wichtiger Punkt,
wenn man den gut lebt. Reviews, Feedback, Kultur, dass
man so die Praxis und Theorie auch wieder mehr ein aneinander
bekommt. Ich hoffe du weißt wie ich das
meine, ich weiß was. Du meinst, der Austausch darf
nicht fehlen an der Stelle? Genau, und das ist halt für mich
auch so ein super wichtiger Punkt.
Und da wir ja im Pair Programming Modell arbeiten und
dadurch quasi eh zusammen coden und am Ende bevor wir
Änderungen. Einpflegen ja auch immer noch
mal n Review zusammen machen. Gut, jetzt kann man sagen OK es
gibt keine unabhängige Person die das Review ja OK das Fass
machen wir jetzt nicht auf, aber wir gucken es uns immer noch mal
wirklich noch mal Review technisch zusammen an und merken
ja da auch noch mal Punkte. Sowas wie hier meinst du nicht,
dass man das vielleicht noch ändern kann, oder?
Quasi angenommen, du hast entwickelt und ich hab mit drauf
geguckt. Merke dann so, na ja, Pass auf,
Pass auf, dass das das geht noch anders.
Mir ist gerade eingefallen, wir könnten das so und so machen.
Und dadurch steigerst du ja auch wieder die Codequalität und
kommst halt noch mehr in diese cleancode Richtung.
Ist jedenfalls meine Erfahrung dabei.
Ich hoffe deine auch wenn es umgedreht ist.
Aber das. Wald ist n sehr sehr wichtiger
Punkt dabei. Ja, geh ich mit.
Ja, ansonsten hast du noch einen.
Also das wären jetzt ich kann es nochmal zusammenfassen, wenn du
möchtest. Was waren denn so Punkte, die
jetzt die Praxis von der Theorie trennen?
Also als allerersten Punkt hatten wir auf jeden Fall.
Zeitdruck und ich finde, das ist auch eigentlich meistens der
Grund, der zumindestens immer mit rein spielt.
In Kombination mit den anderen Punkten, die wir genannt haben,
weil sobald Druck aufkommt. Wird man unsauber oder ist
oftmals gezwungen, unsauber zu arbeiten?
Man will das nicht wahrhaben und ja, man ist irgendwie der Owner
des Codes und verantwortlich dafür, das Leben wir auch und
versuchen das ja auch so gut wie möglich umzusetzen, aber es
kommt immer mal der Punkt, kannst du mal bitte schnell hier
die und die Änderungen einbauen und wenn schon in dieser in
diesem Wunsch kannst du mal schnell drin steckt, da müssten
schon die Alarmglocken angehen, dass man dann halt auch dazu
geneigt ist wirklich schnell irgendwie, wir passen das an
okay jetzt haben wir 5 rote Tests, die machen wir noch
schnell grün und dann rein damit, so weißt du.
Da muss man auf jeden Fall auf die Verantwortung bauen, die man
eben hat, wenn man. Und das ist halt, das ist halt
genauso das Problem. Genau dann hatten wir was,
hatten wir noch gesagt, Ach so, ändern der Anforderungen war der
zweite Punkt von dir, den fand ich auch richtig richtig gut,
weil das ist ja genau das. Kannst du mal bitte schnell, das
war irgendwie nicht richtig von mir was ich dir letzte Woche da
als Feature Wunsch genannt habe, das muss jetzt anders sein und
du denkst dir ja gut ich wollte gerade das abschließen jetzt
muss ich noch mal umbauen so und dann hast du genau das Thema,
dass du dann anfängst das nicht von vorne aufzuräumen zu sagen
okay ich habe ein neues Feature wie muss ich das umsetzen,
sondern ich habe ein geändertes Feature und ich versuche jetzt
meine Implizierung anzupassen, die denn oftmals nicht optimal
Ist manchmal also. Es ist ja auch nicht immer ein
mach mal eben schnell sozusagen diese.
Ändern Anforderungen es kann auch eine einfach nur ändern.
Anforderungen sein, die sich aber sehr stark durch den Code
zieht und dann hat man natürlich durchaus eventuell wieder n
Problem, was natürlich wichtig ist.
An dieser Stelle bestimmte Anforderungen wirklich auch zu
durchdenken und wirklich auch als Entwicklerteam sag ich jetzt
mal mit. Zu besprechen und nicht einfach
nur abzunicken. Was dann auch schon der dritte
Punkt war, dass wenn die Komplexität recht groß ist, dass
es halt schwierig ist, das immer alles so runterzubrechen, dass
du halt diesen Cleancode erreichst, dass du manchmal halt
auch gar nicht in dem Moment Lösungen findest, die nach
Lehrbuch cleancode sind. Ne, das war ja noch so n Punkt
und dann fand ich den Punkt von dir noch ziemlich cool für die
Zusammenfassung jetzt noch mal die mangelnde Erfahrung von Best
Practices, genau auch sehr wichtig, weil nur weil man die
Theorie kennt, kann man nicht sofort praktisch auch super
geilen Code schreiben, es ist halt eine Übungssache und man
muss da auch fair zu sich selbst sein, wenn es halt am Anfang
noch nicht so toll ist und andere man vielleicht in das
Feedback bekommt ja hier nee das ist irgendwie nicht so geiler
Code, dann ist es oftmals halt auch eine mangelnde Übung.
Und das kommt mit der Zeit. Übung macht den Meister.
Genau, und da ist ja auch wirklich n wichtiger Punkt, den
du noch meintest am Ende. Ich glaube ich.
Ich hoffe, ich hab das jetzt nicht ganz durcheinander
geworfen. Aber der nee, das wär auch der
letzte. Hau ihn.
Raus nämlich der Punkt, dass man halt zum Beispiel auch Code
Reviews macht und sozusagen den Austausch eben hat, der einem
genau auch hilft. Natürlich logischerweise.
Ich sag mal mangelndes wissen sozusagen aufzuholen.
Ja, und von anderen Leuten zu lernen.
Genau. Das ist halt wirklich wichtig
dabei. Ja, Fabi, dann würde ich sagen,
haben wir das doch ganz cool besprochen.
Hat mir auf jeden Fall wieder mega Spaß gemacht, sowohl Punkte
zu nennen, die Theorie und Praxis auseinandertreiben, als
auch unser kurzes Off top weg. Was ja aber auch um Cleancode
ging und damit doch Teil der Folge war.
Ich. Sagen, ich beende die Folge oder
hast du noch was? Ich bin durch.
Du bist durch sowohl mental als auch mit dem Thema.
Das hast du alles rausgehauen, was dir dazu eingefallen ist.
Sehr gut, sehr gut. Na ja, dann habe ich auch nichts
mehr hinzuzufügen. Liebe zu liebe Zuhörer, ich
hoffe, dir hat die Folge gefallen.
Falls du Anmerkungen dazu hast oder vielleicht noch weitere
Punkte hast oder Erfahrung gemacht hast, wo du dir
dachtest. So OK, ja nach Lehrbuch müsste
man so entwickeln, aber in der Praxis komplettes Chaos.
Stein, was soll ich nur tun oder was habt ihr dann getan?
Wie auch immer, melde dich gerne bei uns über unsere Podcast Mail
oder über die anderen Plattformen, die links findest
du wie immer in den Shownotes für alle Zuhörerinnen und
Zuhörer, die jetzt Interesse an dem Cleancode Buch, was wir
empfohlen haben oder genannt haben, sage ich mal den Link
hauen wir euch natürlich auch noch in die Show Notes dazu sei
noch angemerkt, kurze Eigenwerbung, wir sind jetzt mit
Thalia in der Partnerschaft und ihr könnt uns da gerne
unterstützen, wenn ihr euch das Buch dann übertallia über den
genannten Link holt, würde uns sehr freuen.
Würde ich sagen, hören wir 3 uns beim nächsten Mal wieder.
Bis dahin habt noch n schönen Tag deine Coding Buddies
gemeinsam besser.