https://refactoring.guru/refactoring/smells

Matthias: [00:00:07.44] Hallo zusammen und herzlich willkommen zu einer neuen Ausgabe von der „Macht der Craft“.

Alex: [00:00:12.00] Heute haben wir euch ein neues Thema mitgebracht. Refactoring.

Matthias: [00:00:17.73] Wir haben in unseren bisherigen Folgen den Begriff schon hin und wieder benutzt, wollen dem Konzept aber auch eine eigene Folge widmen.

Alex: [00:00:23.91] Nach der Folge wirst du wissen, was Refactorings sind und welche Ziele du damit verfolgen kannst.

Matthias: [00:00:29.64] Wir wünschen dir gute Unterhaltung.

off: [00:00:34.50] Die Macht der Kraft arbeitet für dich.

Matthias: [00:00:41.75] Okay, also Refactoring wir haben es ja im Intro grad schon gehört, wir haben den Begriff schon früher öfters verwendet und bestimmt auch schon mal erklärt, aber wir wollen jetzt zu Beginn einfach noch mal kurz klären was ist eigentlich ein Refactoring? Alex, kannst du dazu etwas sagen?

Alex: [00:00:59.48] Bestimmt, – bestimmt kann ich was sagen.

Matthias: [00:01:02.72] Bestimmt.

Alex: [00:01:04.01] Bestimmt, also Refactoring. Wie du wohl sagst, haben wir schon bereits erwähnt. Das ist eine Code Änderung, die wir durchführen, ohne die Funktionalität zu beeinflussen. Ja, ohne Funktionalität hinzuzufügen oder Funktionalität rauszunehmen. Also funktional muss das Code vorher wie nachher das Gleiche machen. Während des Refactoring ändern wir aber den Code, sodass es ja anders aussieht als vorher, aber die gleiche Funktionalität beibehält. Aber warum sollten wir das tun? Na, das ist eine interessante, wichtige Frage. Wenn wir implementieren, schreiben wir Code und diese Code ist, ja – Also alle gute Entwickler, die ich kenne, sind der Meinung, dass sie nicht immer auf Anhieb die beste Code-Qualität der Welt auf die Reihe kriegen, sondern sie schreiben frei Schnauze erst mal irgendwas, was funktioniert, die die Funktionalität in sich birgt, die gefordert ist und erst danach schauen sie sich das mal an und eventuell eben gewisse Verbesserungen an den Code. Deswegen gibts während wir entwickeln so zwei unterschiedliche Sachen, die wir öfters tun. Der eine ist, den Code zu schreiben und Features zu implementieren, Bugs zu korrigieren, Performance-Maßnamen – keine Ahnung -, alles, was wir sonst für Gründe haben, unsere Code zu ändern. Und das Thema Refactoring ist für mich so eine getrennte Abteilung, in dem wir, nachdem wir diese Erstimplementierung sozusagen gemacht haben, Verfeinerungen an den Code vornehmen. Das kann man ganz gut mit TDD machen, wenn es eine neue Anwendung ist oder wenn wir neue Funktionalität hinzufügen, weil wir diese Red-Green-Refactor ganz locker flockig aus der Hüfte durcharbeiten können. Aber Refactoring ist nicht nur irgendwas, was mit TDD zu tun hat, sondern man kann es auch wunderbar verwenden, um bestehende Anwendungen Legacy Code zu erweitern oder anzupassen oder zu verändern, zu verbessern in der Qualität usw. und so fort. Also Refactoring bietet uns deutlich mehr, als wir bis jetzt gesehen haben, nämlich innerhalb des TDD Zyklus. Das einzubinden, sondern auch außerhalb von TDD hat Refactoring ein Berrechtigungsdasein und bringt uns viele nützliche Sachen. Und welche Sachen des sind Matthias? Könntest du vielleicht ein bisschen darüber sinnieren?

