Latest / Coding Buddies | Tech & Dev-Mindset / Refactoring? Mach's gleich richtig!

Transcript

Refactoring? Mach's gleich richtig! · Coding Buddies | Tech & Dev-Mindset

• 0:00
  Wir müssen jetzt noch ein paar neue Features reinpacken und
• 0:03
  wenn wir das haben, dann können wir quasi refecto und das ist
• 0:06
  meiner Meinung nach eine riesengroße Lüge.
• 0:11
  Dein Podcast rund um Softwareentwicklung und
• 0:13
  aktueller Tech News. Herzlich Willkommen.
• 0:27
  Ja, herzlich Willkommen zur neuen Folge des Coding Bodies
• 0:30
  Podcast. Schön, dass du wieder
• 0:31
  eingeschaltet hast. Wir sind natürlich wieder mit am
• 0:34
  Start. Einerseits meine Wenigkeit Tino
• 0:36
  und natürlich auch wieder fantastische Fabi, Fabi, Grüß
• 0:39
  dich neue Folge. Halli Hallo.
• 0:43
  Und hast du Bock, kann losgehen. Die Sonne scheint einfach super
• 0:47
  jetzt hier im Podcast aufzunehmen.
• 0:49
  Ich meine es hat die letzten Wochen gefühlt nur geregnet, der
• 0:52
  Regen ist vorbei, genau der Regen ist vorbei, die ersten
• 0:55
  Sonnenstrahlen kommen raus, da wird es natürlich Zeit einfach
• 0:57
  wieder in der Bude. Zu setzen und Podcasts
• 0:59
  aufzunehmen. Da kommt man nicht drum.
• 1:03
  Drin, ne. Bude zu sitzen, ja.
• 1:05
  Das gehört einfach als Entwickler dazu, wirklich
• 1:08
  dauerhaft drin zu sitzen. Nein, wir haben natürlich ein
• 1:12
  spannendes Thema mitgebracht, deswegen freue ich mich sehr auf
• 1:15
  diese Folge, wir haben es ja auch schon mal angeteasert oder
• 1:18
  gemerkt, dass dieses Thema einfach wirklich wichtig ist und
• 1:23
  deswegen wollen wir heute ja über da da, da, da Riff.
• 1:28
  Reden. Ich dachte da, da, da.
• 1:31
  Da da, Nein, das war nur ein Trommelwirbel, hab ich jetzt
• 1:35
  nicht so hingekriegt. Nein, also das Thema ist
• 1:37
  refactoring hab ich Bock drauf, lass uns da mal ein bisschen
• 1:41
  drüber quatschen was ist eigentlich refactoring, was sind
• 1:44
  die vor und Nachteile oder auch Herausforderungen dabei und
• 1:47
  warum erachten wir als sehr wichtig, deswegen würde ich dir
• 1:51
  jetzt mal das Wort geben und fang doch einfach mal an, erklär
• 1:54
  doch mal unserer Community was refactoring ist.
• 1:59
  Ja, ich mach glaub ich einfach kurz.
• 2:01
  Bei Refactoring handelt es sich darum, dass man die Qualität
• 2:06
  seines Codes erhöht, ohne. Dass die.
• 2:11
  Funktionalität verändert wird. Und das ist prinzipiell
• 2:13
  eigentlich schon Factory. Die Frage.
• 2:17
  Ist ja eigentlich, das war wirklich sehr kurz und knapp.
• 2:20
  Aber ja, das trifft es eigentlich ganz gut.
• 2:24
  Kannst du das noch ein bisschen weiter ausführen, damit das Bild
• 2:28
  vielleicht noch ein bisschen klarer wird?
• 2:31
  Und zum Beispiel auch mal nennen, warum du denn denkst,
• 2:34
  dass es wichtig zum Beispiel dadurch die Code Qualität zu
• 2:37
  erhöhen. Und wie erhöhe ich denn dadurch
• 2:39
  die Qualität? Aber was meinst du jetzt mit
• 2:42
  genauer ausführen? Also es kann natürlich also
• 2:45
  meine, also wieso muss man überhaupt defekt, dann kann man
• 2:50
  sich ja vielleicht fragen, wenn man also es gibt ja keine, sich
• 2:53
  hinstellen und sagen, mach doch gleich von Anfang an richtig, da
• 2:55
  musst du nicht defekt da, da musst du deine Code Qualität
• 2:58
  nicht erhöhen wenn du schon am Anfang auf deine Qualität
