Ich meine, jeder kennt dieses Gefühl.
Man sitzt da an einem Feature, die Deadline rückt näher und man
ist eigentlich schon fertig und merkt, Boah, an der Stelle
müsste ich eigentlich noch das und das machen, aber das könnte
ich auch später tun und genau das ist das Problem, denn das
nennt man technische Schuld Coding Buddies Dein Podcast rund
um Softwareentwicklung und aktueller Tech News.
Herzlich Willkommen. Halli Hallo Grüzi und herzlich
Willkommen zur neuen Folge vom Coding Buddies Podcast.
Heute mal ganz international für alle Bereiche aus Deutschland
und der Umgebung. Und deswegen begrüße ich Tino
dich hier. Ganz herzlich und dich auch,
Liebe Zurer lieber Syrer, grüßt euch.
Was geht ab? Vati Wilde Anmoderation in allen
Sprachen, die dir einfallen, scheinbar.
Ich möchte einfach mal grün. Ziehen?
Ich weiß nicht. Ob er das sagt?
Aber also auf jeden Fall haben wir es definitiv falsch
ausgesprochen, würde ich sagen. Der Slang war nicht ganz gut.
Getroffen aber. Das ist ja auch eine Kunst für
sich, ne? Verbesserung, Verbesserung,
immer gerne her damit ich ich lerne alles mögliche immer gerne
und ja nee, also ich hab mir gedacht ich probier es einfach
mal. Weißt du also just tryde wie man
so schön. Gerne Feedback dazu.
Aber Tino ganz kurz mal, mir ist so n bisschen mal aufgefallen,
dass wo das Wetter sich ja in letzter Zeit n bisschen bessert
und das ist da ist mir irgendwie die Frage jetzt mal aufgekommen,
hast du schon gegrillt dieses Jahr?
Ja, die Woche zweimal schon. Ist cool, also ich noch nicht,
also jedenfalls noch nicht jetzt so, ich weiß nicht, ob ich weißt
du, manchmal grillt man ja auch so im Winter an, so kennst du
das so nach Silvester angrillen und so ne Geschichten.
Ja nee, das mach ich nicht. Ich bin, ich bin
schönwettergriller. Ja, ich eigentlich meistens
auch, aber so. Ich hab es auch schon mal
gemacht. Weißt du so silvester 1.
Januar und dann angrillen oder so hab ich auch schon gemacht
deswegen. Also da war das meinte ich jetzt
gerade nicht, sondern einfach so.
Weißt du dieses Schönwetter angrillen ne hast du gemacht.
Ja, absolut. Es war war geil, soll ich dir
sagen, was ich gemacht hab? Bitte gerne.
Ich hab für meinen Grill so ne Art fajita Pfanne.
So ne gusspfanne, hab aber mit Kartoffeln und grünen Spargel
und so. Quasi sowas da drin gemacht und
dann brutzelt das vor sich hin. Das ist einfach nur geil.
Also ich glaube in Sachen grillen, da kann man sich bei
dir auf jeden Fall noch einiges abgucken.
Ja, also das. Kreativ bleibt immer offen.
Ja, openmined sag ich mal beim grillen, ja.
Aber ich weiß es. Also ich weiß, dass man sich bei
dir noch ne Menge abgucken kann, aber immer wenn ich mal in den
Genuss deiner Grilltastischen Grillereien gekommen.
Bin ich. Muss das sagen, war es immer
sehr sehr lecker. Dann grillen wir, wenn du das
nächste Mal wieder hier bist. Sehr gerne.
Sehr gerne also. Das.
Ist wirklich ein Ding. Aber mal abgesehen davon von
deinen absoluten Grills Skills hast du natürlich auch Skills in
der Softwareentwicklung, Informatik, wie auch immer
wissen wir und da wollen wir jetzt auch hin, ja, ich versuche
jetzt mal die Kurve da hinzukriegen, was heute unser
Thema ist. Tino und zwar sprechen wir heute
ja über das, was schon angeteasert wurde und zwar.
Über technische Schuld ja, also da kann ja ne Entwicklerin oder
n Entwickler so gut sein wie er möchte ja selbst so gut wie du
Tino und trotzdem und trotzdem kann man in diese Falle tappen,
ja und wir wollen halt heute einfach mal klären und gucken
wie man das vielleicht vermeiden kann, wie man da auch wirklich
noch mal sensibilisiert und vielleicht auch mal sagt.
Ich weiß nicht, ob man vielleicht sagen kann, ich weiß
nicht, ob es geht, da müssen wir mal hinkommen.
Ja, ob man sagen kann, technische können wir aufbauen,
ohne dass man sich Vorwürfe machen muss, weiß ich nicht.
Ja, vielleicht muss man sich auch immer diese Vorwürfe machen
oder sollte sie halt immer vermeiden.
Soweit so der erstmal der Fahrplan.
OK, ja, spannendes Thema ist halt so n Thema wo man nicht
gerne drüber redet, weil jeder weiß es ist nicht gut, jeder
weiß wie man es vermeiden kann und trotzdem passiert es einfach
jedem. Ich denke, da werden wir auch so
n paar coole Punkte finden, auch an uns selbst sag ich mal was
immer so n Grund ist sowas aufzubauen ist auf jeden Fall
mal spannend drüber zu reden. Was mir aber als allererstes
einfällt, was schon mal ne gute Maßnahme dagegen ist dagegen
ist, ist einfach auch direkt mal die eigene Podcast Schuld
abzubauen. Also liebe Zuhörerinnen und
lieber Zuhörer, falls du unserem Podcast noch nicht folgst, dann
erledige das doch ganz schnell mal Klick mal auf den Follow
Button, das würde uns super unterstützen und vielen vielen
Dank dafür und jetzt geht es dann auch schon weiter mit der
technischen Schuld. Und ich würd sagen, wir fangen
mal an und definieren mal für uns was so technische Schuld
bedeutet in unserer Welt. Ja, fand ich auf jeden Fall
sehr. Gut, wie du das Smart oder
wirklich also Liebig. Aber technische Schuld?
Ja, was ist technische Schuld? Ich würde es so n bisschen
definieren als kurzfristiger Gewinn ja Gewinn im Sinne von.
Vielleicht Schnelligkeit, aber Schnelligkeit, weil ich ja
kurzfristig meinte, es ist kein langfristige Schnelligkeit ne,
also du hast halt diesen kurzfristigen Gewinn, du kannst
schnell etwas umsetzen, mal schnell, ich nenn es jetzt extra
hinfrickeln, manchmal hilft es ja auch um schneller Feedback zu
bekommen, ne aber davon ab, es ist halt einfach etwas was
sozusagen schnell geht oder was man schnell umsetzen kann.
Was aber einen Preis hat irgendwo, und dieser Preis ist
halt eben langfristig, nämlich in ich sag mal schlecht
wartbarer Code ne sehr hoch oder schnell steigende Komplexität
unter Umständen und das ist für mich würde ich sagen technische
Schuld, so würde ich sie glaub ich definieren.
Ja, ja, ich find es auch gut, das hab ich auch mal gelesen,
dass ja technische Schuld an sich kein Fehler ist.
Ja, weil viele auch sagen. Das sind Fehler, die man einbaut
oder so soweit würde ich ja gar nicht gehen.
Also man baut ja jetzt nicht bewusst Fehler ein, weil man
sagt, OK, ich hab keine Zeit sie zu korrigieren, das wird
natürlich keinen Sinn machen, sondern es geht halt wirklich
mehr in die Richtung, was du meintest, dass es vielleicht
gerade nicht die besten Lösungen sind oder ich einfach schon
weiß, dass ich da noch mal ran muss, ja, dass ich noch ne Rest
auf Arbeit hab, nenn ich es mal. Ich aber bewusst.
Dass in Kauf nehme, dass Sachen nicht vollendet sind aufgrund
von Zeitdruck beispielsweise, das ist so der absolute
Klassiker, wie du ja auch meintest.
Ja, und es ist im Prinzip so ne Art Abkommen, Deal, Vertrag, wie
auch immer mit sich selbst, mit der Hölle zusammen mit der
Hölle, mit mit der Diba Hölle, die dann irgendwann auf einen
zukommt, die Holt einen dann immer wieder einen.
Dass man quasi bewusst Sachen zurückfallen lässt oder oder
nach hinten schiebt, um erstmal weiterzukommen an der Stelle,
also zum Beispiel n Feature abzuschließen, n neues Feature
anzufangen, ne andere Baustelle zu betreten.
Wie auch immer, aber es ist auf jeden Fall irgendwo so n
Abkommen mit sich selbst ja so n Deal mit dem zukünftigen Ich zu
sagen tut mir leid Tino Zukunftstino.
Aber du musst dich da später drum kümmern.
Dafür kann ich aber jetzt das und das schon machen und das
wird dir ja auch helfen irgendwie.
So fühlt sich das ja immer an, weil sonst würde man ja gar
nicht in diese Falle tappen, sag ich mal.
Weißt du was in Ordnung, was ja sogar auf irgendeiner Art und
Weise würde ich sogar noch in Ordnung finden, wenn du
technische Schuld aufbaust und dir sagst.
Tino, Das klären wir später ja, aber in der Realität ist es ja
auch oft so, dass man sich selber sagt, EY, ich bau mal
technische Schuld auf und aber auf irgendeine Art und Weise
nicht ne, also ich sag mal ungesagt nicht sagt.
In meinem Fall Fabi. Du baust aber dann später die
technische Schuld wieder ab. Problem für Zukunftsfabi,
sondern es ist ja dann eher so n Problem teilweise auch für ja
liebes Team. Ja viel Spaß damit und das finde
ich ist eher n Problem, weil wenn du für dich selber
technische Schuld aufbaust und die dann auch wieder abbaust
gewissenhaft. OK, aber oftmals ist es halt
eben in der Realität schon so, dass man dann leider technische
Schuld für sein Team aufbaut und das ist natürlich dann irgendwo
n kleines Problem. Das ist nämlich genau der der
Trugschluss an der Stelle zu sagen, Na ja, ich kann das
später machen und ich weiß dann auch noch genau, was zu tun ist.
Und ich hole das nach und das dauert ja maximal, also
spätestens 2 Wochen ist das ja erledigt, weil ich da nächste
Woche schon anfange, mich drum zu kümmern, und das ist ja genau
nicht die Realität, sondern ich ziehe andere Leute.
Also beispielsweise das Team mit rein, weil diese technische
schuld kann sich so aufsummieren, dass andere davon
auch betroffen sind, dass es halt nicht nur meinen kleinen
Bereich von dem kleinen neuen Feature betrifft, sondern sich
durch die ganze Software zieht, bis hinzu Ich hab diesen dieses
Abkommen mit mir selbst. Aber ich werd mich selbst nie
dran halten und das ist ja nicht mal böswillig, dass man sagt, ja
gar kein Bock drauf, sondern wenn ich einmal in der Situation
war zu sagen, Oh Gott, ich hab eigentlich Grad nicht die Zeit
es so umzusetzen, wie ich es gerne machen würde, werd ich
auch beim nächsten Mal sehr wahrscheinlich nicht die Zeit
haben es so umzusetzen und das ist halt der Trugschluss zu
denken, was ich wie sagt man so schön.
Was ich heute kann besorgen verschieb ich halt auf morgen
und mach es dann da. So funktioniert ja auch das
Sprichwort nicht weißt. Du und deswegen morgen.
Das klappt besser morgen. Genauso geht das Sprichwort
deswegen. Also ich schieb immer mehr auf,
es wird immer schwieriger das Ganze abzubauen und es wird
dadurch auch so ja unwahrscheinlicher, dass ich es
abbaue. Ich mein, Da gibt es ganz
klassische Beispiele. Wir können ja auch mal so die
Best Practices des Schuldaufbauens ansprechen.
Ja, und da ist für mich Platz 1 n schönes to do an den Kommentar
also als also als Kommentar n to do an den Code so rum und das
ist schon das beste Zeichen für Jupp werde ich niemals machen,
ich hab es ja niedergeschrieben, ich hab diesen Vertrag quasi
abgeschlossen mit meinem zukünftigen ich aber.
Ja, weißt du was? Das Problem ist, das ist ja so n
to do ist ja irgendwo mehr oder weniger, dass ein Hint für das
mach ich später und du weißt wie das Ganze läuft ja später Equal
s Never und das ist das was glaub ich vielleicht auch nicht
zu 100% der Fälle aber zumindest schon zu einem einem Großteil
der Fälle, also sagen wir mal 80% halt einfach eintritt ja
erfahrungsgemäß. Und was ich, wo ich echt n
struggle mit hab oder was mich tatsächlich persönlich auf
irgendeine Art und Weise belastet, ja in meinem Alltag
ist die Tatsache, dass wenn du einen Code Review machst, ne,
also sagen wir mal es geht nicht darum, dass du zum Beispiel ne
technische Schuld machst, sondern du musst Code reviewen
und angenommen du reviewst Code und sagst, also ich weiß nicht,
ob du diesen struggle kennst, dass du dir sagst, OK, da ist
jetzt n Code review, ich find da was drin.
Ah Merk ich das jetzt an oder nicht?
Ah, ich will auch keinen Nerven ah ich merk es an nee pass auf
ich merk es an nee komm ah aber wenn du es jetzt nicht anmerkst
ja. Und du musst weiter an dieser,
an dieser Software arbeiten, dann musst du irgendwann selber
damit klarkommen. Verdammt, ich merk es doch an,
weißt du also es ist wirklich, und das ist ja, also das ist ja
auf irgendeine Art und Weise, du hast ja nicht nur aktiv für dich
in der Hand, baust du technische Schuld auf, sondern du hast
natürlich auch irgendwo auf ne Art, also auf beim Code Review
auch die Möglichkeit technische Schuld gar nicht erst aufkommen
zu lassen, also es es geht ja auch darum, dass es nicht immer
der Fall ist, dass du sagst. Das ist jetzt.
Quasi mit Absicht reingecoded ne, aber wenn du es zum Beispiel
wenn du ne Idee hast den Code zu verbessern um halt vielleicht
gar nicht so technische Schuld aufkommen zu lassen, ist man ja
selber auch froh, wenn jemand einem so n Tipp gibt, ne, aber
da kommt natürlich dann auch wieder, das hattest du ja auch
gesagt, hatten wir schon drüber geredet, Zeitdruck oftmals mit
rein, dass man sich so denkt, so komm das muss jetzt mal schnell
fertig werden, komm hier die Zeit drängen und das ist n Pain
wirklich, das ist n so heftiger pain.
Wo es halt echt schwierig ist oder vielleicht auch wirklich
einfach ist, technische Schuld einfach mal aufkommen zu lassen.
Ne, ich find das ist n unglaublich guter Punkt zu sagen
ich muss das nicht mal selbst gecoded haben und kann trotzdem
zulassen, dass technische Schuld aufgebaut wird und Code Reviews
ist einfach das beste Beispiel dafür, weil jeder oder jeder der
Code Reviews durchführt wird sicherlich diesen struggle kenn
den du gerade beschrieben hast und ich selbst kenn den auch nur
zu gut, dass man denkt. Ah, an der Stelle würde ich
schon gern noch mal n Austausch gehen, weil ich glaube, das
sollten wir so nicht tun oder vielleicht wäre es besser noch
das und das da zu machen und damit meine ich jetzt nicht neue
Features oder neue Funktionalitäten allgemein,
sondern wirklich bezogen auf die Implementierung die gemacht
wurde zu sagen, vielleicht sollten wir das umstrukturieren,
wir sollten vielleicht das machen, ah da der und der Test
Case wäre noch nicht schlecht und so weiter.
Ist wichtig, baut oder verhindert, dass das aufgebaut
wird, weil wenn es schon in meinem Kopf ist.
Wenn ich schon merke, das und das wäre gut zu tun, dann bin
ich einfach an diesem Scheideweg zu sagen, entweder ich nehm das
jetzt in Kauf, dass es später gemacht werden muss und
eventuell nie gemacht wird, oder wir investieren jetzt die Zeit
und machen es gleich und bauen gar nicht erst diese technische
Schuld auf und der große Pain dabei ist.
Wie kommt das bei dem Implementi, wie hast du mal
gesagt, ist so n geiles Wort. Bei demjenigen oder derjenigen,
die das implementiert hat an ne, weil wenn Druck drauf ist n
Feature muss fertig werden. Pull request wird gestellt, es
ist ja best nach bestem Gewissen implementiert, aber vielleicht
ist da auch schon so n leichter Punkt von machen wir später.
Hoffentlich geht das so erstmal durch ne möchte man dann da
drüber sprechen. Oder muss man da drüber
sprechen? Ich finde man muss drüber
sprechen, man darf es gar nicht aufkommen lassen, aber die
Realität sieht ja oft anders aus und ich finde es absolut valide
zu sagen, dass man diesen Gedanken hat.
Boah, ich will dieser Person jetzt einfach nicht auf die
Nerven gehen damit, ja, weil das ist grundsätzlich gut
implementiert, das ist grundsätzlich richtig, aber es
kann halt sein, dass uns das so und so aus den und den Gründen
mal wieder auf die Füße fällt, irgendwann.
Und das kann halt auch blöd ankommen.
Ne, gerade wenn Zeitstress drin ist, wenn weißt du auf einer
grünen Wiese am Anfang, wo alle keinen Druck haben, ist das
überhaupt gar kein Thema, da freut man sich ja in diesen
Austausch zu gehen, zu sagen, ja komm hast recht das so und so
wär wirklich cooler komm ich bau das noch mal um, ich stell dann
noch mal n neuen Pull request oder ich sag dir Bescheid alles
cool aber wenn irgendwas fertig werden muss, dann dann trennt
sich die Spreu vom Weizen wie ernst nimmt man das ganze oder
baut man halt diese Schuld auf? Ja.
Ja genau. Also ich find zum Beispiel auch,
also das ist, das ist halt auf jeden Fall n einfach ein n Punkt
wo ich selber mir sage, ja ich verstehe einfach wie technische
Schuld entstehen kann. Weißt du, ich meine das ist
irgendwie also genau diesen Struggle mein ich einfach, dass
man da, dass es nicht von der Hand zu weisen ist, weil das
Schöne ist ja oder das oder was heißt das Schöne, das das
Spannende an der ganzen Geschichte von der technischen
Schuld ist ja, dass wir alle, die wir Software entwickeln, ja,
wir wissen, dass technische Schuld einfach schadet.
Es ist nicht gut, ja, und trotzdem kenne ich persönlich
kein einziges Projekt, wo keine technische Schuld aufgebaut
wurde, weißt du? Also und selbst Literatur
bücherweise wird das belegt, dass alle immer wieder in diese
Falle tappen? Ja, genau.
Also ich meine ich mein technische Schuld kann ja auch
entstehen durch passive Programmierung.
Ich nenn das jetzt einfach mal so, ich finde dieses Wort.
Sorry, da musst du sein. Das ist noch mal ne andere
Geschichte. Ey, da will ich auch.
Das ist der schönere Begriff der passive Programm wir.
Können noch mal drauf eingehen, aber das mein ich aber gar
nicht, sondern ich meine, wenn du entwickelst und etwas tust,
was wo du denkst, das ist gut und das ist auch gut in dem
Moment. Aber in 23 Monaten nicht mehr,
weil kein Refactoring gemacht wurde, dann entsteht genauso
technische Schuld, weil du eben dich nicht um das Refactoring
gekümmert hast und das ist halt das, was ich passiv meine, ne?
Guter Punkt. Was ich aber.
Auch finde und ich da das gut, dass du es sagst.
Bipe Coding ne, ich finde das ist ich find das ist auch n
richtiger Pain weil aus der heutigen Zeit ne wo man mit
Agenten und AI entwickeln kann, da kommt ja wirklich jeder Hans
und Franz. Ich bin jetzt ganz gemein, ja,
und sage, dass da jeder ankommt und sagt, ich kann ja jetzt auch
programmieren, ich möchte auch noch gern was mit reinpacken und
dann kann jeder irgendwie seine Änderungen reinballern, die aber
überhaupt nicht irgendwie fundiert sind so.
In durchaus meiner Meinung nach vielen Fällen.
Und dann kommst du halt einfach auch an den Punkt, wo einfach
unglaublich viel technische Schuld reinfließt, weil Leute,
die Böse gesagt keine Ahnung davon haben, Dinge machen
lassen, aber Dinge sehen schön aus, wenn du keine Ahnung davon
hast und etwas es tut, was den Anschein macht Ahnung zu haben,
ja. Ja, ich mein, Da haben wir auch
mal ne Folge zu gemacht, dass gerade im Open Source Bereich
ja. Förmlich maintena überschwemmt
werden ja von AI CODE oder AI unterstützt n Code und sie halt
versuchen keine technische Schuld aufzubauen und Guidelines
und Richtlinien der Projekte einzuhalten und das alles
durchgucken müssen. Diese Flut an Codezeilen ja und
das ist n Riesenthema und das ist bei jedem Projekt wo das zum
Einsatz kommt genauso n Riesenthema ob das Open Source
ist oder nicht also es ist n absoluter Lider Punkt.
Der auch richtig kritisch ist, bin ich gar nicht bei dir auf
jeden Fall und. Damit kannst du halt auch super
schnell technische Schuld irgendwie reinbringen.
Ne, aber es ist ja auch irgendwo so n Belohnungssystem im Kopf
ne, weil gerade ich meine das das kennst du ja bestimmt auch
wenn man jetzt denkt man hat irgendeine Aufgabe und du
kriegst die schnell fertig ne also was ich meine ist man kann
schnell was implementieren, schreibt aber vielleicht keinen
Test dazu. Weil angenommen Test schreiben,
man muss halt nachdenken. Wie schreibe ich den Test?
Jetzt kenne ich das Framework beispielsweise um den Test zu
schreiben, was auch immer, aber wenn du einfach nur sagst, ich
weiß ganz genau wie das funktioniert und ich bin mir
hundertprozentig sicher, auch wenn vielleicht dann doch n
Fehler sich einschleicht, weil ich war auch mir schon in meiner
Vergangenheit hundertprozentig sicher, dass dieser fix auf
jeden Fall passt, er aber nicht gepasst hat, weil ich keinen
Test dazu hatte. Ja, aber das ist.
Weil das dieses schnelle Belohnungssystem, wo man sich
einfach denkt, so, Boah, es ist geil, es macht Spaß, diesen
Fortschritt zu machen, diese schnelle jetzt weiter, weiter,
weiter, das ist schon geil, aber damit baut man halt eben halt
auch technische Schuld auf und genauso ist es mit vipe Coaling
glaube ich auch oder mit prompt Engineering wir, wie du es
nennen magst so ne. Ja, es es fühlt sich natürlich
immer besser an, neue Sachen zu implementieren, die man zeigen
kann, die auch vorzeigbar sind. Ne, also das halt wirklich was
Neues in die Software gekommen ist.
Tausendmal besseres Gefühl als Sachen zu Refact an ja Klassen
neu zu strukturieren, die Architektur wieder gerade zu
ziehen, was ja auch so n Punkt ist.
Ne wenn du anfängst leicht. Nur so n bisschen abzuweichen
von deinen Architekturentscheidungen.
Aber du bleibst auf diesem Kurs, ja, dann bist du logischerweise
irgendwann richtig weit abgedriftet und dann wird es
halt richtig nervig das alles wieder gerade zu ziehen, weil es
ja umso mehr ist. Und deswegen ist es ja wichtig,
immer regelmäßig zu refactern oder beispielsweise warum Test
Driven Development auch n refactoring Schritt richtig inne
hat. In der Methodik sag ich mal,
weil dadurch linest du dich immer wieder mit deinen
Guidelines, sag ich mal mit deinen, mit deiner Architektur
und du kannst immer wieder oder hast n festen Schritt wieder zu
prüfen ob du noch auf Kurs bist. Das ist ja nichts anderes als.
Ja noch mal deinen Kurs zu korrigieren.
Ja, weil wenn ich ne Weile falsch fahre, dann wird es halt
nervig, dann muss ich quasi das Stück zurück, sag ich mal
bildlich ja und mich neu ausrichten und noch mal in die
Richtung fahren und das ist ja eigentlich der das Nervigste was
es gibt und dann hat man immer weniger Bock drauf und es wird
immer unwahrscheinlicher quasi und trotzdem ich mein mir fällt
jetzt auch mir fallen wenige Projekte ein in unserem Umfeld.
Sei es privat, beruflich, mit Coding Buddies, was auch immer,
wo nicht technische Schuld drin ist.
Also da muss man ja einfach ehrlich sein.
Ja, also es gibt so ein 2 Projekte wo ich das Gefühl jetzt
hätte oder wo ich so n bisschen die Hand für ins Feuer legen
würde, wo ich sagen würde das ist wirklich n guter Stand so ne
also wirklich top ja weiß nicht, dass da nicht noch was drin ist,
aber vor allem heißt das, weil erst vor kurzem mal n größeres
Refactoring stattgefunden hat. Ja, ja, das ist ja der
entscheidende Punkt am Ende. Du musst das regelmäßig machen,
um immer wieder auf Kurs zu bleiben.
Ich find zum Beispiel, weil du auch meintest den refactoring
Schritt im TDD. Ich finde technische Schuld im
ganz kleinen Stil geht meiner Meinung nach schon los, wenn du
Code schreibst und sagst OK passt Let's goso weißt du, du
probierst es aus, es funktioniert also ich weiß nicht
wie es dir geht, aber wenn ich Code schreibe.
Oder halt auch mittlerweile schreiben lassen muss man auch
dazu sagen, es ist immer so, mal so, mittlerweile mehr noch
schreiben lassen tatsächlich, es ist ja immer so eine Art von
Review, man guckt sich das Ganze an, ob ich selber programmiert
habe eine Funktion oder sie mir habe programmieren lassen von
ich gucke mir die Funktion hinterher an, weißt du also ich
gucke mir das an, ich gucke. Wie hab ich das gemacht?
Geht da noch n bisschen was? Ne das ist ja genau dieses
Refactoring, also selbst wenn du ne TDD machst n roten Test
machst grün und guckst noch mal ob das ob du noch irgendwie was
geiler machen kannst und genauso wenn dir die AI Code ausspuckt,
dann guckt man ja nach und denkt sich so OK kann man da noch
irgendwie was optimieren? Passt da vielleicht noch
irgendwas? Mir nicht weil man hat ja auch
so seinen eigenen Flaper wie man codet und so weiter und wenn man
das aber nicht macht finde ich dann geht geht schon diese
kleine technische Schuld los. Und das ist gerade bei so
Leuten, die Krieg ich auch gerne mal mit, dass Leute AI nutzen,
Vibe Coding betreiben oder wie man es wie gesagt nennen möchte
und dann sich denken, es funktioniert ja also du sagst
bau mir das, dann wird geguckt funktioniert was was ist was ich
geprompted habe ja guck mal das funktioniert ja super, also bin
ich fertig. Und das ist glaub ich n richtig
richtig großes Problem, gerade in der heutigen Zeit, wenn es um
technische Schuld geht, dass jemand einfach sagt, ich prompte
mir irgendwas zusammen, teste kurz ob das funktioniert.
Ja es funktioniert perfekt, super, ich bin fertig so und
dann weiß nicht das wird dann technisch gar nicht mehr
hinterfragt oder evaluiert, das ist irgendwie find ich auch n
schneller Punkt wo sowas dann einfach stattfindet, ne.
Ja, man muss ja auch sagen, was ist so das Feingranularste, wo
man technische Schuld anfangen kann aufzubauen.
Und da finde ich es gut, dass du es ansprichst, weil das geht ja
schon los, wenn ich mir denke, ja, der Funktionsname ist noch
nicht so optimal. Die Variable ist auch noch nicht
so optimal benannt, so war es halt.
Es sind so Kleinigkeiten, ja, dass du jetzt schon merkst, ach
so richtig gut getroffen ist das nicht, aber ist erstmal OK, ist
erstmal OK, mach ich später, vielleicht fällt mir irgendwann
noch was Besseres ein, Spoilerwarnung, man wird gar
nicht noch mal drüber nachdenken, wenn man es in dem
Moment nicht vollendet. Ja, wie ist der, wie heißt der
Test? Ja, nenn es erstmal so oder so
immer dieses das merkst du ja auch beim Pair Programming zum
Beispiel was wir bei dir viel machen wenn sowas kommt wie
beide sagen Na ja dann lass erstmal das so und so machen, er
ist schon dann müssten schon die Alarmglocken angehen, dass man
zumindestens das noch mal wirklich Double checkt, so ja,
aber es ist nun mal die Realität ja boah hast du n variablen
Namen? Nee mir fällt nichts ein Ah der
ist aber nicht so geil ja nee irgendwie ist der nicht so geil
ja lass erstmal so. Klassischer Ablauf eines Dialogs
bei sowas weißt du also und ich finde, wenn man sich da drauf
besinnt und jedes Mal bei in solchen Situationen daran wieder
denkt an unsere Worte hier, dann kann man da vielleicht sich
denken, so ach na ja, dann lass uns doch noch mal 5 Minuten kurz
drüber nachdenken, sind nur 5 Minuten, aber.
Weißt du, wenn du in 5 Wochen gar nicht mehr weißt, was da
passiert, weil du den Funktionsnamen überhaupt nicht
mehr zuordnen kannst oder was komplett falsches dahinter
verstehst? An anderen Stellen hast du ja
auch nichts gewonnen, aber es nervt natürlich und es ist auch
Fakt. Es ist ja auch anstrengend, ja
es es kostet ja. Mentale Kraft in dem Moment, die
man ja vielleicht eh schon gut verbraucht hat an dem Tag, ist
ja jetzt auch nicht undenkbar, dass man sagt, Ey du, ich bin
ganz schön durch heut schon, und dann kommt auf einmal sowas noch
ne und nervt, das nervt dann halt.
Ist dann nicht das schnelle Belohnungssystem, was dann
anspringt an der Stelle ne? Das fühlt sich wie n
Bestrafungssystem an. Ja, das kenn ich auch, aber es
hilft halt einfach auch, wenn man jetzt zum Beispiel nicht
gerade per Programming macht, der auch einfach mal, wenn man.
Sagt EY. Scheiße, ich hab hier irgendwas,
wo ich mir nicht sicher bin, ob ich das so machen würde oder
nicht. Es hilft ja auch einfach mal im
Team nachzufragen, sich irgendwen zu nehmen um zu sagen,
ey ich hab echt mal ne Sache, hast du mal kurz Bock darüber zu
sprechen? Ja es ist einfach auch hilfreich
um da auch noch mal n anderes Feedback zu kriegen, weil ich
hab das auch schon öfter gehabt so mittlerweile kann man sich
natürlich hinstellen und auch sich mit sag ich mal mit der AI
fachsimpeln ja aber. Ich hab, ich hab doch so ganz
viele verschiedene Meinungen, die man da so hört.
Ja, weil eigentlich sind es gar nicht so viele verschiedene,
weil es sind halt 2. Die einen sagen ja AI auf jeden
Fall, sag dir auf jeden Fall was geiles, ich hab aber auch schon
oft halt mitgekriegt, dass man so brainstormed fachsimple Ideen
gibt und an einer Idee immer was zu meckern ist oder auch
teilweise Ideen kommen die. Halt irgendwie, wo ich mir
denke. Was soll denn das jetzt?
Und dann sag ich ja, aber ich hab ja eigentlich hab ich es mir
so gedacht, ja, ja das ist wirklich ne gute Idee so und
dann denk ich mir so OK, sagst du jetzt, dass ne gute Idee ist
oder sagst du weil du deinen Algorithmus sozusagen mir
zustimmen soll? Ne so dann kommt wieder
irgendjemand und sagt ja da musst du aber deine AI auf jeden
Fall mitgeben, dass sie dich immer challengen soll.
Ja gut, das bringt aber auch nichts wenn du irgendwann mal
auf ne Findung kommen willst für für ne und ja.
Das ist halt. Da hilft halt trotzdem manchmal
noch dieser normale Austausch. In Anführungsstrichen.
Weißt du was ich mein? Ja, der ist Gold wert.
Auf jeden Fall auf jeden Fall. Was sind denn noch so Sachen?
Also ja, so variable Namen Funktionsnamen so n richtiger
Klassiker sind auch so copy paste Lösungen oder also wenn du
sagst zum Beispiel ja an der Stelle boah da kann ich das aber
nicht verwenden aber ich hab so was ähnliches schon mal gemacht,
mehr Pass auf das nehmen wir uns wandeln das n bisschen ab.
Passt schon, ja, also gibt es auch verschiedene Ansichten,
manche sagen Don't Repeat yourself muss komplett gnadenlos
durchgezogen werden, haben wir auch mal ne Folge zu gemacht,
ist auch n spannendes Prinzip, sind wir ja aber auch zum
Schluss gekommen, so ja das sollte man jetzt nicht so
dogmatisch verfolgen ja also es gibt Situationen, wenn du es zum
Beispiel zweimal was ähnliches drin hast.
Ja und die IDE sagt schon Oh duplicated Code erkannt ja 5
Zeilen wow klasse. Ja, also gut, dass es drauf
hinweist. Keine Frage, gutes Feature, aber
das ist OK. Ja sowas, das kann, das ist in
Ordnung, das ist erlaubt, da wird jetzt niemand irgend n
Schaden von tragen sozusagen. Ja die Frage ist was ist wenn
234 mal drin ist? Wo ist die Grenze zu sagen Boah
nee, jetzt muss es refectod werden und wenn ich gerade jetzt
schon merke, irgendwie hab ich das jetzt schon einmal zu oft
gemacht, diesen Move, ja der ist zwar ne gute Abkürzung und
bringt mich vorwärts, aber. Hab das irgendwie letzte Woche
erst gemacht, so, ja dann ist vielleicht mal wirklich der
Zeitpunkt da zu sagen du ich bau hier gerade wirklich mir wieder
meine kleine Burg aus technischer Schuld auf,
vielleicht sollte ich das mal Refact an und doch mal gucken,
dass ich das n bisschen auslager das ganze ist auch so n
klassisches Beispiel was mir ja auch wirklich oft passiert, dass
man in diese Situation kommt, ja.
Wenn jeder Task anfängt mit ah, ich kann das, könnt ich glaub
ich copy und pasten. Nee, ich, ich geb dir mal n
Beispiel ja wo man immer wo ich oft denke ist nicht so wild ist
nicht mal im Produktivcode sondern in der Testsuite.
Du baust dir testszenarien auf und du Testest zum Beispiel n
Controller ab ja oder oder oder oder was auch immer ist
eigentlich egal, aber du hast nen gewissen Aufbau den du
brauchst am Anfang und dann nimmst du dir n bisschen davon
daten bisschen davon und baust dir so dein Szenario zusammen um
den eigentlichen Test laufen zu lassen und jetzt merkst du, dass
du ziemlich oft 23. Teilen davon 23 Objekte, die du
Erzeugst in jedem Test irgendwie machst.
So, dann kannst du ja weiß ich nicht, gibt es ja verschiedene
Möglichkeiten, aber du kannst es ja, denn einfach du merkst es,
springt dich förmlich an zu sagen, ey, vielleicht müsste ich
mir meine Test Suite mal n bisschen konfigurierbarer
machen, sag ich mal, dass ich sage ey pass auf diese Schritte
muss ich nicht immer machen, ich kann mir auch so ne Art Package
ziehen die das für mich macht und wenn ich Abänderung brauche
kann ich das damit reingeben ja, dass mir.
Keine Ahnung n Bilderbau oder so, der mir das irgendwie cool
zusammensetzt. Mein Testszenario und dass ich
dann quasi meine Prämissen gegeben hab und ich kann jetzt
den Test laufen lassen, wär jetzt so n Klassiker so ne Art
Testbilder ja der mir die Testdaten irgendwie generisch
zusammenbaut, ich aber noch Input Reingeben kann und sagen
kann ey aber in dem Fall brauch ich es n bisschen anders, aber
das heißt ich muss es nicht in jedem Test mal selbst machen
weißtes Beispiel und trotzdem fängt man an bei wenn du neues
Projekt hast, baust du dir die Testsuite auf.
Jetzt brauch ich das, jetzt brauch ich das, jetzt brauch ich
das und dann kommt immer also bei mir immer wieder der Punkt
wo ich mir denke alles klar Zeit für n Test refactoring.
Ja, das kenn ich auch auf jeden Fall.
Aber lustigerweise kommt das, man kennt es, es kommt trotzdem
immer wieder vor. Es es passiert immer wieder.
Du kannst die Uhr nachstellen. Ja, da kannst du wirklich die
Uhr nachstellen, dass das irgendwann passieren wird.
Ich mein ist, das ist auch ne sehr sehr gute Frage, die wir
vielleicht noch klären sollten. Lässt es sich überhaupt final
verhindern oder ist es OK technische Schuld aufzubauen
oder dass es passiert ist es grundsätzlich OK, dass es
passiert, aber muss man quasi das Risiko dahinter managen?
Wie siehst du das? Also ich glaube, das ist.
Auf jeden Fall ne gewisse Art und Weise von technischer Schuld
aufzubauen ist irgendwo OK. Aber es kommt halt immer n
bisschen drauf an. Ja wie du das Risiko managst,
also auf der einen Seite finde ich zum Beispiel angenommen du
sagst du hast irgendwie n Pull request ne und das ist wirklich
gerade dringend, irgendwas muss fertig werden, ne dann ist es
finde ich völlig in Ordnung zu sagen du Pass auf komm das kommt
jetzt rein und das was man gesagt hat ja wir müssten das
eigentlich dann noch mal richtig machen in Anführungsstrichen ja
weil es ist ja auch dieses typische Beispiel mal eben n
kleiner Hack, irgendwie schnell mal was reinballern.
Ist problematisch, wenn man sagt, OK, ich handle halt dieses
Risiko nicht, wie du es so schön gesagt hast, weil wenn du das
nicht machst, dann ist es n absolutes ja was heißt no go?
Es passiert, aber es ist halt so, Verdammnis quasi verurteilt
schon ne, aber wenn man einfach nur sagt OK wir haben jetzt
gesagt das muss noch gemacht werden erstellen Ticket.
Zum Beispiel, wo das einfach transparent ist, dass das noch
dran kommt, dass du es nicht vergessen kannst, ne oder du.
Hast berücksichtige das Ticket und lass es nicht irgendwo n
Backlog versauen. Auch das auch das sehr sehr
wichtig ne Sache von sag ich mal Organisation aber genauso ist es
ja möglich zu sagen OK wir hauen das jetzt rein und direkt im
Anschluss ja der fix ist draußen es funktioniert und direkt im
Anschluss. Geht man das Ganze an, ist auch
OK. Guter Punkt ist auch kein
Problem, aber und das ist ja das richtige Händeln von diesem
Risiko, aber das ist genauso wie wenn du sagst Kleinigkeiten
umsetzen, nie refactern, nie mal die Software wieder betrachten
und gucken, was kann ich denn machen, das ist auch nicht diese
der der richtige Umgang damit. Wenn du aber regelmäßig
refactoring machst, dann ist das in Ordnung, ja.
Bei technischer Schuld kannst du nicht komplett verhindern, wie
du glaub ich auch gerade schon gesagt hast.
Ne ich. Find das ist auch n gutes Fazit,
weil man denkt immer weil jede jedes Projekt was neu startet
jetzt mal was sauber ich fang richtig sauber an, wir werden
das so richtig sauber durchziehen, es heißt ja nicht
nur weil ich technische Schuld aufbaue, dass ich nicht sauber
arbeite, ja ich finde sofern muss man sein an der Stelle wenn
sich jemand hinstellt und sagt was ist denn das da, was ist
denn das Oh oh oh oh. Jetzt hast du aber richtig
geschlampt, so ist es ja nicht, sondern Projekte erfordern das
manchmal. Gegebenheiten erfordern das,
oder ich finde, manchmal baut man technische Schuld ja auch
unwissentlich auf, zum Beispiel das passive finde ich gut, was
du meintest vorhin oder weil ich halt auch so n bisschen
Prinzipien wie Jakny zum Beispiel im Kopf habe, dass ich
mir denke. OK, ich habe das Gefühl, das und
das wäre besser so und so zu machen, aber ich brauche es
jetzt einfach noch nicht. Beispielsweise nehmen wir noch
mal die Test Suite, ich schreib meinen ersten Test.
Wozu soll ich da irgendein Bilderkonstrukt aufbauen und
sagen, Boah jetzt kann ich aber schon mal richtig richtig geil
testdaten erzeugen. Ja und mir zusammenbauen lassen
und dann fragte ich dein Kollege oder deine Kollegin ja aber
warte mal wir sind beim ersten Feature und es gibt einen Test
also. Ich 2 Zeilen alter, was machst
du da? Weißt du also sowas kann sich ja
auch beißen und dann habe ich quasi unbewusst technische
Schuld aufgebaut, die in der Zukunft vielleicht wieder auf
mich zurückfällt, dass man dann sagt, Boah, hätten wir mal schon
testbilder, weißt du, aber das weißt du ja am Anfang nicht,
oder? Beziehungsweise du ahnst es aus
anhand von Erfahrung, die du gesammelt hast, dass dieser
Punkt kommen kann, aber es ist ja auch nicht richtig, das denn
sofort anzugehen, weil dann. Bist du an anderer Seite wieder
irgendwie nicht so optimal unterwegs und deswegen finde ich
es voll in Ordnung zu sagen, technische Schuld lässt sich
nicht verhindern, aber ich muss es managen, es muss immer in
einem Manage in einem verwaltbaren Rahmen sozusagen
sein, dass ich jederzeit irgendwie noch n gutes Gefühl
über dieses Projekt habe und dahinter stehe und sage, ich bin
überzeugt, also meine Zuversicht zu diesem Projekt ist hoch.
Ja, und das ist irgendwie n wichtiger Punkt und man hat ja
ich hab es auch schon mal gelesen oder hattest du mir das
gesagt? Ich weiß es nicht mehr, aber
dass es wieso ne Art Kredit auch ist.
Ja dass ich sage OK ich heb jetzt was ab so ich erlaube es
mir jetzt sozusagen potenziell technische Schuld aufzubauen im
Zuge dafür, dass ich jetzt schneller vorwärts komme, aber
ich muss das zurückzahlen, ich kann dich nur abbuchen
sozusagen, ich muss auch mal wieder einzahlen.
Und das ist halt das Refactoring am Ende, ja.
Das ist n gutes Bild und ich glaube also was man ja auch
sagen muss, also abschließend vielleicht noch mal, weil du
meintest, man kann es nicht immer verhindern und gerade wenn
du auch von außen drauf guckst und ich finde, das ist auch so n
Punkt, da muss man sich auch in dem Moment auch noch mal n
bisschen dran orientieren, wenn du Reinkommst in ein Projekt was
du nicht kennst, wo du nie dran gearbeitet hast.
Dann ist die Wahrscheinlichkeit sehr hoch, dass der
Außenstehende oder die Außenstehende sagt, was n.
Das hier würd ich so nie machen. Ja und da muss man vielleicht
also es es fällt n bisschen auf n anderes Blatt, aber ich finde
damit muss man auch einfach mal dealen, weil das geht richtig
richtig schnell und. Da muss man dann auch einfach
wirklich differenzieren und sagen, ja, OK, wir haben halt
technische Schuld. Sicherlich hat jeder
wahrscheinlich irgendwo, aber die Frage ist, wie geht man
damit um und wenn man damit ordentlich umgeht und vielleicht
auch lernt damit umzugehen, es ist ja immer ein lernen, dann
kann das halt am Ende auch irgendwie klappen.
Da spielen dann die Softskills auch wieder ne Riesenrolle.
Ich komm in ein Team, ich sehe das oder jemand kommt in.
Das Team, in dem man selbst ist. Ja, die Rollen gehen ja in beide
Richtungen und sieht die technische Schuld aus dem
eigenen Projekt. Wie kriegt man das vermittelt,
wie kommuniziert man das und wie geht man die Sache an am Ende,
und das ist, finde ich unfassbar essentiell und das zeichnet auch
gute Entwicklerinnen und Entwickler am Ende aus, ja sich
nicht hinzustellen und zu sagen was das für ne Scheiße, warum
habt ihr das gemacht, ist das euer Ernst?
Wollen wir mal bitte wieder von vorne anfangen, wir machen das
komplett neu, Leute. Gar nicht cool, so reinzukommen.
Ja schade, aber schade. Aber dann fängst du neu an.
Alles ist cool und auf einmal komischerweise was n das
technische Schuld, wo kommt die denn?
Da kommt nämlich der nächste nach dir und der Teufelskreis.
Nein, aber. Das ist noch n abschließender
sehr wichtiger Punkt und ich finde das sollten wir noch ganz
kurz thematisieren, da will ich ja auch gerne mal deine Meinung
hören. Du bist jetzt derjenige, der
reinkommt oder derjenige, der in diesem Projekt schon war und du
hast diese Situation, weil es einfach super wahrscheinlich
ist, dass man in diese Situation kommt und jetzt fühlt es sich so
an wie Boah, das ist ein riesen Berg an refactoring Aufwand,
wenn ich das jetzt mache, da muss ich das überall machen und
es ist echt viel. Wie kann ich jetzt trotzdem
systematisch anfangen, dagegen zu wirken?
Also ja gut, Punkt 1 ist natürlich nicht noch weitere
aufbauen oder so wenig wie möglich, wir haben ja gesagt, es
lässt sich nicht immer verändern, aber natürlich, wenn
ich den Drang hab oder den die Tendenz habe sehr starke
technische Schuld aufzubauen einstellen OK, aber wie kann ich
das sinnvoll abarbeiten, weil da hatten wir ja auch schon viele
Gespräche, dass es oft so ist. Boah, ich weiß gar nicht wo ich
da anfangen soll. Ja, also ich, ich würde da auf
jeden Fall auch gerne irgendwann also auch die Meinungen von von
dir Liebe liberzürer Liberzürer hören, aber ich würde
tatsächlich gucken, dass ich mir immer einen gewissen Zeitraum in
der Woche zum Beispiel oder ne regelmäßig wirklich regelmäßig,
das ist die das Wichtige dabei raussuche rauspicke und dann
Stück für Stück das ganze ändere.
Und wenn ich an den Teil von dem von dem.
Von dem Code komme wo ich merke, Oh das, da müsste man was
machen, dann am besten auch gleich mitmachen ist natürlich
immer ne Frage der Zeit wie das geht, aber wenn du dir trotzdem
sagst nebenbei nehme ich mir immer regelmäßig Zeit um eine
Verbesserung zu machen, dann würde ich das so machen ne also
strukturiert n bisschen gucken OK von da nach da nach da 1 nach
dem anderen. Nicht alles auf einmal also.
Nicht, dass man sagt, jetzt hier einen Monat nur refactoring,
sondern so reinmixen, dass man refactoring macht und das aber
auch irgendwo transparent, immer nach außen.
Spiegelt sehr guter Punkt und das deckt sich ja auch mit
diesem Risikomanagement am Ende ne, dass ich sage keiner
erwartet oder sollte erwarten, dass man da die technische
Schuld komplett abbaut, dass man sagt, jetzt machen wir das, wir
gehen auf 0, utopisch. Wenn ich aber, wie du meinst,
regelmäßig refector und daran darauf aus bin diese zu
minimieren, komme ich wieder in einen Bereich, den ich handhaben
kann und das ist alles. Die muss nie bei 0 sein.
Es können auch to dos drin sein, aber es geht immer darum kann
ich dahinter stehen mit dem Stand so wie er ist.
Ja also habe ich die Zuversicht, dass hier immer noch alles
richtig im grünen Bereich ist. Das sind, so finde ich, wichtige
Punkte und da muss man das immer so rein balancieren.
Und regelmäßiges Refactoring ist eigentlich mit das Beste, was
man da machen kann und natürlich auch mal Sicht von anderen,
deswegen so neue Kolleginnen oder Kollegen im Team können da
auch sehr gut helfen, weil sie halt einfach diesen Blick haben,
dafür noch ne OK mega cooles Thema, Fabi hat mir richtig Spaß
gemacht sich da auszutauschen, deswegen vielen Dank dafür ich
würd sagen ich mach mal den Sack zu, wir haben es ausführlich
besprochen. Liebe Zuhörer, liebe Zuhörer,
falls du Anmerkungen dazu hast, Erfahrungen, Best Practices, wie
du das Angehst, lass es uns sehr, sehr gerne wissen.
Meld dich auf allen Plattformen, die wir zur Verfügung stellen,
such dir eine aus, wir werden auf jeden Fall antworten,
findest auch ne Mail in den Shownotes und wie gesagt voll
gern den Podcast. Das würde uns ungemein
unterstützen, oder aber wenn du so richtig richtig Bock hast da
drauf und uns richtig cool findest, findest du auch n
spenden Link in den Shownotes dann vielen vielen Dank dafür.
Und ansonsten haben wir uns alle nächste Woche wieder.
Habt ne schöne Woche bis dahin eure Coding Buddies ciao ciao.
Gemeinsam besser. Ich glaube, ich muss jetzt
langsam mal angrillen. Alter, ja gut sein Alter ohne
Scheiß so ne Pfanne mit Kartoffel, Spargel und Zwiebeln,
das war, das war der Schüttmann.