Matthias: [00:03:53.03] Ja, klar. Also Refactoring hat mehrere Vorteile also, bzw. er hat mehrere Ziele, die man damit verfolgen kann, nämlich zum Beispiel die Verständlichkeit des Codes einfach zu verbessern. Also soll heißen, ich habe eine Stelle im Code, die schwer verständlich ist, wo ich relativ viel Zeit investieren muss, um zu verstehen, was da gerade passiert. Das kann zum Beispiel eben auch sein. Ich muss eine neue Funktionalität irgendwo hinzufügen und finde die Stelle, wo ich das hinzufügen kann, aber ich verstehe nicht, was da passiert und dann macht es unter Umständen Sinn, vorher zum Beispiel, wenn man den Code dann verstanden hat, also einmal diesen Invest gemacht hat, den Code zu verstehen, durch Refactoring den Code so verständlich zu machen, dass wenn man danach noch mal daran vorbeikommt, man eben nicht noch einmal diese Zeit in das Verständnis der Stelle investieren muss. Und erst dann füge ich neue Funktionalität hinzu, die dann natürlich wieder im Idealfall mit TDD und da auch dann wieder mit Refactoring Schritten einhergeht. Auf der anderen Seite kann ich eben durch solche Verbesserungen eben dann auch erreichen, dass neue Funktionalitäten schneller hinzugefügt werden können, auch in bestehende Systeme. Oder es unter Umständen, wenn man eben nicht mithilfe von Refactoring dafür sorgt, dass die Codebasis erweiterbar bleibt, dass das immer länger dauert. Letztendlich ist es schneller entwickeln irgendwo eine Konsequenz aus eben zum Beispiel: Ich erhöhe die Verständlichkeit. Weil wenn ich eben diesen zeitlichen Invest, den ich eben erwähnt hab, wenn du den nicht aufbringen musst, um den Code zu verstehen, dann wirst du über die Zeit sie mehr von dem Software System eben verbessert worden ist in der Hinsicht ermöglicht es schneller zu entwickeln. Schneller entwickeln ist letztlich eine Konsequenz aus dem Refactoring.

Alex: [00:06:02.05] So weitere Sachen, die auch das Refactoring mit sich bringt, ist eines zum Beispiel, der hilft dir, Fehler zu entdecken, weil während du refactorst, fallen dir eventuell Sachen auf, an die du vorher nicht gedacht hattest. Weil jetzt der Code anders aussieht. Und somit kannst du manche Fehler entdecken, an denen du vorher nicht gedacht hattest. Oder irgendwelche Konstellationen, die vorher du nicht halt gesehen hattest. Weil der Code so aussah, wie es aussah. Und da schien es nicht notwendig, an sowas zu denken oder einfach nicht daran gedacht haben. Deswegen hilft es auch, einige Fehler ausschließen zu können, damit wir ordentlich refaktorieren können, was wir bis jetzt noch nicht erwähnt hatten, – bedeutet für mich, dass wir Tests haben müssen. Es müssen Tests da sein, die die derzeitige Funktionalität abdecken, – zumindest größtenteils abdecken -, sodass wenn ich meine Refactorings mache, wenn ich meine Änderungen durchführe, ich auch irgendwie überprüfen kann, dass ich die Funktionalität tatsächlich nicht verändert habe.

Matthias: [00:07:17.75] Nee, also Tests, klar, die sind da eine Voraussetzung, weil ich kann ja nicht einfach meinen kompletten Code verändern und hoffen, dass alles so funktioniert wie davor. Also klar, sehe ich haargenau so