• 3:01
  achtest, richtig so, das könnte man ja durchaus in Raum werfen,
• 3:04
  ne? Hatte ich witzigerweise sogar
• 3:07
  mal ein Gespräch mit einem mit einem Projektmanager, der mich
• 3:11
  tatsächlich auch genau das gefragt hat, weil da ging es
• 3:14
  nämlich darum, dass wir, dass wir sozusagen unsere Anwendungen
• 3:17
  defekt, dann mussten, muss man regelmäßig machen, Spoiler Alarm
• 3:24
  und da war dann so ein bisschen die Diskussion, dass er, glaube
• 3:29
  ich selber n bißchen in die Bredouille geraten ist, weil
• 3:32
  irgendwie was fertig werden musste und dann hat er irgendwie
• 3:35
  gemerkt, dass ein paar Entwickler.
• 3:36
  Im Team reflektiert haben und sozusagen den Fortschritt, der
• 3:41
  also die Funktionalität, wie ich ja meinte, Ne nicht
• 3:43
  vorangebracht habe, nicht verändert haben von der
• 3:46
  Anwendung aber halt die Code Qualität erhöht haben, so wie
• 3:49
  ich das ja gerade eben schon so von der Definition meinte und
• 3:53
  dadurch, dass es aber nicht funktional voranging, hat er
• 3:56
  glaube ich so ein bisschen ist er also der Projektmanager n
• 3:59
  bisschen schwitzen gekommen weil irgendwas gedrängt hat und.
• 4:03
  Weil an zu dem Zeitpunkt das Projekt an sich.
• 4:07
  Auf dem Papier nicht weiter. Vorwärts kommt nicht genau genau
• 4:10
  also wie gesagt, die Funktionalität geht nicht
• 4:11
  weiter, erhöht die Code Qualität, was natürlich wichtig
• 4:14
  ist. Darüber wollen wir jetzt reden,
• 4:16
  aber es war auf jeden Fall so dieses Gespräch im Raum ne
• 4:20
  einfach aus dem Grund, dass ihm halt damit der Schuh gedrückt
• 4:24
  hat. Manche nennen es vielleicht
• 4:27
  Deadline, manche nennen es irgendwie anders.
• 4:30
  Meilenstein. Ja, also.
• 4:32
  Das Erreichen von. Meilenstein genau.
• 4:35
  Und natürlich kommt dann irgendwie so ein bisschen, sag
• 4:40
  ich mal, das Gespräch auf. Ja, warum können jetzt nicht
• 4:43
  alle mal ein bisschen hier Gas geben und n bisschen ne n
• 4:48
  bisschen machen, bitte, dass wir weiterkommen anstatt jetzt die
• 4:51
  Qualität zu erhöhen und da kam dann irgendwann in diesem
• 4:54
  Gespräch die Frage von ihm. Ja, aber wenn man jetzt zum
• 4:57
  Beispiel sagt, OK, wenn ich jetzt komplett ein neues Projekt
• 5:00
  aufsetze, muss ich dann irgendwann zwangsläufig
• 5:03
  irgendwann recht? Dann, und die Antwort war halt
• 5:06
  ja, das muss man halt machen, weil du gar nicht drum herum
• 5:10
  kommst, dass du, also du kannst es nicht schaffen, die ganze
• 5:14
  Zeit perfekt alles zu coden, weil du ja teilweise auch gar
• 5:17
  nicht weißt, wo solls denn hingehen, dann kommen neue
• 5:19
  Anforderungen, der Code ändert sich, du musst vielleicht
• 5:22
  irgendwelche Strukturen in deinem Code umstellen und dann
• 5:26
  kommt es halt dazu, dass du irgendwann regelmäßig mal wieder
• 5:29
  gucken musst. Oh, hier ist was was
• 5:33
  verbesserungswürdig ist. Ne und?
• 5:35
  Naja, da kommt das zum Beispiel auch schneller oder ist das
• 5:38
  passiert? Ja schnell mal genau, wo man
• 5:40
  dann doch nochmal durch seinen alten Code durchschaut, aber zu
• 5:45
  deinem Beispiel oder zu deine Erfahrungen, die du da gemacht
• 5:47
  hast. Was war das denn jetzt?
• 5:49
  Ein kritischer Punkt, dass ihr lange nicht reflektiert hattet
• 5:52
  und deswegen ein erhöhter refecto Aufwand aufkam?
