Latest / Coding Buddies | Tech & Dev-Mindset / #138 Stop it! Unsere No Go's als Softwareentwickler:in

Transcript

#138 Stop it! Unsere No Go's als Softwareentwickler:in · Coding Buddies | Tech & Dev-Mindset

0:00
Implementierender sagt man das so, dass ich das Implements Laco
0:04
Mitzaue der Implementier genau das klingt wie lateinisch Coding
0:10
Buddies, dein Podcast rund um Softwareentwicklung und
0:13
aktueller Tech News. Herzlich Willkommen.
0:27
Einen wunderschönen guten Tag und herzlich Willkommen zur
0:30
neuen Folge vom Coding Buddies Podcast.
0:33
Es ist mal wieder soweit, es ist Donnerstag, es gibt eine neue
0:36
Folge und damit geht es auch direkt wieder los und zwar mit
0:39
Dino, der hier schon vor mir sitzt, quasi schon völliger
0:44
Motivation strotzend hier und der Fabi Dino was.
0:50
Geht ab Alter. Was geht ab?
0:54
So war so schön. Ich wusste jetzt nicht, wo der
0:56
Part kommt, wo ich einsteigen soll.
0:57
Ich hab den jetzt einfach reingeplatzt so weißt du ja
1:00
manchmal weißt du, manchmal moderiert man es an und dann
1:03
guckt man den anderen so in diesem virtuellen Fenster an und
1:07
der freut sich schon, so weißt du, du sagst auch immer, wenn
1:09
wenn ich so grinse oder so ne, aber das ist immer ist immer n
1:12
schöner Anblick wollte ich nur mal gesagt haben, dass wir uns
1:15
immer so freuen. Eben so soeben, so danke.
1:21
Ja, schön schön, dass wir uns hier wieder versammelt haben,
1:23
Mensch. Lange ist er ja ungefähr ne
1:25
Woche. Ist ja ist immer so ne Woche
1:27
her, dann ungefähr sonst. Sehen wir uns ja nicht quasi.
1:31
Das stimmt, das stimmt, das stimmt ja.
1:34
Was, wie ist es dir, gang die Woche jetzt immer?
1:37
Ach ganz gut, ich hab mal drüber nachgedacht, frag mich nicht
1:42
warum, ich hab drüber nachgedacht warum die Wände im
1:45
Normalfall immer weiß gestrichen werden, weißt du?
1:49
Klingt jetzt n bisschen, klingt jetzt n bisschen weit hergeholt,
1:52
aber ist doch wirklich, also noch nicht, wo das hier
1:55
hinausläuft, aber OK, das war die Frage der Woche für mich.
1:58
Weil du musst dir ja vorstellen, die meisten Wände sind ja weiß
2:01
gestrichen, so ne aber weiß ist ja die Farbe die am schnellsten
2:04
dreckig wird, ne also ist die Frage warum musst du mir jetzt
2:10
nicht beantworten ne? OKOKOK mach ich, mach ich dann?
2:14
Pass auf, lass mal die Community beantworten, Liebe zuhören,
2:17
Liebe zuhören, wenn du ne gute Antwort darauf hast, dann
2:19
schreib uns die, dann kann Fabi die mitgeteilt bekommen das und
2:23
dann tragen wir das mal zusammen.
2:26
Und welche Wandfarbe ist deine lieblingsfarbe?
2:29
Klar. Also ich bin, ich muss sagen,
2:31
ich bin teamweiß ich auch weiße Wände schon gut.
2:34
Ich ja auch. Aber ich hab mich nur gefragt
2:36
warum. Ich könnt mir.
2:38
Vorstellen, ja, ich mein ganz kurz, aber Streich doch mal
2:42
alles schwarz und dann? Lass mal ne Woche wirken und
2:45
dann frag dich noch mal warum weiß.
2:47
Richtig Depri, der war ich mein ja, ich glaube ja, ich glaube
2:52
ja, meine Vermutung ist ne weiß ist einfach neutral, weiß
2:56
verändert nicht die Stimmung oder das Verhalten ne wie zum
2:59
Beispiel rot kann also man sagt Ja rot ne wird man wütend ja
3:03
wenn du alles rot streichst bist du dann Zeit wütend?
3:05
Ich weiß es nicht, hab ich noch nicht probiert.
3:09
Wäre auf jeden Fall no go, alles in rot zu streichen.
3:15
Warum ich no go sage, ja, da kommen wir gleich noch mal drauf
3:17
zurück, aber weil das geht ein bisschen in die Richtung unserer
3:21
heutigen Folge, aber bevor wir da jetzt richtig reinstarten,
3:23
möchte ich noch einmal ganz kurz anmerken, Liebe zuhören, lieber
3:27
Zura denkt dran, es läuft ja unser Turnier 4 gewinnturnier.
3:32
Vor connect Extreme, besser gesagt Macht auf jeden Fall mit.
3:36
Ja, Check das mal auf aus auf unserer Homepage, das ist auf
3:39
jeden Fall in den Shownotes verlinkt, da findest du auf
3:42
jeden Fall alle Infos zum Turnier und Mitmachen lohnt
3:45
sich. Genau, es gibt wieder gute
3:47
Preise. Wir sind ja immer stets bemüht.
3:52
Sponsoren zu bekommen und einen Sponsor zum Beispiel ist Jet
3:56
Braints. Da freuen wir uns mega drüber,
3:58
den sei mal hier an der Stelle genannt und die Preise sind auch
4:02
nicht ausschließlich, aber auch zum großen Teil von Jet Braints
4:05
gesponsort und schau da auf jeden Fall mal vorbei.
4:07
Die Aufgabe ist mega cool so n bot zu implementieren macht Mega
4:10
Spaß und wir freuen uns auf deine Einreichung, so sieht es
4:14
aus das was Tino sagt und jetzt noch mal zum Thema No go warum
4:18
ich gesagt hab no go. Das ist ja auch Thema der
4:21
heutigen Folge. Und zwar geht es jetzt nicht um
4:24
No Gos beim Streichen, sondern um No Gos in der
4:28
Softwareentwicklung und ich hab mir gedacht, es wär doch schön
4:30
oder wir haben uns gedacht, es wäre ja schön, wenn wir einfach
4:33
mal darüber sprechen, was für uns richtige No gos sind.
4:38
Also wenn es jetzt zum Beispiel um die Softwareentwicklung geht,
4:41
ne, ich würd es jetzt offen lassen zu sagen in der
4:44
Zusammenarbeit an in einem Projekt an Software.
4:50
Oder wenn es jetzt wirklich nur um wirklich explizit um Code
4:53
geht, den man vielleicht mit einem anderen Menschen sozusagen
4:57
teilt oder so beziehungsweise gleichzeitig contributed, sei
5:02
mal hingestellt, ne, aber wirklich so in in dem Alltag
5:05
eines Softwareentwicklers oder einer Softwareentwicklerin ne,
5:07
was sind No gos aus unserer Sicht, da würd ich gern mal
5:11
wissen, was sind deine no gos? Ich würd auch sagen was so n
5:13
bisschen also was auch meine No gos sind und.
5:18
Ja, da würd ich einfach mal sagen, lass uns doch mal gucken,
5:20
was sogar nicht geht. Also also nicht nur Coden an
5:25
sich, sondern auch Projektarbeit, Teamwork, ein aus
5:28
allen Bereichen. Ja, also du, du bist ne Tino, Du
5:31
bist Softwareentwickler oder Software engineer ne so und egal
5:36
was für dich n no go ist in deinem Dasein ja Teil es uns.
5:41
Geht OKOK jetzt gehen wir gleich richtig hart rein.
5:45
So und kotzen uns komplett aus. Starten war sanft wie du
5:50
möchtest. Das ist ja auch OK.
5:52
Du konntest doch direkt, was mir als Erstes auffällt oder
5:57
einfällt nicht auffällt ist ne Sache, da bin ich auch n
6:02
bisschen vorgeschädigt aus alten Projekten und zwar ist es für
6:06
mich n absolutes No go wenn es heißt im Projekt so jede Zeile
6:12
Code muss kommentiert sein. Also wenn super viele Kommentare
6:19
am Code sind das für mich n absolutes No go.
6:22
Also ich mag es kurz erläutern, ich hab mal in einem Projekt
6:25
gearbeitet wo der PM beziehungsweise der PO war es ja
6:30
war so ne Doppelrolle schon als Abnahmekriterium hatte, dass der
6:36
Code kommentiert ist. Ja also das war so n bisschen
6:39
Coding guideline. Nach dem Motto, Na ja, weil der
6:42
so gut geschriebener Code hat auch immer ne Zeile ne
6:46
Kommentarzeile ne damit du lesen kannst was in dieser Funktion
6:49
passiert und was damit, dass andere Leute andere Entwickler
6:54
auch schnell nachvollziehen können und man schnell
6:56
eintauchen kann in den Code denk ich mir.
7:00
OK, die Ambition hinter dieser Anforderung ist richtig, Code
7:06
soll verständlich sein, Code soll.
7:08
Man soll sich schnell einarbeiten können, man soll ihn
7:10
selbstständig schnell erweitern können.
7:12
Wenn du neu ins Projekt kommst und so weiter ne die Maßnahme
7:16
aber dahinter ist völlig die falsche in meinen Augen und
7:19
deswegen ist das für mich n absolutes No go zu sagen OK dann
7:21
mach halt viele Kommentare ran, das ist jetzt wichtig und vor
7:24
allem wurden meine Tickets damals nicht abgenommen, weil
7:27
ich es nicht gemacht hatte und meine Einstellung dazu und ich
7:31
denke mal die teilst du auch wenn nicht, dann korrigier mich
7:34
gleich. Ist dass der Code also gut
7:36
geschriebener Code sich selbst erklärt ne und wenn eine
7:39
Funktion so unverständlich wird, dann ist sie entweder viel zu
7:43
komplex und zu lang, zum Beispiel ne, dass zu viel
7:46
passiert in dieser Funktion, oder sie ist schlichtweg einfach
7:50
nicht gut programmiert. Ne, das sind halt so Sachen wo
7:54
ich mir denke. Nee, dann schau lieber, ob du
7:57
dein Code refactors als jetzt super viele Kommentare
8:00
ranzumachen und da ich das halt wie gesagt Mal für ja, das Waren
8:03
bestimmt anderthalb, 2 Jahre war ich in dem Projekt, das so
8:06
gesehen hatte, dachte ich mir, boah, nee, da bin ich komplett
8:09
geheilt, das nervt mich, das ist n richtiges no go ich das.
8:12
Mittlerweile sehe also was ich, also ich kann das total
8:15
nachvollziehen, weil ich finde also wie du meintest ne, also
8:18
selbst wenn du. Was bringt dir n Kommentar an
8:21
der Funktion? Wenn die Funktion den richtigen
8:23
Namen hat für das was sie tut? Ne?
8:25
Also du kannst also klar kann man zum Beispiel kann man jetzt
8:29
argumentieren und sagen Na ja, aber da passiert ja vielleicht
8:31
noch n bisschen mehr drin ne also wir haben ja auch ne Reihe
8:33
zum Thema Cleancode gemacht, da auch gerne mal reinhören aber.
8:37
Stimmt, da gab es eine Folge zu dem Thema.
8:39
Genau. Aber weißt du was, was ich, was
8:41
ich also wenn ich mir das anhöre, woran ich denken muss,
8:46
was für mich auch n no go ist, und das gehört auch.
8:48
Unter einem Thema, was für mich n no go ist.
8:52
In einer Projektarbeit mit verschiedenen Rollen.
8:56
Und zwar wenn jetzt, du hast ja gesagt, das war der PM oder der
8:58
PO ne oder so hybride Rolle ne also PPMO keine Ahnung p aber
9:07
was was auf jeden Fall mich auch richtig triggert ist, wenn du
9:10
zum Beispiel so NPM hast beispielsweise der vorschreiben
9:14
möchte. Wie zum Beispiel etwas
9:20
programmiert werden soll oder wie die Guidelines
9:23
beispielsweise sind. Also das finde ich, ist für mich
9:25
auch n absolutes No go, wenn jemand, der nicht in der
9:27
Entwicklung drin ist und jetzt in deinem Beispiel der POMPO wie
9:31
auch immer der gesagt hat, ey, kommentiere bitte jede Zeile,
9:34
ich finde das ist das, also das gehört sich meiner Meinung nach
9:38
nicht zu sagen, also wenn du Außenstehender von einem Projekt
9:41
bist zu sagen, Code bitte so, ich find das ist nicht in
9:45
Ordnung, weil das ist einfach die.
9:48
Hoheit oder die die Angelegenheit des entwickelnden
9:52
Teams was ich meine, das fällt für mich dafür rein, ja zählt
9:58
auch voll da mit rein gehe ich mit na gut, also er ist jetzt
10:02
nicht irgendwie außenstehend vom Projekt, er gehört ja schon zum
10:05
Projekt, aber ich weiß was du meinst.
10:07
Er ist halt seine Verantwortlichkeit, ist ja
10:09
nicht. Die Codebasis zu erstellen und
10:11
zu verwalten, sondern er ist ja höher, nicht hierarchisch an
10:15
also, sondern einfach sag ich mal in der Entwicklungsebene 1
10:18
höher ne und also näherrichtung Kunde sag ich mal auch ne das
10:23
Ding ist damals in dem Projekt war das so, lass uns mal agil
10:29
arbeiten obwohl wir eigentlich noch n total konservatives
10:33
Unternehmen sind oder Projekt nennen wir es mal Projekt ich
10:35
würde es nicht aufs ganze Unternehmen Münzen aber.
10:38
Das Team und das Projekt war sehr konservativ und man hat
10:41
versucht, agil zu arbeiten und hat dann halt eher diese Rollen.
10:45
Ich sag es mal böse missbraucht ne um ne Art Tracking dann auch
10:49
durchzuführen, ne durch den PO zum Beispiel und diese
10:53
Guidelines waren quasi so im Projekt festgelegt worden und
10:59
klar wurde das dann nur durchgesetzt sag ich mal.
11:02
Aber das ist natürlich völlig der falsche Weg.
11:03
Also da bin ich ganz bei dir, dass das n absolutes No go ist.
11:06
Ich möchte Kommentare ja auch an der Stelle nicht komplett
11:08
verteufeln. Es gibt ja auch Fälle, wo die
11:11
für mich ein absoluter Segen sind.
11:14
Ja, wenn du zum Beispiel in ne n Code reinguckst oder n Projekt
11:18
wo du ganz neu bist und dann sind da zum Beispiel sehr
11:21
komplexe Algorithmen, schwierige Berechnungen oder auch
11:25
irgendwelche Parameter, die gesetzt werden Konstanten.
11:29
Die nicht selbsterklärend sind, wo du, weil du nicht weißt wo
11:32
kommt dieser Wert her, dann ist n Kommentar natürlich absolut
11:35
super, ja, dass da dran steht hier pass auf, dieser Parameter
11:38
wird so und so kalibriert sag ich mal oder eingestellt der
11:41
Wert meinen wir irgendein Flow wert ne wo den du dir niemals
11:44
herleiten könntest alleine so aus aus dem Code heraus, da
11:47
macht das ja natürlich absolut Sinn aber zu sagen keine Ahnung
11:52
und jetzt returne ich den Wert und mach da n Kommentar darüber
11:55
denk ich mir so willst du mich verarschen?
11:59
Aber soweit ist das da teilweise gegangen.
12:02
Aber also ich verstehe den, also den den Hintergrund dahinter
12:05
verstehen. Ich war es einfach aus Prinzip,
12:07
wollte diese Person gerne den Code verstehen, hat ihm das
12:12
geholfen den Code zu verstehen, musste er den Code verstehen,
12:15
also das ist ja für mich jetzt gerade interessant, weil ich mir
12:17
denke so einfach nur zu sagen Kommentier bitte jede Zeile, das
12:20
ist für mich halt, das ist ja schon Behinderung bei der
12:24
Arbeit. Es es wirkte eher wie wir müssen
12:29
ganz sauber Software entwickeln und dabei schieße ich übers Ziel
12:34
hinaus, indem ich mir denke, OK, dann gehören so Kommentare dazu,
12:37
damit der Code so richtig eindeutig und sauber ist.
12:40
Aber er bläht den Code ja am Ende einfach nur auf so n
12:43
Kommentar weil gefühlt hast du ja jede Zeile doppelt.
12:47
Wenn ne gutgeschriebene Zeile braucht, kein Kommentar, außer
12:50
die Ausnahmen, die ich gerade genannt hab.
12:52
Also verdoppel ich eigentlich nur die Anzahl der Zeilen und
12:54
hab keinen Mehrwert in meiner Sicht, im Gegenteil, es ist aus
12:58
meiner Sicht, das kannst du gleich mal sagen, wie du das
13:00
siehst. Aber ist es auch schwieriger
13:02
lesbar, wenn ich jetzt immer Kommentare dazwischen hab, die
13:04
ja auch anders geheihlightet werden in der IDI, dann liest
13:07
sich der Code einfach schwieriger für mich.
13:09
Ja, definitiv. Also geh ich total mit.
13:11
Aber genau das ist ja zum Beispiel auch das, was ich
13:13
absolut, sag ich jetzt mal auch. Als Trigger empfinde weil im
13:20
Endeffekt, sagt er. Also diese Person sagt, wir
13:22
wollen richtig sauber Software entwickeln und hat aber
13:25
offensichtlich keine Ahnung davon, wie saubere
13:27
Softwareentwicklung funktioniert und das ist seine Maßnahme
13:30
dafür. Dann denk ich mir so, wenn du,
13:31
ich sag es jetzt böse, keine Ahnung davon hast, dann lass es
13:34
bitte einfach weißt du das mein ich du kannst ihn nicht
13:36
hinstellen und sagen so wird gecoded weil das ist sauber und
13:40
wenn du aber quasi der Fachmann ne bist und sagst nee so es ist
13:43
nicht so und die Person sagt aber wir machen es jetzt so dann
13:46
das Trigger. Mich total.
13:47
Das ist für mich ein absolutes No go sich hinzustellen und zu
13:50
sagen, OK, pass auf, wir machen es so, obwohl man keine Ahnung
13:52
davon hat, finde ich schlimm, weißt du was ich meine und das
13:54
fällt für mich also der Punkt zu sagen überall Kommentare ran
13:58
oder exorbitant viele Kommentare in den Code ist für mich auch
14:00
ein No go, aber das ist für mich noch das übergeordnete No go was
14:04
auf jeden Fall gar nicht geht finde ich also quasi.
14:07
Überstimmt zu werden, obwohl es deine Verantwortung ist.
14:11
Die Codebasis. Ja, bei mir geht das ja schon
14:13
los. Also wenn jetzt zum Beispiel.
14:15
Es es ist n schmaler Grat, ne, also manchmal kann man ja zum
14:17
Beispiel so über bestimmte Stories reden und ich hatte das
14:20
auch mal, dass man so Stories hatte, über die man gesprochen
14:23
hat, ne also die implementiert werden soll und dann also bist.
14:27
Jetzt ne agilen Story. Du erzählst jetzt keine Story,
14:29
sondern hast ne Story, die du bearbeitet hast.
14:31
Ja ja genau, ja eigentlich. Ich war gerade verwirrt.
14:33
Sorry, sorry, nein, einen task ne.
14:34
Also du bearbeitest einen Task und du du redest über diesen
14:37
Task im Vorfeld. Also du schätzt sozusagen du
14:39
machst. Machst im klassischen machst du
14:41
n refinement ne, du guckst OK wie wie was muss in dieser Story
14:46
gemacht werden? Ne in dieser in diesem Task und
14:49
dann kommt zum Beispiel der PO oder der PM NE und sagt ja das
14:52
und das eigentlich muss man doch nur das und das machen oder ich
14:55
würd da wahrscheinlich das und das verwenden, also quasi auf
14:59
implementierungsebene runterzugehen um sozusagen nen
15:02
Vorschlag zu machen wie man es machen könnte.
15:05
Triggert mich total. Ist jetzt nicht unbedingt n
15:07
absolutes No go, weil wie ich mein das ist n schmaler Grad
15:10
zwischen OK es kann ne Hilfe sein als Gedankenanregung, aber
15:14
in dem Fall was ich gerade meinte war das für mich einfach
15:17
nur n absoluter Trigger weil die Person die das gemacht hat, die
15:20
hat immer einfach immer nur gesagt so ja ich würd es so und
15:23
so machen aber so und so wär einfacher so und so wär besser
15:26
also gerade wenn du auch zum Beispiel n Entwickler also ne
15:29
spricht des Entwicklerteams und dann so ja ich würd es aber
15:31
wieso nicht so das ist doch viel einfacher und dann denk ich mir
15:33
so. Mal ganz ruhig bleiben also da
15:37
red ich mit mir selbst, weil im Endeffekt denk ich mir so, es
15:41
kann ja nicht sein. Also du hast Rollen im Team, ne
15:44
und wenn du rollen im Team hast, dann kümmert sich jeder um seine
15:46
Verantwortlichkeit und man kann diskutieren, aber das war halt
15:50
für mich so richtig so ja aber mach es so ist besser und ich
15:53
denk mir so was also das wär so als würde ich zu einem Arzt
15:56
hingehen und sagen ja schneid nicht das Durchschneid das durch
15:58
es besser bei einer OP. K also durchschneiden klingt
16:03
erstmal überhaupt nicht gut aus. Ja, aber ja, OKOK machen wir,
16:08
machen wir n harmloses Beispiel. Du kriegst irgendwelche
16:11
Medikamente verschrieben und du sagst, nee, gib mir mal die, die
16:14
knallen mich ab. Ja.
16:18
OK, gut, aber ich verstehe, ich hab den Punkt verstanden und ich
16:22
bin da auf jeden Fall ganz bei dir, weil wie gesagt jeder hat
16:25
seine Verantwortlichkeiten und seine Expertise in seiner Rolle
16:28
die er hoffentlich hat für die Rolle ne logischerweise und ich
16:32
denke, dass gerade ein Po pm. Sagen wir mal abseits vom
16:37
Entwicklerteam andere Dinge zu tun hat, als sich zu überlegen,
16:41
wie das zu implementieren ist. Ne.
16:44
Zumal das die Vorschläge, wie wie du ja meinst, es können gute
16:46
Vorschläge sein, keine Frage, ne, das will man ja nicht
16:49
abstreiten, aber Fakt ist, dass diese Person ja auch nicht so
16:52
tief in dem Projekt auf Code Ebene drin stecken.
16:58
Um jede Aspekt, jeden Aspekt quasi berücksichtigen zu können.
17:02
Und dann so n schnellen Vorschlag zu machen und mit der
17:06
mit der Annahme sag ich mal, dass das ja schon das Beste sei
17:09
und das einfachste und so müsste man es machen.
17:11
Ist halt auch gewagt an der Stelle.
17:13
Ja als so ne Aussage zu treffen. Ja ja ich meine jeder hat ja
17:17
seine Verantwortlichkeit, das ist ja auch richtig so und seine
17:21
Expertise und. Man kann drüber reden, aber
17:24
Anweisung zu geben sag ich jetzt mal, das ist für mich fällt halt
17:29
untergeht nicht. Ja, ja doch, geh ich mit ist ist
17:33
n guter Punkt als No go. Ja was fällt mir noch so ein,
17:39
ich glaub n Klassiker und das ist jetzt auch gerade Leute die
17:43
uns schon länger verfolgen oder den Podcast hören das ist denk
17:46
ich mal irgendwie selbsterklärend, ich möchte ihn
17:48
trotzdem mal kurz nennen. No go.
17:51
Für mich ist keine Tests zu haben.
17:54
Ja, also das ist für mich n no go.
17:56
Ich wusste, das kommt jetzt. Aber auch, weil es hart, also
18:02
hart lernen musste über die Jahre, über die Projekte, die
18:05
ich gemacht hab, weil ich einfach beides erlebt hab, so
18:09
Projekte, wo es keine Tests gab, die man versucht hat, so lange
18:12
wie möglich zu tragen, bis es irgendwie implodiert ist, man
18:14
sich dachte, jetzt müssen wir doch mal Tests nachziehen, und
18:16
das ist n riesen pain, ich glaub das haben wir schon so oft
18:19
besprochen. Bis hinzu Projekten, die
18:23
komplett testdrivend entwickelt wurden und die mir einfach so
18:26
viel mehr confidence am Ende vertrauen in meine Software
18:31
gegeben haben, dass ich einfach ja nie wieder zurück möchte, sag
18:34
ich mal ne, also das ist für mich n absolutes No go, wenn ich
18:37
in n Projekt kommen würde, wo es heißt ja hier kommt n Test.
18:41
Wir haben es, wir haben es manuell getestet, das läuft ist
18:43
in Ordnung. Direkt wieder umdrehen.
18:46
Dann würde ich Leute alles klar, kann man mich versetzen.
18:50
Ich möchte woanders hin, das wäre so geil.
18:52
Kommst rein, moin, was machen wir heute ja an dem Projekt hier
18:55
arbeiten hat aber keine Tests, wir machen das so und so, ich
18:58
verabschiede. Mich auch so und damit gehe ich
19:01
auch schon direkt in den Urlaub. Macht's gut Leute, hey keine
19:05
Ahnung möchte ich glaube ich wieder lieber freiwillig
19:07
powerpoints machen. Ja, aber das geht ja.
19:11
Also, das geht wirklich nicht. Ich habe, wie gesagt, ich habe
19:14
auch lange ohne Tests gearbeitet, haben wir ja auch im
19:17
Studium, hatten wir auch schon drüber gesprochen, auch gar
19:19
nicht so gehabt und gar nicht so gelernt, wir sind also quasi
19:22
nicht damit aufgewachsen, ja. Das ist eine schöne
19:25
Formulierung. Aber wenn du es einmal hast,
19:29
dann willst du es auch nicht mehr missen.
19:31
Also das ist so, wie wenn du weiß, ich nicht.
19:34
Sagst, du hast noch nie Süßigkeiten gegessen und dann
19:37
probierst du mal eine und denkst dir so, nein, ist jetzt doch
19:40
nicht so Scheiße. Eigentlich ganz geil.
19:42
Das ist eigentlich ganz geil, aber es ist kein gutes Fall für
19:46
Süßigkeiten. Ja, grundsätzlich nicht gut
19:48
sind, aber Tests sind grundsätzlich gut, aber ich weiß
19:50
was du meinst. Ich wollte mit nicht wissen,
19:53
aber ja, Süßigkeiten sind ungesund, Leute, esst keine
19:57
Süßigkeiten, niemals, ich hab keine veralte Süßigkeiten.
20:03
Was aber pass auf, was ich interessant finde oder was was
20:06
ich also pass auf ich fang nochmal an was ich richtig zum
20:10
Kotzen finde, weil ich möchte das gerne bisschen übertreiben
20:17
wenn du stell dir vor du gehst in ne Codebase rein und du
20:20
klickst dich so n bisschen durch und versuchst irgendwas zu
20:22
verstehen in dieser Codebase ne und dann kommst du triffst du
20:26
auf n Pfeil und du fängst an dir dieses Pfeil anzugucken.
20:31
Scrollst und Scrollst. Ja, du merkst irgendwann, warte
20:35
mal irgendwie, ich scroll hier ganz schön lange und guckst auf
20:37
den Balken und der ist übelst klein und da ist noch ganz viel
20:39
Platz nach unten und dann denkst du dir so OK und du scrollst
20:43
nach unten, hast dann irgendwie 2002 1000 3000 was auch immer
20:46
zeilencode kriegst. Schon Krämpfe in der Hand, so
20:50
vom Scrollen. Ja, du weißt nicht, ob du es bis
20:52
nach unten schaffst. Wenn ich das sehe.
20:55
Könnte ich wirklich, könnte ich kotzen, weil es ist.
20:58
Ich finde n absolutes No go. N absolut riesen Spaghetticode
21:02
dahin zu ballern oder zu sagen ich hab n Pfeil was mehrere 1000
21:06
Zeilen lang ist. Einfach weil für mich ist das n
21:10
Anzeichen von ich hab gar keinen Bock gehabt mich darüber mal.
21:14
Also mir darüber Gedanken zu machen, wofür dieses File oder
21:17
für was diese einzelnen Parts, weil offensichtlich es kann
21:20
einfach nicht anders sein, da einzelne Parts drin sind, die
21:23
man vielleicht auseinander ziehen kann.
21:24
Also da, das ist für mich Softwareentwicklung, wo sich
21:27
irgendjemand denkt so keine Ahnung, ich schreib einfach
21:29
alles rein, passt schon, aber keinen Bock gehabt sich darüber
21:32
irgendwie zu Gedanken zu machen, was im Endeffekt da eigentlich
21:38
passieren soll. Ja, das ist n spannender Punkt,
21:42
weil da gehe ich auch mit, weil das ist noch so n no go, was mir
21:45
durch den Kopf geistert, Leute die so refactoring resistent
21:49
sind oder Projekte Münzen, was man nicht unbedingt auf ein um
21:53
auf eine Person, weil es oft auch projektgetrieben ist, dass
21:58
man refactoring resistent ist oder sein muss.
22:02
Weil das ist n großes Anzeichen dafür.
22:04
Ne, wenn ich so lange files hab frag ich mich warum niemand auf
22:06
die Idee kommt wie du ja meintest das mal zu refectern
22:09
oder mal auseinander zu ziehen ne also wirklich mal an der
22:13
Qualität des vorhandenen Codes zu arbeiten und wie oft hab ich
22:17
in Projekten gearbeitet, was heißt ja haben wir keine Zeit
22:20
für. Ja, aber wir müssten wirklich
22:22
mal das aufräumen. Nee, wirklich, ey, ja,
22:25
vielleicht nächsten machen wir nächsten Sprint, aber diesen
22:27
Sprint sind wir schon wieder völlig überplant, das ist auch
22:29
so n no go, aber egal. Deshalb brauchen wir nicht drauf
22:32
eingehen, ne wir wollen ja die unsere großen No Gos mal
22:36
herausstellen. Und das da geh ich mit.
22:39
Also dieses keine Zeit zu refact, dann weiß ich schon OK
22:43
wie lange macht ihr das schon, wie lange entwickelt ihr 3
22:46
Monate, wie lange soll ja OK ein 2 Jahre alles klar Vergesst es
22:51
so weißt du also das klingt jetzt n bisschen herabwürdigend,
22:54
so ist es, ist ja jetzt n bisschen überspitzt dargestellt
22:56
ne aber Fakt ist wenn du von Anfang an dir keine Zeit dafür
23:01
nimmst und dann irgendwann sagst ja wenn wenn alle Features drin
23:04
sind. Dann refect dann war.
23:06
Dann hast du schon so viele Entscheidungen getroffen,
23:09
basierend auf einer vielleicht schlechten Softwarearchitektur.
23:13
Ein Beispiel, wann man refect, dann müsste ne oder du baust auf
23:16
jeden Fall auf nicht optimalen Code auf.
23:19
Was ist schon optimal? Mag sich jetzt der ein oder
23:21
andere denken, ja, aber du versuchst ja so optimal wie
23:24
möglich deinen Code zu gestalten.
23:27
Oh, das wird definitiv nicht der Fall sein.
23:29
Wenn du monatelang entwickelst, ohne einmal zu refactern.
23:32
Ja, ich meine, du kannst dich hinstellen und sagen, also ne,
23:34
ich find das ist immer n geiles Argument zu sagen mach es doch
23:38
einfach gleich richtig haben wir auch schon paar mal drüber
23:40
gesprochen aber ja das funktioniert so nicht.
23:42
Wenn es so einfach. Wäre das funktioniert so nicht.
23:45
Das ist halt einfach nicht die Realität, wenn es so einfach
23:49
wäre, dann wären alle Produkte, die es auf dieser Welt gibt,
23:52
perfekt. Da müsstest du niemals irgendwas
23:54
neues auf diese Welt packen. Wenn du sagst, mach es doch
23:57
einfach perfekt. Genauso ist es mit Code ne wenn
23:59
du sagst du entwickelst Code ja du klar du lernst dazu ist
24:03
logisch, du wirst heute besseren Code schreiben als vor 3 Jahren
24:06
im Normalfall ja das ist einfach Fakt klar du verbesserst dich ja
24:11
aber über die Zeit und dann genau dieses über die Zeit
24:15
bedeutet irgendwann kannst du Code wieder refactern
24:18
Anforderungen verändern sich vielleicht und dann kann man das
24:20
machen und ich find es auch absolut schlimm.
24:23
Wenn du wenn irgendwie ne Einstellung herrscht, mach das
24:26
einfach erstmal nicht. Wir haben keine Zeit, geh ich
24:28
total mit. Ich find auch weil du meintest
24:30
so ja wir refact dann später. Also es gibt ich find Pendant
24:33
dazu ist wenn man sagt wir testen unsere Software wenn sie
24:37
fertig ist wo ich mir ganz ehrlich denke.
24:40
Macht ihr nicht. Erstens, erstens macht ihr
24:43
nichts, zweitens brauchst du gar nicht, wenn deine Software
24:45
fertig ist. Warum willst du sie dann auch
24:46
testen? Ist doch scheißegal so, du hast
24:48
wahrscheinlich schon so viel gelitten bis dahin, ja bis deine
24:51
Software fertig ist. Wenn du es schaffst, sie fertig
24:54
zu kriegen, ja, da kommt dann, dann ist sie fertig.
24:56
Lass brauchst du nicht mehr machen so ne und das ist ja
24:59
genau das gleiche so wenn deine Software fertig ist, dann
25:01
anzufangen zu refact, dann lass sein Alter, dann ist sie fertig,
25:04
so weißt du wenn du von. Fertig reden, abgehakt, das
25:06
nächste, nächstes Mal war es besser.
25:09
Aber dann braucht man sich halt auch nicht wundern, wieso man
25:11
keine Ahnung auf dem Weg bis zur bis zu fertig in
25:15
Anführungsstrichen ne, weil was ist schon fertig aber einfach.
25:19
Permanent nur durch die Hölle geht ne.
25:20
Also das ist ich übertreibe jetzt extra.
25:23
Ja, es muss nicht immer so sein, aber ich find es auch ganz ganz
25:27
schlimm wenn man nicht damit, also nicht mit Refactoring quasi
25:34
von vornherein einplant und ich hatte so n so ne sowas
25:37
tatsächlich auch schon mal. Da hab ich mich auch mit nem PM
25:39
unterhalten und hab ich glaub das waren so ich hab ein 2
25:44
Wochen oder so mit zusammen im Pair ne haben wir.
25:46
Ne ganze Komponente komplett refactod, weil wir gemerkt
25:49
haben, wir haben also wir haben ne Aufgabe daran erledigt ne ne
25:52
Story n Task und haben gemerkt das ist richtig scheiße wir also
25:57
wir haben uns das angeguckt und haben nicht verstanden wie das
26:00
funktioniert beziehungsweise dieser Code das der war das war
26:02
einfach das war alles durcheinander und wir haben uns.
26:05
Dabei keine Kommentare dran waren.
26:06
Ja, wenn jederzeit n Kommentar dran gewesen wär, dann wär dann
26:10
wär perfekt. Die Tests haben auch genervt
26:15
dabei und. Ja.
26:17
Nein. Und wir haben natürlich auch
26:18
nicht auf den PM gehört. Ne der der eigentlich die
26:20
Implementierungsvorschläge gemacht hat, nein, aber also wir
26:24
haben uns das anguckt und haben es, wir haben nicht verstanden
26:26
wie das funktioniert, also es hat sehr lange gedauert ne bis
26:29
man irgendwie verstanden hat, OK so funktioniert das, also das
26:32
ist quasi die Intention dahinter und haben uns das angeguckt und
26:36
dachten uns so, es ist doch eigentlich viel einfacher zu
26:38
lösen als das was wie es da gelöst ist.
26:41
Also haben wir gesagt, OK, wir müssen das Refact dann und sind
26:43
dann beim Refact dann darauf gekommen.
26:44
OK, du kannst die Strukturen noch n bisschen umstellen, dies
26:46
und das und das und dabei muss man ja auch sagen, ey, es ging
26:49
um eine Komponente, die halt auch genutzt wird, die
26:51
regelmäßig angefasst wird, die regelmäßig gewartet werden muss
26:55
oder erweitert werden muss oder was auch immer ne war wichtig so
26:57
und der PM hat dann wirklich Ewigkeiten diskutiert mein ich
27:01
so ey ihr seid jetzt schon ne Woche da dran das zu refact dann
27:03
es kann doch nicht sein so nach dem Motto ne das ist doch nicht
27:06
wert so und wir so Alter das ist es auf jeden Fall wert also.
27:10
Das war so n bisschen so ne Diskussion im Sinne von na ja,
27:12
aber bis es dann irgendwann genau dahin ging zu sagen, ja,
27:16
aber du willst mir ja nicht erzählen, wenn du jetzt von
27:18
vorne anfängst neue Software zu entwickeln, dass du dann direkt
27:21
quasi refactoring einplanst und ich dachte mir so genau das will
27:26
ich dir hier erzählen. Genau das ist die Realität, es
27:30
ist auch einfach so. Ja es war hart, das sind das
27:35
sind das sind harte Sachen. Aber am Ende durftet ihr das
27:39
machen und es hat sich ja wahrscheinlich auch ausgezahlt,
27:41
oder? Na, ich muss sagen, es war auf
27:42
jeden Fall schon so, dass eigentlich war so, nee, macht
27:45
das nicht mehr weiter und wir es trotzdem einfach weiter gemacht
27:48
haben. OK, also ihr habt es denn noch
27:50
am Ende durchgezogen, sag ich mal.
27:52
Ja, weil da dachte ich mir so, es kann nicht, darf nicht sein,
27:57
weil am Ende hast du ja auch die Verantwortung über den Code, ne,
28:01
was für mich übrigens auch n no go ist.
28:02
Um mal sowas wie refactoring, keine Tests.
28:06
Beispielsweise zusammenzufassen. Es ist deine Verantwortung für
28:10
diesen Code und der muss halt zum also der da muss man sich
28:14
wohlfühlen können, der muss halt gut sein, das ist halt die
28:16
Verantwortung, wenn du keine Verantwortung als Entwickler
28:18
oder Entwicklerin für Deine eigene Software übernehmen
28:20
möchtest, ist das für mich auch n absolutes No go.
28:23
Ja, das ist, das ist gut zusammengefasst und oder alle
28:27
Punkte, die wir jetzt so hatten, weil es ja das ist essenziell,
28:32
dass man sich verantwortlich fühlt dafür, ne, also es ist
28:34
irgendwo dein Produkt, auch wenn man.
28:36
Sag ich mal. Es ist ja für den Endanwender
28:39
ne, das muss man sich ja auch mal vor Augen halten.
28:41
Natürlich nicht ersichtlich ne wie der Code da drunter
28:44
aussieht, der kriegt ja den Source Code jetzt nicht
28:46
ausgeliefert und denkt sich Oh Mensch oh schlecht so ja oh guck
28:49
mal Tests, aber es ist ja trotzdem muss es ja in deiner
28:54
Verantwortung liegen oder dein Bewusstsein so sein zu sagen ich
28:58
bin aber verantwortlich und ich möchte, dass es bestmöglich ist.
29:01
Es kann auf mehreren Arten funktionieren, das gewünschte
29:04
Feature. Aber es muss ja schon dein
29:06
Interesse sein, dass es sehr gut umgesetzt ist, dass es gut
29:10
erweiterbar ist, wartbar ist und so weiter ne, das muss einfach
29:14
deine Intention sein, dahinter ich mein n Handwerker denkt sich
29:17
auch nicht, ja wird schon wird schon halten.
29:21
Die Mauer, die ich da hochgezogen hab, ja, ist
29:23
vielleicht jetzt nicht so geil und innen drin hab ich
29:25
gepfuscht, aber sieht keiner so ne tritt aber nicht, dass es das
29:28
gibt, sollte aber nicht die Einstellung sein, Tritt aber
29:31
nicht gehen, genau die Mauer. Steht aber Fass sie nicht an,
29:35
niemals n Bild in diese Mauer. Aber weißt du, das ist ja
29:41
eigentlich ne gute Analogie. Das sollte doch auch nicht das
29:43
Bestreben sein. Genauso ist es auch bei
29:45
Softwareentwicklerinnen und Entwicklern, also.
29:47
Ich meine ich jeder kennt das ne.
29:49
Man denkt sich so, woah, ich hab da jetzt echt gerade keinen Bock
29:51
drauf ne und manchmal denkt man sich auch komm ganz ehrlich der
29:55
Test passt schon so ne also man könnte das noch abbrechen
29:58
natürlich aber muss jetzt nicht unbedingt sein oder hab ich
30:02
gerade keinen Bock drauf? Ne da muss man sich vielleicht
30:04
eher noch mal fragen. OK, ist es in Ordnung wenn du
30:07
sagst, so ja ist in Ordnung, meine mein Vertrauen in diese
30:10
Software ist in Ordnung passt noch ich mach grad vielleicht so
30:14
n kleinen ja wie nenn ich das Flüchtigkeitsfehler will ich das
30:18
jetzt einfach mal so nennen oder ne weiß ich nicht so n bisschen
30:21
ne kleine Nachlässigkeit aber wenn du dir denkst so ja komm
30:24
daran wird jetzt meine Software nicht sterben oder da wenn jetzt
30:27
irgendwie was auftritt das wird nicht daran auftreten so ne
30:30
angenommen dann ist es in Ordnung finde ich.
30:34
Aber wenn du dir denkst, so ist schon ne kritische Nummer.
30:37
Hab ich aber gerade keinen Bock drauf, dann muss man sich denken
30:40
so na ja, aber willst du dich jetzt drauf verlassen können auf
30:43
deine Tests und so weiter und auf deine Software.
30:45
Oder nicht so ne, dann es ist natürlich auch der Punkt, warum
30:49
hab ich jetzt gerade keinen Bock drauf, also wahrscheinlich wird
30:53
es ja anstrengend sein dann das zu testen.
30:54
Ne, dass man sich so denkt jetzt dann ist halt die Frage ob es
30:58
nicht vielleicht sinnvoll ist vielleicht mal 5 Minuten
31:00
Kaffeepause zu machen, mal kurz. Kopf aus ne mal so n bisschen
31:05
entspannen sag ich mal. Und dann das Thema angehen
31:07
anstatt immer mehr technische Schultern am Ende wieder
31:10
aufzubauen. Weil das ist auch so der
31:11
Oberbegriff den man da zupacken kann, weil es wird irgendwann
31:14
dir auf die Füße fallen, halt ne.
31:16
Ja, ich mein, Es ist natürlich immer einfach gesagt.
31:20
Es gibt natürlich immer mal Momente, wo man sich vielleicht
31:23
denkt, so, man könnte es so machen, aber die Struktur ist
31:27
aktuell schon so, es wär viel einfacher, es so zu machen.
31:30
Es wär viel schneller so zu machen, also weißt du, manchmal
31:32
geht man natürlich den einfachen Weg, aber man muss halt damit am
31:36
Ende leben können, weil ich hab beides auch schon gemacht, so
31:38
dass man sich so denkt. So, ja ich mach das jetzt, pass
31:40
so ne oder wir müssen das jetzt umbauen, es geht nicht anders,
31:44
auch wenn ich keinen Bock drauf hab, kann auch mal passieren ne.
31:47
Na sagen wir mal so, diese Schmerzgrenze, wo man sagt, nee,
31:51
ey, wir müssen das jetzt umbauen, die muss halt.
31:53
Hoffentlich schnell erreicht sein, dass man nicht sagt, also
31:55
Schmerzresistent sein ist in dem Fall halt nichts Gutes, wenn man
31:58
sagt, ja nee komm, wir ziehen es noch durch, wir bringen das noch
32:01
so ins Ziel, so mit der Art und Weise wie es jetzt ist, ne weil
32:04
Fakt ist, da sind zwar no gos für uns.
32:08
Aber es muss auch jedem klar sein, dass man immer wieder sich
32:11
selbst oder selbst gechallenged wird davon, egal wie lange du
32:15
entwickelst. Ich kann mir nicht vorstellen,
32:17
dass es Entwicklerinnen und Entwickler gibt, meinetwegen mit
32:20
2030 Jahren Berufserfahrung, also noch um einiges mehr als
32:23
wir, ne beide jetzt, dass sie sich denken, nee sorry, aber das
32:27
passiert mir nicht mehr, es wird es gibt immer n Test.
32:30
Ich will Check da immer direkt das Feature und wenn ich das
32:34
Gefühl hab ich kann es besser machen mach ich es sofort.
32:38
Also wenn ja, dann cool, dann kommen wir da auch noch hin.
32:41
Wird geil, aber ich sag mal so, man ist irgendwie eigentlich in
32:46
einem Zustand wo man weiß was der richtige Weg ist.
32:49
Aber immer wieder diese Versuchung spürt zu sagen, Ach
32:52
komm, nächstes mal, was du ja auch meintest, das ist ja.
32:55
Das ist ja ständig ne Challenge an sich selbst, ne und man muss
32:59
halt einfach sich immer wieder besinnen da drauf, dass es dir
33:02
irgendwann auf die Füße fallen wird.
33:04
Also mach es jetzt, das ist für mich persönlich die beste Art
33:07
und Weise damit umzugehen, halt ne.
33:08
Ja, aber wie gesagt, es ist halt weil, weil wir ja gesagt haben,
33:12
es ist n no go, finde ich ja auch, dass wenn man sich nicht
33:16
quasi, wenn man sich nicht um die Verantwortung des eigenen
33:18
Codes bewusst ist und einfach, ich sag mal salopp drauf
33:21
scheißt, so ist n no go. Dass man es immer zu
33:24
hundertprozentig richtig macht, ne, das ist halt, das geht eh
33:28
nicht, ne aber wenn du das richtige Mindset hast zu sagen,
33:30
OK der Code dafür bin ich verantwortlich, dann bist du auf
33:33
dem richtigen Weg, dann ist gut, dann ist es schon kein No go
33:36
mehr, auch wenn du mal sagst ha heute mal nicht ne, du hast
33:40
immer auch n Tag wo du sagst heute mal nicht heute ist nicht
33:42
so geil so fertig ne und dann hast du wieder n Tag wo du sagst
33:45
Angriff richtig Bock jetzt geht es los ne und genauso ist es
33:48
auch aber wenn du permanent sagst alles scheißegal mir
33:52
Wurst, so weißt du typisches Teenagerverhalten wie man es von
33:56
sich selber früher kennt cool so ne eine Sache hab ich noch im
34:03
Kopf die ich auch noch ganz kurz loswerden will, ich weiß nicht
34:06
wie es bei dir ist. Es geht um Code Reviews und zwar
34:11
wenn du sagst du also ne du irgendjemand committed was und
34:15
du sollst es reviewen find ich ist n absolutes no go wenn.
34:20
In diesem also erstmal, wenn der gesamte Commit ne, also der der
34:27
Umfang die Changes zu krass sind zu viel.
34:30
Also wenn du jetzt wirklich sagst, du hast weiß nicht 200
34:34
200 Files und 1000 Zeilen da geändert und musst das alles
34:37
durchgucken haben wir auch mal ne Folge gemacht über Code
34:40
Reviews beziehungsweise wie man das halt auch aus unserer Sicht
34:45
gut machen kann. Aber wenn da jetzt so viele
34:49
Changes drin sind, dann ist es für mich n no go.
34:51
Also wenn ich NNN pur request Stelle, versuche ich schon, dass
34:55
es nen gewissen Kontext hat, nicht zu viel beinhaltet und was
35:03
auf jeden Fall richtig kacke ist ist wenn du zum Beispiel sagst
35:05
du machst n Feature ne oder n Teil Feature und nebenbei
35:12
layoutest du alles noch mal neu. Weißt du so, so typischer
35:15
Shortcut, so autoformat Autoformat autoformat, weißt du,
35:19
und dann kommst du halt an n Punkt, wo du dein Code, also wo
35:23
du das im Code Review überhaupt nicht mehr weißt.
35:26
Also sagen wir mal, du hast übelst viel und dann hast du
35:29
immer n file wo du sagst, Oh hier ist wieder Logik, das muss
35:32
ich wirklich checken, passt das so, dann arbeitest du dich da
35:34
rein, dann kommen erstmal wieder 20 Files wo einfach nur
35:37
autolayout ist. So und dann innerhalb von einem
35:39
Autolayout hast du vielleicht irgendwo noch.
35:41
Nen wirklich ne Änderung die wichtig ist, die du aber
35:44
übersiehst, so weißt du, das ist auch so n Ding wo ich mir denke
35:47
so OK da also wenn du jetzt zum Beispiel wirklich committest mit
35:51
einem Code Review, dann ist es wichtig, dass es n gewissen
35:53
Scope hat und nicht alles mögliche rein.
35:55
Also sowas wie autolayout würd ich dann einfach in n anderen
35:57
commit ballern. Weißt du, dass man halt
35:59
zumindest sagt, OK das ist n autolayout commit ne, dass du
36:02
dann siehst ja OK pass auf wenn ich mir jetzt den Pull request
36:06
aus x. Commits angucke, dann brauche
36:09
ich mir diesen einen Commit nicht anzugucken, weil das ist
36:11
halt einfach nur Auto layout. Weißt du, dann kannst du das
36:14
schon mal weg so. Ja, es ist schwierig.
36:18
Also ich gehe auf jeden Fall mit zu große Reviews sind einfach
36:21
kontraproduktiv, weil die Wahrscheinlichkeit einfach
36:23
drastisch steigt, dass du Sachen Übersiehst.
36:27
Da bin ich ganz bei dir. Zu viele Changes in Files oder
36:32
zu viel Files da, da blickt einfach keiner mehr durch.
36:34
Dann hat man irgendwann keinen Bock mehr, ist genervt und dann
36:36
rutscht halt rutschen halt Sachen durch.
36:39
Das mit dem Autoformat finde ich es schwierig, weil ich weiß
36:43
nicht wie es bei dir ist. Bei mir ist es so, dass diese
36:47
Shortcuts so richtig automatisiert sind und ich die
36:52
instinktiv ausführe, also ich bei mir ist das manchmal so, ich
36:56
schreib oder ziemlich oft, ich schreib code.
36:59
Und Merk gar nicht, wie ich diese Shortcut sozusagen Abfeuer
37:02
für Autoformatierung und so, das heißt Autoformat wird sehr
37:07
wahrscheinlich bei mir eh in jedem Commit sozusagen drin
37:11
sein. Ne also ich ich kann jetzt nicht
37:14
irgendwas n Feature implementieren und ich lös das
37:17
nicht aus und committe das und committe dann erst sag ich jetzt
37:22
autoformat. Das Problem, also das Problem
37:25
ist ja sehr tiefgründig dabei beziehungsweise es ist einfach
37:27
zu lösen, aber es ist ne andere Stelle wo das Problem ist.
37:30
Wie kann es sein, dass die Autoformatierung sich
37:33
unterscheidet von dem die bisher committed haben?
37:35
Weil ich muss ja irgendwie, und das finde ich es super wichtig,
37:38
wenn ich gemeinsam an einem Projekt arbeite, dann muss es
37:42
die gleichen, dann muss es einfach Vorgaben geben, wie das
37:45
auszusehen hat. Und dementsprechend muss ich
37:47
meine Autoformatierung einstellen.
37:49
Muss der Linda eingestellt sein, wie auch immer ne, also dass
37:52
sowas gar nicht passiert und das geht schon los bei Darstellung
37:56
von Zeilenumbrüchen oder sowas ne oder zeilenendings
38:00
lineendings zeilenendings schön englisch ne also also da bin ich
38:05
ganz bei dir, wenn sowas überall review drin ist, vergiss es, da
38:09
kannst du, da kannst du gleich sagen hier kommt was soll ich da
38:11
reviewen. Also ich mein wir also.
38:13
Wenn du an deinen Files arbeitest und an dir halt auch
38:16
dazugehören, so, dann ist es in Ordnung, weil dann bist du eh im
38:18
im Kontext drin. So dann dann gehst du da rüber
38:21
und siehst, OK, das sind hier die Changes da das musst du was
38:23
wahrscheinlich machen, aber wenn du jetzt sagen wir mal also das
38:26
hab ich auch schon erlebt und da ist man ist ja schnell in der
38:29
Versuchung angenommen, also erstmal klar definitiv, wenn du
38:32
so bestimmte Regeln hast oder Automatisierung die dir das dann
38:34
richtig formatieren ist gut Check.
38:36
Wenn du es nicht hast, kann es halt blöd werden und genau dann,
38:40
wenn du zum Beispiel angenommen, du bist irgendwo in einem,
38:43
arbeitest an einem Feature, hast neues File oder Erweiterst
38:46
irgendwie n Pfeil ne springst, dann weil du dir anguckst.
38:49
OK warte mal hier wird ne Funktion aufgerufen aus einem
38:51
anderen Pfeil, springst dahin, guckst dir das an, siehst ah OK
38:54
so läuft das das und das OK das wollte ich noch mal checken ob
38:57
das wirklich so ist. Ne und dann kommst du an einen
38:59
Punkt wo du dir denkst. Warte mal, das ist irgendwie
39:02
komisch. Warte mal ich mach mal Auto
39:03
layout, das heißt du bist in einem Pfeil der überhaupt nicht
39:06
in deinen Scope gerade fällt, siehst es aber und denkst dir
39:09
so. Und wie gesagt, das hab ich auch
39:10
manchmal, dass ich dann so diesen diesen Drang hab zu sagen
39:13
echt Auto layoute das jetzt weißt du weil ich mir denke so
39:16
ich sehe, dass das nicht richtig formatiert ist.
39:18
Ich mach das jetzt, obwohl das halt irgendein Pfeil ist was ich
39:20
sag mal 5 Kilometer weiter weg von dem Feature liegt was ich
39:23
gerade bearbeite weißt nicht meine.
39:25
So aber ist das nicht OK für dich.
39:27
Na ich find es blöd, wenn du, wenn das permanent immer dann
39:30
noch in den in den in den gleichen Commit reinkommt, wie
39:33
das Feature angenommen. OK, du musst, das kann ich.
39:38
Verstehen, aber ich find das ist sehr schwer zu vermeiden.
39:41
Ja, es ist auch. Es ist auch wie gesagt, es geht
39:44
mir darum, wenn es exorbitant stattfindet, wenn du wirklich
39:47
sagst, du hast n Feature, musst es angucken und hast dann
39:50
zwischendrin immer so irgendwie falls falls falls autoformat
39:53
autoformat denkst du so, oh Gott, oh Gott oh Gott OK ist
39:55
egal ne so wie gesagt es ist auch sind.
39:57
Ist auch nicht so, dass es absolut gar nicht geht.
40:00
Das ist n mittleres no go, aber wenn du immer das machst ne also
40:05
es ich angenommen bis passiert kannst du ja drüber reden,
40:07
kannst sagen ey wollen wir das vielleicht so und so machen,
40:09
manchmal muss man sich auch selber dran erinnern, aber wenn
40:11
du das immer wieder also angenommen du hast regelmäßig
40:15
Code Reviews und hast regelmäßig dann immer so was drin, also
40:18
Belanglosigkeiten die eigentlich gar nicht zum Feature gehören,
40:21
das find ich blöd da hab. Ich das das da, da geh ich mit
40:25
ja. Das kann man trennen, gerade
40:28
wenn ich auch keine Ahnung, wenn ich so Typus drin hab oder so,
40:32
die ich so zwischendurch fixe oder so, dann kann man schon
40:35
gucken als implementieren Implementierender sagt man das
40:39
so, dass ich das Implement extra Commit zaue der Implementi genau
40:44
das klingt wie lateinisch, genau dann das auf n extra commit
40:52
packen fördert auf jeden Fall, dass das Review.
40:56
Übersichtlicher ist, da bin ich ganz bei dir, also Störfeuer so
41:00
im Review, was ablenkt von den eigentlichen wichtigen Changes
41:04
ist natürlich kontraproduktiv, weil halt das Kernproblem
41:07
Reviews halt sehr umfangreich wären und dann Sachen einfach
41:10
übersehen werden. Ich hab noch ein no go, das
41:14
können wir noch n bisschen Zeit haben wir noch, weil das passt
41:17
gerade sehr gut rein was für mich n absolutes No go ist und
41:21
was halt zu großen Reviews auch führt sind.
41:26
Feature branches also ich geh mal so n bisschen feature
41:29
Branches hasse ich auch. Ich geh mal so n bisschen in
41:35
Entwicklungsmethodiken rein und ganz oft verwendet man ja git
41:40
zum Beispiel für die Repositories und da gibt es ja
41:44
so auch den klassischen Git Flow, das heißt man hat sag ich
41:46
mal jetzt n Main Branch. Das ist so dein
41:49
Hauptentwicklungszweig wo deine neuesten Versionen sozusagen
41:52
liegen, also jetzt klassischer Sinn, ne?
41:53
Das heißt, wenn ich n größeres Feature oder wenn ich n feature
41:56
entwickel was neues zweig ich abgehen wir jetzt mal ganz von
42:00
dem klassischen Fall aus Entwickel auf meine Abzweigung,
42:03
also auf meinem Brunch und lass es dann zurück in den Hauptzweig
42:06
fließen. Klassisch spricht nichts
42:10
dagegen, ist für mich völlig fein, ne wenn Leute aber dazu
42:13
neigen zu sagen ja ich mach mir jetzt erstmal schön Brunch.
42:17
Und dann mach ich mein eigenes Ding.
42:18
Haben wir immer so richtig, also ne, dann kann ich ja erstmal
42:21
entwickeln, weil dann bin ich ja erstmal so auf mich gestellt, da
42:23
kann ja nichts passieren und das No go dahinter sind für mich
42:29
feature branches die ne sehr hohe Lebensdauer haben, da könnt
42:33
ich komplett kotzen, das regt mich richtig auf, weil es
42:37
meistens die Bequemlichkeit von Entwicklerinnen und Entwicklern
42:40
ist. Punkt A, dass Sie sagen, Nö,
42:43
ich, ich mach da jetzt erstmal in Ruhe mein Ding und das wird
42:46
schon, das werd ich schon wieder integrieren können.
42:48
Problem ist je länger das Ding lebt umso weiter entferne ich
42:50
mich von der eigentlichen Entwicklung, was irgendwie klar
42:53
sein sollte und umso schwieriger wird die Integration wieder.
42:56
Stichwort Code Review zum Beispiel, wenn ich natürlich
42:59
lange auf dem Feature Brunch bin und da super viele Änderungen
43:02
mache, gibt es auch dementsprechend viel zu
43:04
reviewen, um deinen Punkt noch mal aufzugreifen, ist n no go,
43:07
da kombinieren sich schon mal 2 no gos, die quasi auch aus dem
43:10
gleichen Ursprung resultieren und wenn du es noch weiter
43:13
treibst, kommt nämlich noch n no go oben drauf für mich, weil
43:17
warum machen sie? Es gibt nur einen Grund, dass n
43:20
Feature Brunch lange lebt in meinen, in meinen.
43:23
Wie soll ich sagen, aus meiner Sicht ne bei einer klassischen
43:26
Entwicklung jetzt nicht, dass ich Varianten hab oder so, da
43:28
rede ich gar nicht drüber. Ne heißt ein Grund der dafür
43:32
spricht ist ich hab wirklich n sehr großes Feature zu
43:35
implementieren. Ja und das ist nämlich genau das
43:38
nächste No go, dann schneit die Features nicht so groß warum
43:42
musst du wochenlang auf einem Feature Branch arbeiten?
43:45
Es gibt gar keinen Grund dafür, dann dann ist das Problem ganz
43:48
woanders und so. Resultiert das eine no go in das
43:52
nächste no go und du hast so ne kaskade, ne, dass du dir denkst,
43:57
das ist doch einfach alles nur noch nervig hier gerade.
43:59
Das no go weißt. Du ja, so sagt man, die No Go
44:04
Kirsche da oben drauf. Kenn ich ja, kann ich
44:09
nachvollziehen und das ist. Auch wirklich ne Sache, die hab
44:13
ich jetzt so Grad gar nicht dran gedacht.
44:15
Also da wär ich jetzt so tatsächlich nicht drauf
44:17
gekommen, aber ich geh absolut mit, dass das n absolut n
44:20
absolutes No go ist, dass man sagt Ey, also wenn du lange an
44:25
dem Branch entwickelst, ja dann würd ich zumindest sagen
44:29
regelmäßig den Main rein, mergen so.
44:32
Ja, das ist das Mindeste, dass du wenigstens die Konflikte auf
44:35
deine Seite holst. Aber aber wie gesagt.
44:40
Ich hab da diese Diskussion hab ich schon sehr oft geführt, auch
44:43
in älteren Projekten und ich habe nie verstanden.
44:47
Also es gab für mich keinen validen Punkt, der das begründet
44:51
hat, das so zu machen, weil ein Argument war immer, aber dann
44:55
hab ich ständig Konflikte, ja, da muss ich ja immer gucken, was
44:58
in der Zeit entwickelt wurde, und es sind ja so viele
45:00
Entwickler und Entwicklerinnen, die da arbeiten an dem Projekt
45:03
waren wirklich viele Coder, ja. Das heißt, ich hab ja ständig
45:06
changes, die ich dann rein mergen muss.
45:08
Dann denk ich mir so ja, aber beantwortest du dir nicht gerade
45:11
selbst die Frage, wenn dich das schon nervt, wie hart wird es
45:15
dich nerven, wenn du in 5 Wochen dein Brunch aufstand bringen
45:19
musst? Und wer soll da, wer soll noch n
45:23
Überblick haben was jetzt wie wo rein muss passt dein passt deine
45:28
Entwicklung überhaupt noch dazu? Vielleicht musst du auch in der
45:32
Zeit wieder alles abändern, dann.
45:34
Wichtige Fragen also. Definitiv geh ich voll mit Tino,
45:38
keine Frage. Das ist also da, da red ich mir
45:41
richtig ne Branche. Ich hab nein, aber das ist aber
45:46
das sind echt so Punkte, die find ich die die spielen alle
45:49
zusammen ne also erstmal große Features dadurch resultieren
45:54
große Feature branches wenn wir wollen ja niemanden
45:56
unterstellen, dass er faul ist und einfach denkt so nee ich
45:58
mach erst mal mein dick und dann die Code Reviews die daraus noch
46:01
resultieren wo auch keiner Bock drauf hat am Ende.
46:04
Ja. Und dann am besten noch so n so
46:06
ne Nachricht kannst du mal eben das Code Review machen?
46:08
Ich würd es gerne integrieren, kriegst du aber dann wie du
46:10
meinst 200 Files rübergeworfen denkst du ja klar frag mal in
46:14
einer Woche noch mal nach, dann hab ich es vielleicht alles
46:15
durchgeguckt. Ja, genau so ungefähr.
46:17
Das ist halt das, das das bringt es halt dann nicht, weil im
46:20
Endeffekt Code Reviews sind ja gut, keine Frage, wenn sie aber
46:25
zu riesengroß wären und du dann wirklich sagst, so ey ich in
46:28
einer Woche bin ich fertig, so dann.
46:30
Kommt in einer Woche eigentlich schon das nächste Gefühl drauf?
46:33
So, und dann bist du ja nur noch am Review und so ne, also da
46:35
muss man halt gucken, dass man wirklich auch n Code review,
46:38
wenn du es erstellst irgendwie auch angenehm wie möglich
46:41
machst. Auch wenn ich sagen muss, wie
46:43
gesagt, es ist ja auch nicht immer, dass man alles immer
46:45
selber perfekt macht, so ne, weil man kann.
46:48
Ja nicht drauf ein, aber man muss das im Hinterkopf haben.
46:50
Genau. Ich glaube also, ich könnte
46:53
jetzt glaube ich noch weiß nicht 10 weitere no Gos aufzählen.
46:58
Lass uns das doch mal zusammenfassen.
47:01
Also wenn vielleicht, vielleicht kommt ja noch mal n zweiter Teil
47:05
dieser Folge raus. Liebe zu, höre zu, falls du das
47:08
cool findest, dass wir darüber sprechen und n zweiten Teil dir
47:11
wünscht, dann schreib uns gerne, dann uns fallen noch genug
47:13
Punkte ein auf jeden Fall und schreib uns auf jeden.
47:16
Fall aber auch was deine No Gos sind.
47:19
Falls wir jetzt zum Beispiel welche genannt haben oder noch
47:22
nicht die genannt haben, die du aber als No gos hast.
47:28
Dann würde ich sagen, lass uns mal das kurz zusammenfassen.
47:33
Jeder kann ja mal seine Top 2 nennen, beispielsweise von
47:38
denen, die wir heute genannt haben, lass das noch so n
47:39
bisschen priorisieren. Ich find es zwar sehr schwierig,
47:41
aber wir können es ja mal versuchen und eine Sache möchte
47:44
ich aber kurz anmerken, jetzt wo wir auch noch mal wirklich
47:48
zusammenfassend darüber gesprochen haben, finde ich es
47:50
halt krass, dass zumindestens bei uns einige No gos
47:55
voneinander. Abhängig sind oder sich
47:57
bedingen, ja oder halt auch wirklich wirklich, wieso ne
48:02
Reihenfolge aufbauen, ne du fängst mit einem No go an, dann
48:06
hast du so ne richtige Kettenreaktion an no gos find
48:08
ich halt schon spannend so, wenn man mal drüber nachdenkt, ne.
48:10
Ja, das stimmt, dass du es. Halt an einer Stelle schon viel
48:13
Pain vermeiden kannst. Wenn du den ordnungsgemäß
48:16
machst. Und das ist zum Beispiel sowas
48:18
wie die agile Arbeitsmethode. Ja, wo ich meinte, Warum sind
48:21
denn eure Tickets so riesig beispielsweise?
48:24
Ja. Das ist auf jeden Fall die ein
48:27
Wurzel des Übels. Ja, klingt gut, find ich gut,
48:33
ich glaube also, wenn es jetzt zum Beispiel um Codebase geht,
48:37
ich, ich heb das direkt mal auf die Ebene, wenn du nicht, also
48:42
weil ich ja von langen Files geredet hab, ne in Sachen
48:44
codebase das ist find ich wirklich schlimm, hat aber wohl
48:51
damit zu tun und ich find das richtig was du gesagt hast, dass
48:54
einfach. Die Mentalität ich refactory
48:56
hier nichts oder zu wenig halt einfach das und wenn du das
49:00
nicht machst wie ich auch meinte mit der Story die ich erzählt
49:02
hatte, das ist für mich auf jeden Fall Code, technisch ein
49:05
riesennogo, was meiner Meinung nach überhaupt nicht geht.
49:09
Da gehe ich tatsächlich mit. Das ist für mich auch einer der
49:13
größten Logos, die wir heute genannt hatten, also Code, die
49:16
Code Basis nicht zu refact dann auch wenn ich weiß, dass man
49:19
Sachen verbessern kann und umbauen müsste, weil.
49:23
Ich damit einfach n riesen Schaden anrichte im Projekt
49:26
wissentlich eigentlich wissentlich ja.
49:28
Dass, was in der Zukunft auf die Füße fallen wird und hast du
49:32
noch n zweiten ich find den Punkt zu sagen wenn du ich
49:38
formulier das jetzt mal extra mit Absicht n bisschen krass
49:41
wenn du keine Ahnung hast ja dann hör auf kluge Ideen
49:45
reinzuwerfen weil. Gerade wenn es darum geht, dass
49:51
du vielleicht wirklich etwas entscheidest, obwohl du keine
49:54
Ahnung davon hast. Also anstatt zu sagen, ey, pass
49:56
auf, ich hol mir jetzt die Expertise von jemandem rein, der
49:58
es vielleicht weiß, um dann darauf gehend auf dieser Basis
50:02
zu entscheiden. Das macht Sinn oder halt eben
50:06
die. Also wenn du eine Entscheidung
50:07
treffen musst oder wenn du sagst, OK, das ist nicht mein
50:11
Zuständigkeitsbereich, dann muss ich mich darum nicht kümmern,
50:15
ne. Wenn sie also noch mal
50:16
Stichpunkt. Dass man zum Beispiel sagt, OK,
50:19
ich würd es so und so implementieren, oder dein
50:22
Beispiel bitte zu jedem, zu jeder Zeile Code n Kommentar ne,
50:27
das fällt halt da drunter. Das ist finde ich so, wenn es
50:30
jetzt um die ich sag mal nicht unbedingt um die Codebasis an
50:34
sich geht, aber wenn es jetzt sozusagen um das Drumherum geht.
50:38
N starkes Manko für mich. Platz 2 ist bei mir schwierig,
50:42
also ich Schwank stark zwischen keine Tests und die Feature
50:48
Branch Nummer tatsächlich, aber das resultiert auch irgendwie
50:52
in. Also ja, es ist halt so diese
50:54
Verantwortlichkeitsthematik ne wie beim Refactoring, weil jetzt
50:58
glaub ich jeder erwartet, dass wir da keine Tests nennen, mach
51:01
ich es jetzt nicht, es ist aber auch wirklich es schwebt über
51:04
allen so keine Tests n no go das schwebt über alles ne deswegen
51:08
nehm ich mal die Feature branches weil es einfach.
51:11
Ich halt erlebt hab in einem wirklich sehr großen und
51:13
wichtigen Projekt, dass das richtig viel Pain bedeuten kann,
51:17
wenn wirklich viele Entwicklerinnen und Entwickler
51:22
auf ihren Branches verharren, man dann nicht mehr weiß, wie
51:26
man alles zusammenführen soll, weil es halt einfach sehr hohe
51:29
Lebensdauern sind und das hätte man vermeiden können durch
51:33
bessere Schnitte der der Features, beispielsweise durch
51:36
bessere agile Umsetzung. Und vor allem auch vom Mindset,
51:41
der der Coder her muss ich ganz ehrlich sagen und deswegen würd
51:45
ich das als zweiten Punkt nehmen.
51:49
Alright so, dann haben wir uns mal im positiven Sinne
51:52
ausgekotzt, war n sehr sehr cooles Gespräch, hat mir viel
51:55
Spaß gemacht fabi, wir können auch einfach mal als ergänzende
52:00
Folge mal ne Duce Folge machen, also Sachen die wir so als
52:03
richtig geil erachten ne um mal wieder mal n bisschen mehr
52:06
Positivität reinzubringen, der Podcast soll ja für was
52:08
Positives stehen. Aber ich denke aus den No Gos
52:11
kann man auch ne Menge für sich mitnehmen.
52:13
Liebe Zuhörer, liebe Zuhörer und wie gesagt, Falls du noch Punkte
52:15
hast, schreib sie uns gerne, falls du nicht ganz
52:18
einverstanden bist mit dem was wir gesagt haben, dann schreib
52:21
uns das bitte auch ganz gerne. Wir haben auch im Discord auch n
52:24
Channel extra dafür, wo wir uns mit Leuten aus der Community
52:27
austauschen, zu Podcast folgen, das Macht immer mega viel Spaß
52:31
und wir sind auch richtig dankbar für jedes Feedback,
52:34
ansonsten würde ich sagen sind wir damit heute durch Fabi.
52:39
Noch mal kurz wie immer der Hinweis in den Shownotes Liebe,
52:42
zuhören, Liebe zuhören. Gibt es alle Links zu allen
52:45
Plattformen. Falls du einen Link deiner Wahl
52:47
suchst, dann schau da gerne mal vorbei.
52:50
Die Podcast Mail findest du da. Falls du uns darüber schreiben
52:52
möchtest, n spenden Link falls du sagst ach Mensch das war ne
52:55
richtig coole Folge, die beiden möchte ich unterstützen in Ihrem
52:58
Vorhaben diesen Podcast weiter zu treiben, dann vielen vielen
53:01
Dank dafür. Empfiehl ihnen auch gerne
53:03
weiter, lass ne Bewertung da, denk an das Glöckchen, was wir
53:06
selbst erst vor n paar Wochen, vielleicht mittlerweile Monaten,
53:09
ich weiß es nicht genau entdeckt haben und ansonsten würde ich
53:12
sagen, hören wir uns alle beim nächsten Mal wieder.
53:14
Ich wünsche euch ne wunderbare Zeit bis dahin ciao ciao bis zum
53:18
nächsten Mal deine Coding Buddies.
53:20
Gemeinsam besser.