Alex: [00:07:33.22] Okay, super. Eine ganz andere Sache. Die die mit Refactoring ganz gut machen können ist: Es gibt Entwicklungsvorgehen, in dem man sich bevor man anfängt zu programmieren, so tagelang, wochenlang, monatelang Gedanken darüber macht „Was ist der optimale Design für diese Anwendung?“ Nicht nur wie die auszusehen muss, sondern wie es architektonisch aufgebaut werden soll. Und weiß Gott was alles da an Hirnschmalz rein fließt? Ich will nicht sagen, dass das schlecht ist. Um Gottes Willen. Es gibt aber auch andere Möglichkeiten, die Sachen oder diese Sache anzugehen. Es gibt auch Menschen, die sagen, man braucht überhaupt kein Design vorab. Kein gar nichts, keine Gedanken einfach anfangen. Und mit der Zeit ergibt sich diese Design von unsere Anwendung schon von alleine, wenn wir entsprechende gute technische Methoden bei der Entwicklung verwenden. Ich bin irgendwie für ein Mischmasch von den Sachen, nämlich dass man sich kurz Gedanken darüber macht, was für ein Design man anwenden möchte. Heißt nicht ins Detail gehen, aber eine grobe Übersicht, wo wir sagen können: „Ja, damit können wir anfangen.“ Damit sehen wir einen Weg, wie wir unseren Fall oder unsere Anwendung durchexerzieren können. Und diese kleine anfängliche Design ist für mich völlig okay. Danach aber ist mein Tool für den Design der Anwendung des Refactoren. Nämlich ich implementiere was auch immer für ein Feature und dann bringe ich es in die richtige Form mit dem richtigen Design, mit dem richtigen Pattern, mit was auch immer, in den ich kleine oder nicht so kleine Refactorings mache, so dass dank meine Tests weiß ich, ich habe nichts kaputt gemacht. Aber nach und nach durch diese Refactorings kann ich meine Anwendung auch so aussehen lassen, das, wie du gesagt hast, verständlicher ist, weniger Fehler drin stecken, dass auch schneller neue Funktionalität hinzugefügt hat, weil alles verständlich, weil alles ordentlich, weil es getestet ist. Du verstehst, was ich meine?

Matthias: [00:09:59.63] Ja klar, genau. Ich sehe es auch ganz ähnlich. Also ich will auch nicht gar keine Idee vorher haben, wo die Reise hingehen soll. Aber ich will halt auch nicht festgezurrt sein, „Alles muss vordefiniert sein.“ Also bin ich auch kein Freund von. Also Design on the fly ist eine gute Sache, die ich auch sehr gut find.

Alex: [00:10:20.82] Aber wie gesagt, net ist Design on the fly bedeutet nicht, dass man oberhalb sich keine Gedanken macht, bevor man anfängt zu coden, sondern dass diese anfängliche Aufwand relativ klein ist und sich in Grenzen hält. Es geht darum, gewisse Rahmenbedingungen zu setzen, wie ich meine Anwendung implementieren möchte und nicht alles im Detail vorab zu planen. Aber gut, wann sollten wir refactoren? Refactoren ist eine tolle Sache. Okay, ganz schön und gut. Aber wann sollen wir refactoren? Können wir jederzeit refactoren? Oder gibt es bestimmte Zeitpunkte, wo es sich anbietet? Oder gibt es bestimmte Zeitenpunkte wo lieber nicht. Was denkst du?

Matthias: [00:11:05.41] Also, wovon ich abraten würde, – was ich schon mitgemacht habe und keine guten Erfahrungen damit gemacht habe -, sind Refactoring-Sprints also wo wirklich ein gesamtes Team einfach drauf angesetzt wird, irgendeinen Teil zu refaktorieren, sondern ich würde es tatsächlich immer eher situationsbedingt machen, was auch mehr eben dem eben angesprochenen Design on the fly irgendwo entspricht. Also des heißt, ich muss irgendeine Änderung im Code vornehmen, das kann zum Beispiel ein neues Feature sein, oder es kann auch ein Bug sein, der aufgekommen ist. Würde den Code mir entsprechend angucken, wo dieses Feature ungefähr landen würde oder wo der Bug verortet ist und würde dort schauen, ob ich Stellen identifizieren kann, die, wenn sie anders aussehen würden, mir die Arbeit leichter machen würden. Und wenn ich solche Stellen finde, dann würde ich diese dann in dem Zuge erst mal refaktorieren bevor ich neue Funktionalität hinzubringen. Also das wäre so mein Ansatz.