• 5:56
  Oder war es eigentlich eine Sache von maximal ein 2 Tagen
• 6:00
  und die wollte euch quasi schon nicht?
• 6:03
  Eingestehen, sag ich mal. Na also, es ging glaube ich
• 6:06
  schon so. Also der Aufwand des Refactoring
• 6:09
  was wir hatten hat sich glaube ich über ein 2 Wochen hingezogen
• 6:12
  und das war immer ungefähr ein Drittel des Teams saß dann da
• 6:16
  dran und ich hab das auch n bisschen gepusht an der Stelle,
• 6:19
  weil mir das halt auch schon länger aufgefallen ist, dass man
• 6:22
  das hätte machen müssen. Und das ist dann halt irgendwie
• 6:26
  einfach. Irgendwann musst du halt mal
• 6:29
  sagen, OK, jetzt wird es gemacht, weil das Problem ist ja
• 6:32
  meistens, dass gerade in solchen Projekten im Arbeitsumfeld gerne
• 6:38
  mal gesagt wird, ja, das machen wir dann später, ne, das wird
• 6:41
  dann irgendwann mal gemacht, das wird irgendwann refecto,
• 6:44
  irgendwann wird die Qualität erhöht, aber erstmal müssen wir
• 6:46
  jetzt noch was liefern, wir müssen jetzt noch ein paar neue
• 6:49
  Features reinpacken und wenn wir das haben, dann können wir quasi
• 6:53
  reflektieren, und das ist meiner Meinung nach eine riesengroße
• 6:56
  Lüge. Weil man das halt einfach nicht
• 7:01
  konsequent durchzieht, weil du immer was zu tun hast.
• 7:04
  Es kommen immer wieder neue Sachen, die irgendwie reinkommen
• 7:06
  müssen und dann bist du halt irgendwann an dem Punkt, wo du
• 7:08
  sagst, also irgendwann musst du halt mal sagen, jetzt zieht die
• 7:11
  Reißleine, jetzt wird reflected ne und es geht ja um nochmal n
• 7:17
  bisschen drauf zurückzukommen, was du gefragt hast.
• 7:19
  Ne, wieso muss man denn überhaupt perfekt, dann kann
• 7:22
  nicht von vornherein alles richtig machen.
• 7:23
  Angenommen Du arbeitest im Team ne und sagen wir mal wir beide.
• 7:28
  Ne arbeiten im Team, arbeiten an 2 verschiedenen Stellen im Code.
• 7:31
  Ich schreib irgendwas, du schreibst irgendwas so
• 7:33
  vielleicht parallel, vielleicht schreiben wir Code teile die
• 7:37
  sehr sehr ähnlich sind, weil es gerade zufälligerweise so ist.
• 7:40
  Ne und jetzt kommt irgendwann ein Dritter.
• 7:45
  Und guckt sich das an. Und denkt sich irgendwie, warte
• 7:49
  mal, da ist eine Funktion, die S sehr ähnlich zu dieser Funktion.
• 7:52
  Vielleicht kann ich ja irgendwie ein kleines Refactoring machen,
• 7:56
  ne? Also Refactoring hat ja
• 7:57
  verschiedene verschiedene Punkte, ein Punkt davon ist ja
• 8:02
  zum Beispiel Redundanz zu beseitigen und wenn du merkst,
• 8:04
  dass zum Beispiel eine Funktion oder funktions teil redundant
• 8:07
  irgendwo im Code rumliegt, dann kannst du halt diesen teilnehmen
• 8:10
  extrahieren. Sodass, wenn eine Änderung an
• 8:14
  diesem Code teil stattfindet, dass du dann nicht in diesem
• 8:17
  Punkt kommst. Du sagst OK, ich hab jetzt den
• 8:19
  Code teil verändert, aber es gibt quasi noch einen sehr
• 8:22
  ähnlichen oder gleichen Code teil der woanders liegt und der
• 8:25
  ist dann sozusagen nicht angepasst oder halt in dem Falle
• 8:28
  danach fehlerhaft. Ne, das heißt?
• 8:30
  Fehleranfällig. Genau das heißt das, dass das
• 8:32
  sind ja so bestimmte Sachen und sowas kann halt auftreten, das
• 8:35
  kannst du im Vorfeld nicht unbedingt planen.
• 8:37
  Du kannst nicht sagen, ja, ich schreibe jetzt diesen Code und
• 8:39
  diesen Code, dann müsste man also dann hast du ja vielleicht
