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.