Alex: [00:12:13.75] Ich muss dazu sagen, – ich gebe dir recht, völlig, völlig in Ordnung. Aber für mich gibt es zwei unterschiedliche Arten, wie ich refaktoriere. Die eine ist, wenn ich eine neue Anwendung schreibe oder ein neues Feature. Während ich dieses neue Feature schreiben, zum Beispiel mit TDD, dann gibt es gewisse Schritte, die diese Refactoring mit einbeziehen und diese Refactoring machen. Es gibt aber auch der Fall: „Ich habe eine Legacy Anwendung und ich muss da was verändern.“ Und da setze ich dann ein, was für mich sich als gut erwiesen hat ist, ich muss, bevor ich was ändere, verstehen, was bis jetzt passiert. Und wie du gesagt hat, wenn ich das verstanden habe, kann ich eventuell einen besseren Weg finden, das zu machen. Und wenn ich die entsprechenden Tests habe, kann ich das auch machen. Da mache ich dieses Refactoring, die mir vereinfachen soll, dieses neue Feature hinzuzufügen oder dieses Bug zu korrigieren oder was auch immer. Also schon endlich finde ich, wie du das beschrieben hast. Aber wie gesagt, ich setze diese Unterscheidung. Ja, es ist entsteht irgendeine neue Anwendung gerade, die ich zum Beispiel mit TDD entwickeln kann? Oder habe ich einen Legacy Code, da ich schon da ist? Und muss ich den anpassen? Und das sind für mich die zwei Bereiche in der Refactorings wirklich Stärken spielen können.

Matthias: [00:13:45.50] Ja, aber letztendlich ist es doch – Also wenn ich in Legacy System irgendwie anpassen muss, das könnte doch auch jetzt in einer, also in deiner Anwendung, wo du vorher beschrieben hast mit der dem neuen Feature könne ja auch ein Bug sein. Also im bestehenden Code einfach.

Alex: [00:13:59.35] Natürlich.

Matthias: [00:14:00.31] Und also klar, das sind TDD ist für mich der Refactoring Step natürlich unangetastet drin, keine Frage. Da habe ich quasi implizit mit angenommen, weil ich persönlich einfach nach TDD gerne arbeite und das dann auch entsprechend durchzieh. Ich wollte im Prinzip einfach nur, was ich herausstellen wollte war im Prinzip, dass man eben, bevor man Änderungen am Code, eben neues Feature oder einen Bugfix oder was auch immer macht, dass da ein geeigneter Zeitpunkt ist, um bestehenden Code zu Refaktorieren. Weil dann habe ich ja noch meine grünen Tests, da kann ich Vorbereitungen treffen, um eben dann die Lösung meiner Aufgabe besser zu gestalten. Das ist die Lösung der Aufgabe, dann letztendlich wieder mit TDD und somit auch wieder mit Refactoring einhergeht das ja, das ist korrekt.

Alex: [00:14:57.82] Okay, okay, also redeten wir eigentlich schon immer das Gleiche.

Matthias: [00:15:01.36] Genau.

Alex: [00:15:02.47] Alles klar. Code Smells.