• 8:41
  n utopisch. Hohe Absprachen, Aufwand, wo man
• 8:45
  dann sagt, OK, jeder muss jetzt irgendwie besprechen, was
• 8:47
  irgendwie jede Funktion, die ja implementiert muss, abgesprochen
• 8:51
  werden, ne, und deswegen ist es halt einfach so, dass man
• 8:55
  einfach regelmäßig reflektieren muss, damit kann man von
• 8:58
  vornherein direkt ins Projekt starten, in egal wo man ist, man
• 9:02
  kann immer direkt sagen, OK, jetzt geht irgendwas los und
• 9:05
  irgendwann müssen wir mal defekt, dann die Frage ist nur
• 9:08
  meiner Meinung nach. In welchen Schritten möchte
• 9:11
  machen regelmäßig immer n bisschen oder in längeren?
• 9:15
  Abschnitt Bang dann machen, aber das ist ja genau der Punkt oder
• 9:19
  das, was ich jetzt noch sagen wollte ist, weil du meintest du
• 9:23
  hattest das schon länger so das Gefühl, oh da müssten wir mal
• 9:27
  reflect, dann wurde es weiter aufgeschoben, aufgeschoben und
• 9:30
  am Ende war es ein Aufwand von ein 2 Wochen.
• 9:32
  Klar jetzt nur für ein Drittel des Teams aber dennoch ne, also
• 9:36
  würdest du sagen man hätte definitiv früher Reflektoren
• 9:40
  müssen, damit das auch einfach schneller erledigt ist.
• 9:42
  Also hat sich das wirklich aufsummiert oder lag es einfach
• 9:45
  nur und defector Aufwand war gleich wie vor meinetwegen ihr
• 9:49
  hättet das 2 Monate früher gemacht.
• 9:51
  Ja, gute Frage. Also das war tatsächlich ist
• 9:54
  auch ein bisschen schwierig manchmal so, ich glaube, da gibt
• 9:57
  es nicht so die hundertprozentige Antwort,
• 9:59
  zumindest in diesem Fall nicht, weil es gab, also wir hatten
• 10:05
  einen bestimmten Stand und wussten aber zu diesem Zeitpunkt
• 10:07
  auch nicht hundertprozentig, wo es dann genau weitergeht, ne,
• 10:11
  irgendwann hat sich heraus kristallisiert.
• 10:13
  OK, es wäre aber auf jeden Fall wichtig, dass wir unsere
• 10:16
  Struktur des Codes generell, also ein bisschen, ich sag mal,
• 10:20
  das war schon eher so ein Teil auf architektonischer Ebene und
• 10:24
  umbauen wollten. Und das hat sich dann irgendwann
• 10:29
  herauskristallisiert, dass auch Sinn macht.
• 10:31
  Und dann kam der Punkt, wo wir gesagt haben, o, wir machen das
• 10:34
  mal bloß, dass wir dann im Team ein gesamtes Grundverständnis
• 10:40
  für alle schaffen, wollten, wir s machen wollten, weil es bringt
• 10:42
  ja nichts, wenn du sagst, die Hälfte des Teams weiß jetzt so,
• 10:45
  wie es läuft und wie man das Refektorium möchte und die
• 10:49
  andere Hälfte des Teams arbeitet nach dem Refactoring
• 10:52
  beispielsweise genauso weiter wie vorher und dann kannst du
• 10:55
  eigentlich, dann bringt es ja nichts.
• 10:56
  Dann arbeiten 2 t, also 2 Teile des Teams in völlig
• 11:01
  unterschiedliche Richtungen. Und dann ist der Code hinterher.
• 11:03
  Kraut und Rüben ne, aber wir mussten halt irgendwie diesen
• 11:06
  diesen diesen Zeitpunkt finden oder diesen Termin erstmal
• 11:10
  machen, diesen Workshop, worauf dann halt auch erstmal wieder
• 11:12
  vielleicht keiner so richtig Lust hat, muss sich hinsetzen
• 11:15
  und muss nachdenken und und das war irgendwie auch so n bisschen
• 11:19
  Punkt. Also man braucht natürlich die
• 11:20
  Zeit und die Zeit muss man sich dann irgendwann nehmen und dann
• 11:23
  haben wir sozusagen alle im Team Brainstorming darüber
• 11:25
  nachgedacht, wie wir das machen wollen.
• 11:27
  Und dann? Danach ging es halt eigentlich
• 11:31
  erst richtig los, ne? Ich frage, weil ich hab halt die
