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.