Matthias: [00:15:06.63] Ja, die guten Code Smells, das ist ja letztendlich das, was ich vorhin auch so ein bisschen angedeutet hab mit „Stellen im Code identifizieren, die sinnvoll wären zu verbessern“. Also Code Smells, da gibt es ja letztendlich eine ganze Reihe. Da habe ich sogar mal eine Seite rausgesucht, die ich da recht gut fand den Refactoring Guru. Der hatte eine sehr spezielle, eine sehr schöne Übersicht. Das können wir dann mal verlinken, weil der hat es ganz schön unterteilt in Kategorien und dann noch mal unterteilt in eben die einzelnen Code Smells, wie die sich äußern. Und wenn man da mal drauf schaut, da kann man glaube ich ganz viel lernen. Aber genau das sind letztendlich eben so typische Muster, die man eben – ja wie soll man sagen -, wenn man sich die Literatur dazu anschaut als refactoringwert vorstellt. Also macht es Sinn mal drüber nachzudenken, die zu ändern, weil sie eben zu besserer Erweiterbarkeit des Codes, zu bessere Handhabung des Codes führen.

Alex: [00:16:13.16] Ein Okay so Code Smells bedeutet wortwörtlich stinkenden Code sozusagen oder Code der riecht. Und ja, wie du gerade erwähnt hast, da gibt es eine ganze Latte davon könnt ihr wie gesagt im Netz oder in den Links, die wir unten posten, mal anschauen. Und das sind auch eine gute Gelegenheit zu refactoren. Also diese Probleme sich anzunehmen und die Qualität unserer Codes zu verbessern, indem wir diese Codesmell einfach entfernen.

Matthias: [00:16:45.15] Genau. Also man könnte im Prinzip sagen, dass wir vor der Änderung von Code, sei es nur als Feature, sei es Bugs als Hotfix an den entsprechenden Stellen eben nach Code Smells Ausschau halten. Und wenn wir welche finden, sind es die Kandidaten, die wir vor dem Feature refaktorieren können.

Alex: [00:17:03.71] Machen wir, – oder mache ich – auch tatsächlich öfter so Refactoring Sprints, halte ich auch nichts davon. Nichtsdestotrotz.

Matthias: [00:17:15.11] Es gibt sie.

Alex: [00:17:17.67] Ja, die gibt es. Aber wo ich hinwollte, ist zu unserem nächsten Thema Refactoring versus Rewrite. Wenn ich eine Anwendung anpassen muss. Es ist öfters der Fall, vor allem wenn ich im Legacy Bereich arbeite, dass ich sehr viele Refactorings machen will. Also bin ich eine Legacy Anwendung modernisieren oder anpassen will. Das haben wir, als wir das Thema Legacy angesprochen haben, schon mal gesehen. Tests müssen da sein und dann verändere ich den Code ohne die Funktionalität zu verändern, die da war. Und es ist nichts anders als Refektorings zu machen.

Matthias: [00:17:57.83] Ja genau.

Alex: [00:17:58.64] Und dann kann es durchaus sein, dass das ganze Sprint daraus besteht. Meine Anwendung von Zustand A zu Zustand B zu bringen. Und das bedeutet, dass wir die ganze Zeit nur irgendwelche Refactorings machen. Das wurde ich aber nicht als ein Refactoring Sprint in dem Sinne definieren, sondern eben als die geeignete Vorgehensweise, um eine Legacy Anwendung von Zustand A ins Zustand B zu versetzen. Was denkst du?