• 11:35
  Erfahrung gemacht, dass oftmals so ist, wenn man schneller in
• 11:41
  diese in diesem Zyklus kommt oder sagt, OK ich reflecta
• 11:44
  jetzt, ich dreh jetzt noch mal die Runde und schaue nochmal
• 11:47
  alles durch und optimiere und steige ja damit hoffentlich auch
• 11:51
  die Code Qualität, dass es für die weiterführende Entwicklung
• 11:54
  halt auch viele Verbesserungen mit sich bringt.
• 11:58
  Also das heißt ja nicht, dass dieser Aufwand nicht statt oder
• 12:02
  irgendwie mit steigt, sozusagen ne, weil wenn du jetzt zum
• 12:06
  Beispiel. Funktionen, reflectors,
• 12:08
  Schnittstellen oder Whatever kann es ja sein, dass die neuen
• 12:12
  Features, die du implementierst, sich viel besser und leichter
• 12:14
  implementieren lassen oder im Worst case du noch auf dem alten
• 12:18
  Code aufsetzend das Weiterentwickelst und das auch
• 12:21
  alles dann wieder reflektiert werden muss, wenn du einmal dann
• 12:25
  anfängst. Und so skaliert das ja quasi
• 12:27
  dann auch oftmals mit der Aufwand ja definitiv keine gute
• 12:32
  Sache ist. Deswegen hab ich gefragt, ob du
• 12:33
  einschätzen würdest, dass es hätte viel schneller erledigt
• 12:36
  werden können. Wenn es natürlich jetzt ne
• 12:38
  Entscheidung in der Architektur ist oder so, dann wird
• 12:40
  wahrscheinlich auch gleich bleiben, weil es ja
• 12:43
  wahrscheinlich ja ein sehr grundlegender Umbau war dann.
• 12:48
  Aber im Allgemeinen, wenn es um einfache, quasi Optimierung der
• 12:53
  Funktionalitäten ist der Schnittstellen, dann finde ich,
• 12:57
  dass es meistens wirklich besser ist, relativ schnell in diesem
• 12:59
  System in diesem reflector Zyklus zu kommen, um halt
• 13:03
  einfach sich auf das Leben danach leichter zu machen.
• 13:05
  Ja, auf jeden Fall. Also das, wir hatten ja auch im
• 13:09
  in der Test Driven Development Folge auch darüber geredet, dass
• 13:12
  gerade Test Driven Development ja genau diesen refactoring Part
• 13:16
  jedes Mal mit drin hat. Ne, und dann?
• 13:19
  Sorgt er auch? Dafür, dass du regelmäßig das
• 13:21
  machst. Es kommt halt immer drauf an,
• 13:24
  weil für mich ist es so, dass es so unterschiedliche Arten von
• 13:28
  Refactoring gibt, und zwar entweder du reflectors nur eine
• 13:32
  Funktion oder eine Klasse oder halt wie gesagt dann auch ne,
• 13:37
  vielleicht auch ne ganze die ganze Software, die die
• 13:39
  Architektur dieser Software n bisschen unterschiedliche Ebenen
• 13:43
  und in dem Fall was ich jetzt gerade.
• 13:49
  Eingeführt hatte. Da ging es halt wirklich darum,
• 13:53
  dass sich dann langsam herauskristallisiert hat, dass
• 13:56
  es besser ist, dann nochmal ein bisschen zu wechseln.
• 13:58
  Und wenn du aber zum Beispiel am Anfang sag ich jetzt mal ne
• 14:03
  andere Annahme getroffen hast, weil die Anforderungen von der
• 14:06
  von der Software auch anders sind und sich dann aber ändern,
• 14:09
  dann kann es halt einfach dazu führen, dass man sowas machen
• 14:12
  muss, das sind da manchmal größere Umbauten, das stimmt,
• 14:16
  aber wie du auch schon meintest, je länger man damit wartet,
• 14:19
  desto länger zieht sich das am Ende trotzdem, auch wenn es
• 14:22
  erstmal ein größerer Aufwand ist, ne?
• 14:24
  Ja, also zum Beispiel, wenn man jetzt sagt, OK, man hat 10
• 14:27
  Klassen und muss die grundlegend, sag ich jetzt mal
• 14:30
  refecto irgendein Beispiel zu bringen und dann sagst du ja,
• 14:34
  wir machen das noch, wir machen das noch und dann hast du aber
