Latest / Coding Buddies | Tech & Dev-Mindset / Clean Code #5 - Theorie vs Praxis

Transcript

Clean Code #5 - Theorie vs Praxis · Coding Buddies | Tech & Dev-Mindset

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