Matthias: [00:18:27.76] Ja, es ist halt tatsächlich. Ich glaube, das ist dann recht spezifisch. Das kommt dann natürlich auch immer auf das entsprechende System an. Wie verbaut ist es und überhaupt? Also ich glaube, da kann auch vorher noch ganz kurz drüber sprechen, warum überhaupt manchmal diese Entscheidung getroffen werden muss. Weil es kommt ja auch nicht grundlos, dass man sich denkt Oh, es wäre jetzt vielleicht besser, die ganze Anwendung neu zu schreiben, sondern es passiert ja im Prinzip meistens, weil irgendwie das Hinzufügen neuer Funktionalitäten sehr, sehr lange dauert oder das Fixen von Bugs zu neuen Problemen führt. Also das ist so eine endlos Spirale ist die Entwicklungskosten explodieren, es wird immer teurer alles. Und dann steht man ja vor der Entscheidung: „Was mache ich?“ Da ist glaube ich das Hauptproblem, das man sehr häufig das Refactoring über den Lebenszyklus von so einem Projekt vernachlässigt, bis man irgendwann an den Punkt kommt, wo es weh tut und dann denkt man sich „Ja aber das ganze jetzt zu refaktorieren, das ist ja unglaublicher Schmerz, da schreibe ich es doch lieber neu“ und das ist halt irgendwie in meinen Augen das Hauptproblem. Also man sollte es in meinen Augen gar nicht so weit kommen lassen, dass man diese Entscheidung treffen muss. Und wenn man bei einem Legacy System vor der Entscheidung schon steht, weil man jetzt keine Ahnung dieses System geerbt hat, man muss damit klarkommen, dann stellt sich halt immer die Frage wie groß ist der Bereich, den ich refaktorieren muss, um jetzt zum Beispiel eine neue Funktionalität hinzuzufügen? Also wenn sich das ganze System mit Händen und Füßen gegen eine Änderung wehrt, dann gebe ich dir vollkommen recht. Dann kann es absolut Sinn machen, einen Sprint oder vielleicht auch noch längere Zeit dafür in Anspruch zu nehmen, um dieses System von diesen Ausgangszustand in einen gewissen Zielzustand zu bekommen. Aber es ist halt eventuell auch durchaus möglich, das mit sehr vielen kleinen Refactoring über einen Zeitraum hinweg zu schaffen. Aber wie gesagt, ich glaube, das steht und fällt mit dem Zustand des Systems, an dem man arbeiten muss.

Alex: [00:20:39.81] Okay, dann widmen wir uns mal wieder dieses Thema Refactoring vs. Rewriting, wie du wohl gesagt hast. Manchmal steht man vor dem Code und sagt „Nein, das kann ich nicht warten. Damit kann ich nicht arbeiten. Das schreiben wir jetzt neu.“ Ja, das ist nicht immer der richtige Weg.

Matthias: [00:20:59.91] Ja, genau. Es ist nicht alles Gold, was glänzt sozusagen.

Alex: [00:21:04.32] Aber sei dahingestellt. Warum denkst du, sind viele Entwickler geneigt, einfach neu zu schreiben, anstatt zu refaktorieren?

Matthias: [00:21:16.53] Naja, also ich glaube, der Hauptgrund ist, dass wir natürlich häufig vielleicht der Meinung sind, dass wenn wir das jetzt neu machen, wir das natürlich alles besser machen als es vorher war. Also kurz gesagt, wir lieben die grüne Wiese. Also wir fangen gerne etwas neu an. Wir, weil wir machen natürlich auch alles richtig, ist ja eh klar. Und deswegen sind wir der Meinung, das neu zu machen wäre die bessere Entscheidung, weil dann bin ich sicher, ich habe das gemacht. Also ich hoffe, man hört den Sarkasmus raus und deswegen kann es nicht falsch sein. Und ich glaube, das ist so ein bisschen der Grund. Ich kenne es von mir selber auch. Ich tendiere auch erst mal irgendwo im Kopf erst mal dazu, eventuell zu sagen, es wäre jetzt viel schöner, wenn ich das einfach neu machen könnte. Aber da spricht halt in meinen Augen zu viel dagegen, dass einfach in vielen Fällen spricht zu viel dagegen für mich. Also da muss schon ein System ganz schön als ganz schön weit kaputt sein, das ich sage Ja, ich unterschreibe das ein Rewrite die einzige Möglichkeit ist

Alex: [00:22:30.45] Was sind Gründe für mich, die ein Rewrite ermöglichen oder eher den Vorzug geben? Entschuldigung, aber wenn die Anwendung einfach Schrott ist, wenn die einfach nicht funktioniert, wie es funktionieren soll, dann kann es manchmal durchaus besser sein, esneu zu schreiben als diese alte Zeug, die, die gar nicht funktioniert, wie es soll versuchen auf die Reihe zu kriegen. Ich sage bewusst kann es nicht, muss und kann es. Aber es ist ein Grund, wo ich mir dann Gedanken darüber machen, ob es vielleicht sich eine Neuausschreibung nicht nicht besser rentieren würde.