• 14:36
  irgendwann 15 Klassen, sag ich jetzt mal, wo du das machen
• 14:38
  musst. Ne ist jetzt sehr effektiv
• 14:41
  gewesen, aber ich hoffe du konntest das Beispiel
• 14:43
  nachvollziehen. Aber wir können ja ein reales
• 14:46
  Beispiel bringen aus unserem aktuellen Projekt, von der
• 14:48
  Arbeit aus. Da war das ja so, dass wir uns
• 14:53
  entschieden haben, unsere kompletten Test zu reflektieren,
• 14:58
  aber auch im Sinne von, dass wir das Test Framework umgestellt
• 15:01
  haben, und das ist ja schon ein großer Aufwand gewesen durch
• 15:05
  alle, also wirklich alle testen, neu zu schreiben beziehungsweise
• 15:08
  nochmal durchzugucken und quasi in das neue Framework zu
• 15:12
  überführen, wo sich auch Leute denken könnten, warum
• 15:17
  eigentlich, also warum macht ihr das?
• 15:19
  Die Tests laufen, also das alte Test Framework hat funktioniert.
• 15:22
  Ja, nur haben wir festgestellt, je länger man damit arbeitet, so
• 15:28
  na, war vielleicht nicht die richtige Entscheidung.
• 15:30
  Hätten doch lieber das andere Framework nehmen müssen und ja,
• 15:35
  am Ende haben wir es ja umgebaut, zum Beispiel deshalb,
• 15:39
  weil es einfach wesentlich performanter war und die Tests
• 15:41
  schneller liefen. Ja, jetzt kann man sich ja
• 15:44
  denken, ja gut, läuft halt n paar Sekunden schneller oder so,
• 15:47
  aber was das auch für den Aufwand beziehungsweise in der
• 15:50
  Summe dann ausmacht, weil wie gesagt Test driven wir lassen
• 15:53
  nicht sehr oft. Laufen die Tests ne, also was du
• 15:57
  da denn hinten raus wieder an Zeit sparst hätte man sagen
• 15:59
  können, lass es einfach, also so früh wie möglich hätte man
• 16:02
  diesen Umbau machen müssen, auch wenn natürlich dann erstmal
• 16:04
  keine Features implementiert, sondern ja eigentlich nur seine
• 16:07
  Test Abdeckung neu aufsetzt sozusagen.
• 16:09
  Ja, aber das ist, das ist ein guter Punkt, weil gerade dieser,
• 16:14
  weil du das gerade ansprichst, so dieses aufschieben, ne was
• 16:19
  was finde ich immer sehr, sehr wichtig ist.
• 16:21
  An dieser Stelle ist, dass man, wenn man sagt.
• 16:25
  Okay wir müssen jetzt erst mal vorankommen, ne, und
• 16:27
  beispielsweise wir sagen ja, lass mal das Refactoring noch n
• 16:31
  bisschen, wir müssen jetzt erstmal feature ABC machen und
• 16:37
  wenn wir das haben so das Problem ist, wenn du dann aber
• 16:40
  sag ich mal an den Punkt kommst und sagst ich hab jetzt Feature
• 16:42
  ABC fertig und sagst jetzt würde ich gerne Reflektoren und dann
• 16:45
  hat heißt es aber vielleicht jetzt müssen wir noch DF machen
• 16:49
  und dann können wir weitermachen und dieses aufschieben ne und
• 16:52
  irgendwann hat bist du in diesem in diesem Modus das sozusagen.
• 16:56
  Du sogenannte technische Schuld aufbaust, weil du dann
• 17:00
  vielleicht noch mal ein Workaround gemacht hast und
• 17:02
  Bekanntlicherweise bleiben Workarounds für immer in der
• 17:05
  Software drin. Nee, aber also das, das ist halt
• 17:11
  das Problem, das heißt du in, ich sag jetzt mal, wenn man,
• 17:13
  wenn man jetzt von so einem, ich sag mal Zyklus spricht, es waren
• 17:17
  zum Beispiel sagt, OK, du hast jetzt eine bestimmte Menge an
• 17:20
  Features, die neu reinkommen, aber du hast nicht, dann kommen
• 17:25
  die, der nächste Zyklus ist, kommen also wieder n neue Menge
• 17:28
  an Features rein, du Effekt das nicht und am Ende hast du quasi
• 17:31
  für jeden für jeden in die für jeden Zyklus wo du diese diese
• 17:38
  wo du nicht defekt. Das erhöht sich ja.
