Latest / Coding Buddies | Tech & Dev-Mindset / #164 Technische Schuld: Der Preis für schnellen Code

Transcript

#164 Technische Schuld: Der Preis für schnellen Code · Coding Buddies | Tech & Dev-Mindset

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