Matthias: [00:23:08.55] Also meinst du jetzt zum Beispiel sowas wie vollkommen veraltete Technologie, die nicht mehr supported wird von zum Beispiel Herstellern. Und dass es dann Sinn macht, das System neu zu machen. Oder ist das für dich noch mal was anderes?

Alex: [00:23:24.87] Das meinte ich nicht, aber das ist ein andere Grund, warum eine Neuausschreibung eventuell sich rentieren muss. Auf Sicherheitsgründen zum Beispiel, weil Sachen nicht mehr gewartet werden und entsprechende Sicherheitslücken entdeckt werden und so weiter und so fort. Das ist tatsächlich eine der anderen Möglichkeiten, warum es eventuell eine neue Schreibung sich rentieren könnte. Aber das ist nicht alles positiv. Also ich meine, wenn der Code, die wir jetzt schon haben, funktioniert, es funktioniert und es bringt was zum Umsatz des Unternehmens, weil er läuft und unsere Kunden nutzen sie, dann ist eine Neuschreibung ohne einen triftigen Grund, wie gesagt, für mich nicht notwendig. Dann ist es, finde ich besser, die bestehende Anwendung zu refaktorieren, zu erweitern und nicht eine neue zu schreiben

Matthias: [00:24:19.02] Oder was ja auch ein Weg sein kann Teile. Wie soll man sagen, ist nach und nach Teile rauszuziehen aus dem alten System und ein zweites System parallel, das halt die Funktion, die du aus dem einen raus nimmst, zum anderen bereitstellen. Sozusagen wäre er auch noch irgendwo denkbar.

Alex: [00:24:37.98] Ist auch eine Möglichkeit. Vor allem hat das Thema Neuausschreibung ein bisschen ein Geschmäckle. Und zwar diese Neuschreibung bedeutet ich habe vor, eine gewisse Zeit und normalerweise ist es keine kleine Zeitspanne, habe ich zwei Anwendungen, die ich warten muss und die ich betreiben muss die alte Anwendung, die noch da ist, wo ich nichts mehr ändere. Aber die ist da, die muss noch laufen. Ich muss gegebenenfalls noch irgendwelche Fixes machen, weil das notwendig ist. Und ich muss neben an noch parallel an eine neue Anwendung arbeitet, die eventuell diese total hässliches Wort für mich, diese 1:1 Umstellung von von Alte in neu macht.

Matthias: [00:25:26.31] Ja. Und im besten Fall hast du dann auch zwei Teams, also doppelte Kosten – Enwicklungskosten sozusagen.

Alex: [00:25:32.40] Am besten reden sie nicht miteinander. Ist auch

Matthias: [00:25:35.43] Ja gut. Nee, und es kann ja auch genauso gut sein, dass irgendwie vom Business ganz wichtige Features kommen, die trotzdem noch in das alte System rein müssen. Das heißt, dann müssen die Funktionalitäten zweimal implementiert werden bzw. wahrscheinlich beim neuen System dann irgendwann erst am Ende, weil das kommt halt dann irgendwie auf die To do Liste, was alles mal rein muss. Aber ja. Nee, als des halte ich auch für für schwierig, weil das ein Rewrite oder das ein Refactoring oder ein Rewrite überhaupt in Frage kommt, da gebe ich dir vollkommen recht, muss das System produktiv laufen, es muss irgendeinen Wert liefern. Und deswegen ja, wenn da dann ein Rewrite gemacht werden soll, dann muss da schon wirklich ganz viel Grund dafür da sein.