• 17:40
  Der Aufwand des Refactoring und zusätzlich kommen wir aber
• 17:43
  trotzdem regelmäßig über Features.
• 17:45
  Das heißt, wenn du sagst, du brauchst keine Ahnung Monat für
• 17:48
  alle Features und hast dann keine Zeit mehr, bräuchtest du
• 17:51
  aber ein sozusagen Monat und eine Woche für Feature und
• 17:54
  Refactoring, dann brauchst du im nächsten Zyklus wieder einen
• 17:57
  Monat für die Features, aber vielleicht 2 Wochen für das
• 18:00
  Refactoring. Und irgendwann mal
• 18:01
  unwahrscheinlicher, dass das irgendwie gleichzeitig alles
• 18:04
  noch hinkriegt. Genau rechtzeitig.
• 18:05
  Und irgendwann kommt man vielleicht an den Punkt, wo man
• 18:07
  dann, und dann kommt dieser Big Bang, von dem du geredet hast.
• 18:10
  Ne, dass du vielleicht den ganzen Zyklus einfach nur für
• 18:14
  das Refactoring brauchst und dann kommt wieder jemand und
• 18:16
  sagt, ihr habt ja gar nichts geschafft.
• 18:18
  So, und das ist halt das Allerschlimmste finde ich, weil
• 18:21
  wenn du dann sozusagen als Entwickler hörst.
• 18:23
  Ja, ihr habt ja nichts geschafft und du denkst dir pass auf das,
• 18:27
  was wir gerade geschafft haben ist, dass wir überhaupt für die
• 18:29
  Zukunft eine Grundlage gelegt haben, dass diese Software
• 18:32
  überhaupt noch weiter existieren darf, das ist halt der finde
• 18:36
  ich, dass das krasse, weil da denkt niemand daran, ne,
• 18:40
  sozusagen dieses. Ich denk mal n bisschen weiter
• 18:42
  und überleg mir mal, soll diese Software denn überhaupt noch in
• 18:46
  Zukunft existieren oder wollen wir so lange Features machen bis
• 18:49
  das Ding implodiert? Weißt du und.
• 18:52
  Das ja, das ist ein echt guter Punkt.
• 18:54
  Aber also ich bin da voll auf deiner Seite, ne, aber ich
• 18:58
  erwische mich auch selbst dabei, dass manchmal.
• 19:03
  Wenn dann halt im Projekt Stress aufkommt, man sich auch
• 19:08
  verleiten lässt zu sagen, ja, OK, wir machen jetzt die und die
• 19:11
  Funktionalität bauen wir noch ein, aber dann werden wir
• 19:13
  wirklich mal reflektieren, weil du weißt eigentlich schon, du
• 19:15
  hast es wirklich vor Augen, du hast am besten schon eine to do
• 19:18
  Liste eingelegt, was alles gemacht werden muss, ne und die
• 19:21
  guckst du dir jeden Tag an und denkst dir, na gut, aber jetzt
• 19:25
  noch Feature AB und dann dann wirklich so, also man das ist
• 19:29
  halt auch schwer da so richtig konsequent zu sein finde ich
• 19:32
  manchmal. Weil du ja wirklich keine Ahnung
• 19:34
  kommt dein Produkt oder zu dir und sagt Hey, müssen das jetzt
• 19:37
  wirklich in dieser Iteration mal fertig kriegen so ne und im
• 19:41
  Hinterkopf hast du o meine ich würde aber echt gerne vorher
• 19:44
  noch einmal durchgefallen, weil das gefällt mir gar nicht mehr
• 19:47
  so wie der Code aktuell ist. Also in diesen diesen Modus kann
• 19:51
  man halt schneller reinfallen als man denkt, also es ist halt
• 19:54
  leicht gesagt zu sagen ne machen wir jetzt nicht wie dann weil
• 19:57
  irgendwann kommt halt auch mal der Projekt Stress unter, dieser
• 20:00
  reicht der Druck von außen da drauf ne.
• 20:02
  Aber meinst du nicht, dass es rein theoretisch.
• 20:05
  Eigentlich. Mit inbegriffen sein sollte,
• 20:09
  dass man sagt ich also Software zu schreiben beinhaltet eine
• 20:14
  gewisse Art von Refactoring. Ja, sollte es also.
• 20:19
  Das ist ja dann aber auch wieder eine planungs Sache.
• 20:23
  Dass du dir die Zeit halt dafür aktiv einplanen und quasi das
