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