Alex: [00:26:32.18] Okay, finde ich auch, weil es ist ja öfters mit deutlich mehr Arbeit verbunden, als Refactoring zu betreiben. Auch wenn man auf den ersten Blick des Refactoring kompliziert zu scheinen mag, weil wir die Codebasis nicht kennen, weil was auch immer. Aber gut, das sage ich, der muss halt durch. Junge, musst du dich mal anschauen, was der Code macht Tests schreiben, wo Tests noch nicht vorhanden sind, um wirklich zu checken, dass die Anwendung auch das tust, was du denkst, dass es tut. Wenn du das hast, dann kannst du anfangen zu refaktorieren und die Anwendungen anzupassen. Und das ist nicht immer die schlechte Lösung ist sehr oft die bessere Lösung für eine Neuausschreibung bitte nur, wenn es wirklich wichtige, gewichtige Gründe dafür gibt. Ja, weil eine Software, die da ist, die schon Wert für das Unternehmen stiftet. Einfach grundlos zu ersetzen und durch eine neue, die eigentlich das gleiche machen soll, halte ich für nicht so klug.

Matthias: [00:27:46.48] Ja genau, weil bis die auch irgendwann Mehrwert liefert, wird erst mal ordentlich Entwicklungsgeld reingesteckt.

Alex: [00:27:53.05] Vor allem es kann auch passieren, dass du eine Menge Fehler rein baust in der neue Anwendung, die in die alte noch gar nicht vorhanden war.

Matthias: [00:28:02.92] Weil Zeitdruck, weil muss ja ganz schnell fertig sein.

Alex: [00:28:06.38] Wie auch immer. Und weil wir auch nur Menschen sind und auch Fehler machen. Das ist völlig normal. Aber man muss halt damit rechnen, dass es da als Fehler und Probleme geben wird. Und deswegen sage ich Es ist eine Entscheidung, die sehr gut abgewogen werden möchte. Ich würde tendieren zum Refactor, soweit es möglich ist, um bei uns unserer Meinung nach keine andere mögliche Lösung als eine Neuschreibung da ist, ja mein Gott, sei so aber immer begründet.

Matthias: [00:28:44.38] Ja, alles eine abschließende Botschaft.

Alex: [00:28:47.32] Ja, also das wäre es tatsächlich gewesen.

Matthias: [00:28:51.12] Naja, also ich hätte auch noch mal eine Botschaft und zwar was ich auch vorhin schon mal gesagt habe, was glaube ich ganz wichtig ist: Lasst es gar nicht so weit kommen, dass die Entscheidung zwischen Refactoring und Rewrite getroffen werden soll, sondern schaut, dass ihr euch Refactoring so einverleibt, dass es einfach in eure täglichen Arbeit ganz normal dazugehört. Und damit wären wir dann auch schon am Ende unserer Folge.

Alex: [00:29:18.92] Ja, heute hast du viel über Refactoring gehört und was du damit erreichen kannst.

Matthias: [00:29:24.25] Es wird dir helfen, sowohl bei der Neuentwicklung mit TDD als auch natürlich bei der Überarbeitung von bestehenden zum Beispiel Legacy Systemen. Also Du wirst es auf jeden Fall zu schätzen wissen.

Alex: [00:29:36.01] Danke, dass du die Folge angehört hast und denke daran, den Podcast zu abonnieren, falls du es noch nicht gemacht hast.

Matthias: [00:29:43.24] Wir würden uns auch freuen, wenn du unseren Podcast anderen Menschen empfehlen würdest, die auch davon profitieren könnten.

Alex: [00:29:50.57] Aber. Was kannst du machen, wenn du wissen möchtest, was man alles in den geheimen Taschen des Werkzeugs Gürtel eine Softwareentwicklern zu finden ist?

Matthias: [00:30:02.84] Natürlich kannst du einfach die nächste Folge anhören, weil genau darüber wollen wir dann sprechen.

Alex: [00:30:07.80] Ciao.

off: [00:30:10.72] Die Macht der Kraft arbeitet für dich.