• 20:28
  Wissen im Team oder auch im Projekt herrscht.
• 20:32
  Dass das damit drin ist, also dass das nicht nur Features
• 20:35
  beinhaltet, sondern auch die Wartung der Software, halt ne.
• 20:39
  Also ich hab mal gehört, dass man ungefähr im Normalfall, und
• 20:45
  das ist absolut realistisch, 20 bis 30% initial schon immer,
• 20:50
  immer wenn Software Entwicklung stattfindet, für das Refactoring
• 20:54
  einplanen muss. So, und da sind wir dann zum
• 20:58
  Beispiel auch wieder an diesem Punkt, weil ich ja meinte, dass
• 21:01
  ein Drittel des Teams bei mir in dem Beispiel, was ich vorhin
• 21:05
  genannt hab, was mir, was mir passiert ist, haben.
• 21:09
  Wir hat ja ein Drittel des Teams daran gearbeitet und rein
• 21:12
  theoretisch, und das war nur für über 2 Wochen.
• 21:14
  Die müssen dauerhaft dann eigentlich.
• 21:16
  Das rein theoretisch muss dauerhaft passieren und daran
• 21:20
  denkt halt immer keiner so und. Aber da würde mich wirklich mal
• 21:24
  Hand aufs Herz interessieren, bei wie vielen Leuten das so
• 21:27
  läuft. Also ich bin da wirklich ganz
• 21:29
  bei dir und das sollte so auch sein, weil das macht dir das
• 21:31
  Leben wie gesagt langfristig auch echt besser ne, aber ich
• 21:35
  glaube, dass das selten der Fall ist, dass du so viel Zeit dafür
• 21:38
  eingeräumt bekommst. Wenn du es dir nicht aktiv
• 21:41
  nimmst und dafür kämpfst halt ne, deswegen ja dann.
• 21:46
  Muss man sich glaube ich, einfach mal hinstellen und
• 21:48
  sagen, Nein, das schaffen wir nicht, das geht nicht, ich ja,
• 21:52
  weiß ich nicht, ich bin ich, ich hab da schon so viel erlebt,
• 21:56
  dass also aber auch, also weißt du diese.
• 21:58
  Meistens hast du die Entwickler, die sagen ja, das stimmt so, das
• 22:01
  ist ja, alle sind quasi einer Meinung, nur dann kommen
• 22:03
  irgendwie sag ich jetzt mal so aus Management kreisen oder so
• 22:06
  mal blöd gesagt, weil die halt ganz andere ist ja logisch ne
• 22:10
  die haben ganz andere Blickwinkel auf die Dinge und da
• 22:14
  treffen manchmal Welten aufeinander, das ist eigentlich
• 22:18
  manchmal ganz schön. Doof, ganz schön doof.
• 22:20
  Wäre ja gut, Missverständnisse gibt es immer ne, ich würde aber
• 22:26
  sagen wir haben das ja ausführlich diskutiert, warum es
• 22:29
  wichtig ist. Und auch Vorteile genannt.
• 22:33
  Genau, ich würde sagen, lass uns die Folge hier beenden, ich
• 22:36
  denke wir haben das Refactoring ordentlich besprochen.
• 22:38
  Ja, ansonsten, wenn ihr da draußen als Zuhörerinnen und
• 22:45
  Zuhörer noch ein bisschen mehr über Factoring wissen wollt oder
• 22:47
  euch nochmal ein paar Themen interessieren, dann einfach mal.
• 22:52
  Schreibt uns einfach bei Instagram.
• 22:54
  Wie gesagt, wenn euch generell auch Themen im Podcast
• 22:57
  interessieren, einfach immer her damit wir.
• 23:00
  Gehen da gerne auf eure Wünsche drauf ein und ansonsten guckt
• 23:05
  einfach mal. Ja, einfach auf unsere anderen
• 23:08
  Plattformen, die links zu den anderen Plattformen findet ihr
• 23:10
  in den Show Notes. Vergesst nicht, den Podcast ZU
• 23:13
  liken und euren Freunden und Freundinnen zu empfehlen, falls
• 23:16
  euch. Die Folge?
• 23:17
  Gefallen hat und in diesem Sinne hoffen wir, dass wir uns beim
• 23:22
  nächsten Mal wieder hören. Und macht euch noch einen
• 23:24
  schönen Tag. In diesem Sinne eure.
• 23:26
  Cordis gemeinsam besser.