Refactoring von Martin Fowler - Ein Überblick

[@DavidTielke]

Wie immer interessiert mich: Wie steht Ihr zum Thema Refactoring? Wie geht ihr da ran? Was vermeidet ihr und welche Erfahrungen habt ihr damit gemacht? Und wie immer: wenn Euch das Thema interessiert, helft mir und unterstützt den Kanal mit Likes und einem *Abo* - Danke!

[@NordmannDK]

Ich lerne seit ca. einem Jahr, da ich Softwareentwickler im .net Bereich, als Quereinsteiger werden will. Die Softwarequalität hat bei mir schon sehr früh einen hohen Stellenwert eingenommen. Ich bin wirklich froh, dass ich deinen Kanal gefunden habe, der dieses Thema so praxisnahe und ausführlich behandelt. Vielen Dank, soetwas ist in Büchern schwer zu finden.👍 ...Und das Buch würde mir natürlich auch sehr gut weiterhelfen.😉

[@DavidTielke]

Hallo Michael, vielen Dank, das hört man gerne - viel Erfolg dabei! Gruß David

[@marcusreinicke]

Hallo Michael, bei David bist Du gut aufgehoben. Es macht jedesmal Spaß und gelernt habe ich schon sehr viel

[@razielstriker564]

Hey David. Ich finde, das Video ist bisher dein bestes. Es ist klar strukturiert, einfach verständlich, nicht zu lang, wird von Grafiken unterstützt und hat ein gutes Timing. Vielen Dank dafür! Ich verargumentiere ein (größeres) Refactoring meist mit einer Überarbeitung der Oberfläche. Z.B. Dark-Mode Unterstützung oder Accessibility-Verbesserungen. Wenn wir sowieso fast den ganzen Quellcode anfassen müssen dann kann man soetwas ganz gut gleich miterledigen.

[@DavidTielke]

Hey, vielen Dank, freut mich sehr das Dir das Video so gut gefällt - danke für das Feedback! Hmm klingt gut und wenn es nur eine Struktur "unten-Drunter" ist? Verkaufst Du es dann auch in einem UI-Umbach gleich mit? Gruß David

[@maestro4735]

Bei uns ist (aktuell) der beste Grund die Testbarkeit. Wir hatten bisher die Testabdeckung nur stiefmütterlich betrachtet. Natürlich wird jetzt immer deutlicher wie wichtig automatisierte (Unit)Tests werden. Hierfür ist aber meist ein Refactoring nötig, um z.B. Interfaces zu implementieren und DI + SRP zu berücksichtigen... Ich schwärme schon dauernd von deinen Videos in unserer "Kaffeeküche" ;-) Super Kanal!

[@DavidTielke]

Hey Michael, danke für das Feedback - schön wenn Dir die Videos gefallen :) Ja, das mit der Testabdeckung in meinem Quellcode ist auch immer so ein leidiges Thema.... ;) Gruß David

[@heischono4917]

Danke für das Video. Ich habe kein Hauptargument. Teilweise mache ich kleine Refactorings ungefragt, in anderen Fällen überlege ich was das beste Argument für genau dieses Projekt ist. Da ich viele Projekte völlig alleine mache, passiert es doch öfters dass ich ein Feature einfüge und gleichzeitig noch ein Refactoring mache. Das gab noch nie Probleme, aber es ist logisch dass das bei Teams etwas anders aussieht 😁

[@DavidTielke]

Hey, da bist Du aber in einer glücklichen Situation - freut mich :) Gruß David

[@IxFreeZe4TW]

Da ich noch nicht die ganzen coolen Entwurfsmuster aus dem Buch kannte und ich nun viele Teile der Anwendung deutlich eleganter und robuster erstellen kann, wäre ein refactoring eine gute Idee 😂 Super Video, der Klassiker von Fowler steht nun auf meiner Leseliste 😊

[@DavidTielke]

Hey, sehr gute Antwort :D Das überzeugt Deinen Chef? :D Das ist zwar ein recht altes Buch, aber immer noch eins meiner Lieblingsbücher :) Gruß David

[@daomonkcoder]

Herzlichen Dank für das Video.

[@DavidTielke]

Hallo, sehr gerne, schön wenn es Dir gefällt und Dich hoffentlich beim Refactoring weiterbringt :) Gruß David

[@davidmuller6723]

Für uns ist die Testbarkeit das non-plus-Ultra. Wir legen viel Wert auf Unittests und wenn’s nicht testbar ist, wird es refactored. Wir hatten zuletzt auch die Diskussion mit unserem PO und nach kurzer Diskussion zeigte er vollstes Verständnis und stärkt uns den Rücken

[@DavidTielke]

Hey Namensvetter, sehr cool, glückwunsch zu dem PO :) Hat der zufällig Geschwister? :D Gruß David

[@binaercoder]

Wer das hier sieht kennt deine videos und deren qualität oder er fühlt sich gezwungen informationen zu besorgen . Bei mir trifft beides zu 😀😔 auf jeden fall wieder Klasse Arbeit und danke für das Video

[@christianhuber4048]

Hab das Buch schon....😁 Das Video hat mir gut gefallen

[@DavidTielke]

Sehr gut, hilft es denn beim Refactoring? Gruß David

[@christianhuber4048]

@@DavidTielke Entwurfsmuster helfen auf jeden Fall, guten Code zu schreiben...vor und beim Refactoring

[@martinbernasconi9208]

"Ein Refactoring ist nötig, weil der Code 10 Jahre alt ist, ich damals noch nichts über Softwaredesign wusste, der Code entsprechend schlecht strukturiert und damit nicht so erweiterbar ist, wie ich es für das neue Feature XYZ brauche." Normalerweise faktorisiere ich dann einfach, wie von dir beschrieben, wenn das neue Feature eingebaut wird. Glücklicherweise besteht aber auch seit Jahren eine gute Testbasis für die mir verantwortete Komponente, so dass die Validierung nach dem Umbau kein Problem darstellt. An dieser Stelle möchte ich eine Lanze für Komponenten-Tests (und Tests im Allgemeinen) brechen: es lohnt sich immer! Die Sicherheit, keine Seiteneffekte erzeugt zu haben, die Ruhe, die man hat, weil sich keine Kunden beklagen, und die Zeit, die man spart, weil keine endlosen Debugsessions nötig sind, da die Fehler schon während des Testens aufgetreten sind und die Ursache meist offensichtlich ist, sind viel mehr wert, als die Zeit, die man für das stetige Erweitern einer Testbasis investieren muss! Danke David für die Auffrischung! 😉

[@DavidTielke]

Hey Martin, genau das meinte ich mit "ehrlich und offen" - sehr gutes Beispiel :) Was das Testen angeht: Glückwunsch! und ja, bin ich total bei dir. Das Problem ist, dass diese meist im Betrieb weniger Benefit versprechen (weil komplizierter zu erstellen) als Unit-Tests einer klasse. Wenn Du sie aber hast, ist das Refactoring wirklich super umsetzbar und es kann eine ganze Menge an Kopfschmerzen ersparen! Sehr gerne, danke für Dein Feedback! Gruß David

[@marcusreinicke]

Hallo David, ich konnte ne Zeit nicht folgen. Von meiner Seite noch mal herzlichen Glückwunsch zur Masterarbeit. Tolles Video - ganz richtig. Technische Schulden Wie wird es im Buch - der Pragmatische Programmierer beschrieben: Software Entropie (ich habe das Wort schon in der Physik geliebt) "Die Software vergammelt. Manche nehmen hier den etwas optimistischeren Begriff technische Schulden und implizieren damit, dass diese Schulden eines Tagen beglichen sind. Sie werden es wahrscheinlich nicht. Mein Hauptargument ist eigendlich das Thema Geld. Je schlimmer die Softwarestruktur, desto größer die Wartung. Je schlimmer die Softwarestruktur, desto größer ist der Aufwand, neue Feature einzubringen. Je schlimmer die Softwarestruktur, desto schwieriger und länger, dauert eine Einarbeitung. Und all diese Punkte kosten Geld u.u. sehr viel Geld. Nur hören tut man nicht auf mich🙃 LG Marcus

[@DavidTielke]

Hallo Marcus, vielen Dank :) Sehr gut formulierte Argumentationskette - gefällt mir! Gruß David

[@marcusschone296]

Schönes Video was genau zeigt, was erst einmal benötigt wird, um ein Refactoring durchführen zu können - wäre das Video mal 2 Jahre eher gekommen. Wir haben ein Refactoring ohne Unit Tests und genaue Anforderungen gemacht ... Ergebniss ... Nach dem refactoring ist vor dem refactoring :(

[@DavidTielke]

Hallo Marcus, habe mich selbst gefragt, warum es dazu noch kein Video gibt - habe Refactoring als Thema schon seit Jahren auf dem Zettel aber nie gemacht. Aber Du hast total recht "Nach dem Refactoring ist vor dem Refactoring" - der Satz hätte definitiv in das Video gehört :D Gruß David

[@guidoerfen7944]

Extra schwierig kann es werden ein Refactoing durchzusetzen, wenn Softwareentwicklung nicht das Kerngeschäft des Arbeitgebers ist und das Entwicklerteam klein ist. Hochdeutsch reden hilft, DEnglisch-Jargon weniger. Etwa: "Das hatten wir damals in Eile umgesetzt. Da ist jetzt viel Kuddelmuddel drin. Wir müssten da dringend mal aufräumen." 1. Bei jeder Gelegenheit den Bedarf wiederholen: "Wir müssten da ja auch mal dringend aufräumen." 2. Wenn an den entsprechenden Stellen neue Funktionalität implementiert werden soll, dann das Refactoring einfordern: "Wir müssen vorher aufräumen, sonst gibt das nur noch Krautr und Rüben." 3. Refactoringsbedarf vorher ankündingen, wenn Technical Debt im Anzug ist. Etwa wenn "schnell mal" was umgestzt werden soll. Technical Debt würde ich nicht mit "Schuld" sondern mit "Schulden" übersetzen, wie bei einem Bankkonto.

[@DavidTielke]

Hey Guido, ah, die Nervensägentaktik - sehr gut :) Aber besonders mit dem "nicht das Kerngeschäft" hast du vollkommen recht. Das ist die korrekte Übersetzung, das stimmt - eigentlich wollte ich von Schulden auf Schuld überleiten - das hab ich leider versaut und es ist mir beim Schneiden nicht aufgefallen :) Gruß David

[@markuskruger1889]

Wir haben, entgegen des Testpyramide tatsächlich unseren Fokus rein auf automatisierte UI Tests gelegt, trotz längerer Laufzeit und höherem Wartungaufwand. Bei jedem Feature und Bug werden also UI-Tests nach besten Wissen und Gewissen geschrieben ohne auf Testabdeckung zu achten. Klar rutsch das ein oder andere mal durch, aber wo tut es das nicht ;-) Allerdings ist es dadurch nun so, dass wir uns aus unserer Erfahrung damit nun voll auf unsere Tests verlassen können. Dies bedeutet, dass wir ohne weiteres einfach Refactorings machen, auch sehr große, und sehen beim nächsten Testdurchlauf direkt, wo wir mist gebaut haben und sich etwas anders verhält als erwartet. Ohne diese Tests, wie dies Teilsweise durch Consultants bei Kundenspeziefischen Erweiterungen gemacht wird, würde wir durchdrehen und nichts mehr anfassen wollen, denn nur durch Refactorings kann man Code und ganze Strukturen verbessern und neuen Anforderungen gerecht werden.

[@17plus9]

Die Neuentwicklung ist das beste Refactoring.

[@biask89]

Moin David, ich konnte tatsächlich schon mit dem Argument überzeugen, dass ich neues Wissen über Softwarearchitektur mit einem Refactoring verinnerlichen will, um dieses Wissen in zukünftige Projekte mit einfließen zu lassen. Hintergrund: - ein älteres, aber solides Projekt, dass ich zu meiner Anfangszeit der Programmierung umgesetzt habe - viel technische Schuld durch Unwissen, dass produktive Programm lief, war/ist schnell und bugfrei, aber war nicht sehr wartungsfreundlich - da es mich immer gewurmt hat, was mein Vergangenheits-Ich da angestellt hat, habe ich mir Gedanken gemacht, mit welcher Begründung ich diesen innerlichen Ärger loswerden kann

[@DavidTielke]

Hey Bias, klar, das ist natürlich auch ein Aspekt des Refactoring und cool wenn Dein Vorgesetzter Dir das einräumt - oftmals wissen die selbst, dass Du für eine Tätigkeit nicht ausreichend ausgebildet warst und unterstützen das iterative lernen. Die Frage ist (zumindest bei mir) immer, ob man danach dann für immer zufrieden ist mit dem umgebauten Quellcode? Gruß David

[@biask89]

@@DavidTielke Schöne Frage und ja, da triffst du natürlich einen Nerv. Wenn es nach mir geht, würde ich natürlich immer weiter optimieren und machen und tun, gleichzeitig bin ich aber realistisch genug, um zu wissen, dass am ende des Tages die angewandten Maßnahmen dem Projekt gerecht werden müssen und nicht anders herum. Am Ende habe ich einen Monolithen mit vielen Kommentaren, die den Code erklären … in Mehrschichten verwandelt, die sich selbst erklären und damit bin ich vorerst zufrieden und der Code ist jetzt so flexibel, dass er bei Bedarf unkompliziert angepasst werden kann. Danke übrigens für dein Buchtipp „Effektive Softwarearchitekturen: Ein praktischer Leitfaden“, bin zwar noch nicht durch, aber es öffnet ganz schön die Augen^^ Viele Grüße

[@DavidTielke]

Ja, ich denke das geht jedem so :) Ein Zwischending ist immer super! Finde das Buch auch echt klasse, da kann man auch nach 15 Jahren in dem Geschäft noch etwas dazu lernen :) Hab noch 2 oder 3 andere gute Bücher, hoffe zu dem Video komme ich die Tage mal. Gruß David

[@Tiriondil]

In meinem aktuellen Projekt habe ich es mit Legacy-Code meines Vorgängers zu tun, der einige Bugs zusätzlich beinhaltete. Während der Bugfixes bemerkte ich, dass ich bestimmte Dinge deutlich anders machen würde, und so schrieb ich während der Bugfixes den Code zusätzlich um. Außerdem waren bestimmte Verhaltensweisen nicht klar definiert zuvor; in Absprache mit dem Kunden vereinheitlichten wir das dann, spezifizierten also gewissermaßen nach. Das Refactoring bezog sich also auf bestimtme Dateistrukturen, die Programmstrukturen und eben die Bugfixes sowie die mit dem Kunden besprochenen Verhaltensanpassungen.

[@breakerx6212]

Durch neue Erfahrungen, alten Code bessere lösen zu können und dadurch eventuell an Performance zu gewinnen oder eine bessere Usability z.B. für den Fachbereich bereitstellen zu können. Deine Videos sind große Klasse. Ist das Video zu deinen Buchempfehlungen schon in Planung oder ist es zurzeit etwas schwierig, das ist natürlich verständlich. Ich brenne schon darauf neues zu lesen.

[@DavidTielke]

Hey, auch ein guter Punkt. Vielen Dank für das Feedback! Gruß David

[@tobiasnickel3750]

die Grafik aus dem Thumbnail fehlt. da ist die schoene grafik mit circularer und sogar doppelt circularer Abhaengigkeit. die wird aber gar nicht im video gezeit und besprochen.

[@ernstgreiner5927]

Bei einer Erweiterung wird _vor_ dem "Eingriff" der alte Code refactored und quasi vorbereitet auf das Neue, sind keine/zu wenig Tests vorhanden wird auch hier erweitert. Das fällt auch unter wieder/kennenlernen des Codes. Das Refactoring ist immer x-stufig, fängt mit nachbilden der Tests an, dann einfachem TidyUp reformatieren, Whitespace dazu/entfernen..., renaming, oft trifft man auf Namen die einem nichts mehr sagen, bei all dem lädt man sein Gehirn mit dem vorhanden Code, später kommen die eigentlichen architektonischen Refactorings. Kann sein, dass hier _scheinbar_ viel Arbeit umsonst reingesteckt wird, weil dann eventuell kein Stein auf dem anderen bleibt. Bei neuen Features wird am Ende refactored, auch wieder x-stufig bis alles so ist wie man das haben möchte. Alles begleitet von heftigem committen. Für mich gehört das alles zum Entwicklungsprozess, muss also nicht extra "verhandelt" werden, kann sein, dass man sich als Entwickler hier kräftig auf die Beine stellen muss, kann auch sein, dass man zur Erkenntnis gelangt bei der falschen Firma zu sein...

[@DavidTielke]

Hallo Ernst, sehr gutes und sauber strukturiertes Refactoring - super! Wenn Du da die "Vollmacht" und die Ressourcen zu bekommst, genial - da werden einige neidisch sein. Machst Du das bei jedem Feature oder wie häufig? Gruß David

[@ernstgreiner5927]

@@DavidTielke Bei einer Erweiterung schaue ich schon wie weit ich gehe/gehen muss, was bringt's mir für die Zukunft usw. Letztens waren Tests extrem wichtig, komplexe Stundenabrechnung bei der es mindestens 5 Jahre nichts mehr zu tun gab, Code uralt und wenig schön (alles brav selber verbrochen), Angst davor das Zeug wieder anzugreifen, wenig detaillierte automatisierte Tests vorhanden. Überlegen wie man da vorgeht, Tests bauen, refactoring hat mind. 2/3 der Zeit gekostet. Die eigentliche Änderung war dann fast schon trivial. Die Tests und der Prozess geben dann die Sicherheit die man braucht um so etwas anzugreifen. Bei neuen Features, wenn die Architektur/Lösungsweg nicht klar ist, setze ich gerne auf TDD, hier entsteht viel Explorational-Code, der einem dann hoffentlich den Weg zeigt, kennt man den dann, kann man ihn in eine ordentliche(re) Architektur überführen. Und ein bisschen Pragmatismus darf dabei auch nicht fehlen, aber nur ein bisschen...

[@DavidTielke]

Ja diesen Tradeoff kenne ich, das Problem ist das bald die nächste Änderung kommt, dann die nächste... Und dann ärgere ich mich immer total, dass ich es am Anfang nicht einfach durchgezogen habe :D Ich vermute Dir wird es da ähnlich gehen.... Gruß David

[@ernstgreiner5927]

@@DavidTielke Schieben wir's einfach auf KISS und YAGNI!

[@xeracles3042]

"Chef, wir haben aus unseren PoC Projekt ein Release gebaut und an Kunden verteilt der noch Anfängerfehler sowie Erfahrungslücken zeigt. Aber jetzt ist der Sprint gekommen unsere Technischen Schulden zu reduzieren und neu gewonnener Erfahrung sowie Prozesse einzusetzen dieses Besser zu machen um neue Anforderungen schneller und besser implementieren zu können." Aussage meinerseits gegenüber meines Arbeitsgebers. Ergebnis: Ressourcen verfügbar sowie mit prio eingeplant. => net.5 im Einsatz mit Container

[@DavidTielke]

Ihr habt aus einem POC ein Release für einen Kunden gemacht? 😱 haiaiai... Gruß David

[@xeracles3042]

@@DavidTielke ja leider eine Entscheidung die wir aktuell damit ausgleichen das wir in unseren Sprintphasen mehr zeit in Stabilisierung stecken als in neue Features. Jetzt mit den ganzen Planungen und Erfahrungen wird das alles zuverlässiger.

[@Sunny-wh6jr]

Man kann es aufzeigen Anhand der gestiegenen Zeit für Bugfixes und Neuentwicklungen. Oder auf "Application Lifecycle" schieben. Das hilf auch oftmals. (bsp Core Migration)

[@DavidTielke]

Danke für Deine Anregung, stimmt - aber in der Praxis finde ich das immer schwer mit Zahlen zu belegen - weil für so etwas müsstest Du vergleichbare Aufgaben haben :) Ein Refactoring löst natürlich meist das Problem dahinter nicht ;) Gruß David

[@lukasb9163]

"Hallo Chef! Ich bzw. alle unsere Entwickler müssen ein Refactoring machen, da jeder beim Entwickeln von neuen Features erstmal Tage damit verschwendet herauszufinden welche Auswirkungen die kleinste Änderung am Code auf den Rest der Software hat. Da das auch nicht immer funktioniert, kannst du die Umsetzungen für den nächsten Sprint in die Tonne hauen, da wir damit beschäftigt sind, die Probleme aus diesem Deployment zu beheben. Ich muss dann mal los, die Bugs von 2017 warten auf mich. Mahlzeit!"

[@DavidTielke]

Hey Lukas, und das frisst er einfach so? :D Gruß David

[@lukasb9163]

@@DavidTielke natürlich nicht, aber sehr sehr sehr extrem ausgedrückt läuft es doch oftmals in vielen Unternehmen ähnlich ab. 😜

[@hightower-yt]

Ein Argument ist auch, dass die Frustration der Entwickler hoch ist, wenn schlecht wartbare Software immer weiter ausgebaut werden muss. Gute Entwickler zu finden und zu halten sollte im Interesse der Firma sein.

[@DavidTielke]

Hey Mark, bin total bei Dir, leider zieht das Argument nicht so oft wie es sollte - hat es bei Dir geklappt? Gruß David

[@seventone4039]

Wie machst Du das bei Kundenprojekten mit Millionen Zeilen C/C++ Code?

[@Diddelmann]

Weil es die Alterung von Software "verlangsamt" oder im besten Fall aufhalten wird.

[@DavidTielke]

Und das zieht bei Deinem Chef? :D Gruß David

[@Diddelmann]

@@DavidTielke Beim Kunden

[@nifix777]

Vorallem direkte Abhängigkeiten versuche ich aufzulösen, zb zum UI .

[@DavidTielke]

Hey, sehr gut und die anderen? Gruß David

[@SebastianSack]

Ich würde damit argumentieren, dass der Code dadurch lesbarer wird, was dazu führt, dass man später neue Features schneller einbauen kann UND dass sich neue Kollegen schneller in den Code einarbeiten können. Ich arbeite in der Steuerverwaltung, wo Software i.d.R. über einen längeren Zeitraum läuft. Insofern ist hier regelmäßiges Refactoring praktisch ein Muss ;)

[@DavidTielke]

Hey Sebastian, das kann ich mir in der Branche vorstellen, in dem Bereich können viele von Euch etwas lernen. Schon mal in einer anderen Branche gearbeitet? Da ist es leider oft anders.... Gruß David

[@SebastianSack]

@@DavidTielke Ja, ich war davor bei einem kleinen Startup. Da war es sehr unterschiedlich: Es gab Zeiten, da haben wir viel refactort (?), aber es gab auch Zeiten, da hatten wir für so etwas keine Zeit. Aber ehrlich gesagt, war dort alles sehr chaotisch :P

[@medn_]

Bisher war das Hauptargument immer, dass wir mit den aktuellen Strukturen (die wir aufgrund von zu viel Stress nicht ändern konnten/können) immer mehr technische Schulden aufbauen. Und die dann in Summe zu immer höheren Entwicklungszeiten führen, die mittlerweile auch schon spürbar werden.

[@DavidTielke]

Hey, so geht es mir auch - und das klappt bei Dir echt immer wieder? :D Gruß David

[@medn_]

@@DavidTielke so wirklich gut funktioniert das leider nicht, zumindest was großflächige Refactorings angeht, da meist die Anforderung des Kunden Prio hat. Bin jetzt dazu übergegangen intensiv mit dem "Pfadfinderprinzip" kleinere Stellen zu lösen (refactoren) die mich schon lange stören. Da das aber in Verbindung mit anderen Bugfixes oder neuen Features läuft, ist damit dann doch die Zeit leider etwas begrenzt und damit logischerweise auch die Größe des Refactorings. Aber immerhin konnte ich somit schon einige Stellen lösen, die mir schon häufig Koppschmerzen bereitet haben.

[@DavidTielke]

Gute Idee das so zu lösen, ist Deinem Vorgesetzten denn klar in was für einen Zustand die Anwendung ist? Gruß David

[@medn_]

@@DavidTielke Wir kommunizieren das auf jeden Fall offen und nehmen mittlerweile auch alle möglichen technischen Schulden mit Aufwandsschätzungen in das Ticket-System auf, damit diese Daten auf jeden Fall schriftlich vorliegen und in entsprechenden Auswertungen auftauchen können. Durch aktuelle Nacharbeiten und Umstrukturierung der Planung ist es jedoch noch nicht so einfach gewesen solche Punkte angesehen. Ich hoffe das es dann nach der Umstrukturierung anders aussieht.

[@DavidTielke]

Sehr gut, das mit dem Backlog und den technischen Schulden hab ich in dem Video total vergessen, obwohl es dazu auch ein Video gab.... Mist! Gruß David

[@ChristianHartmannBerlin]

99% der Videos hier bei YT sind 99% des Videos nur Gelaber. Bei diesem Video aber scheint es genau andersrum. So viel Inhalt pro Zeiteinheit erlebt man nur selten. Eine mehr als wohltuende Ausnahme! Said that ... Gleich nochmal gucken...

[@DavidTielke]

Hallo Christian, vielen dank für das Lob - das freut mich sehr, ich mag diese Art von Videos auch deutlich lieber. Das Problem ist leider, das diese "Labervideos" mehr und länger geschaut werden, weil es nicht so harte Kost ist. Das ist ein bisschen das doofe an KZbin, deshalb versuche ich im Moment so ein bisschen ein Zwischending :) Gruß David

[@ThePeterDuh]

Wissen Sie, dass die wichtigsten Funktionen in Ihrer Software vor neun Jahren geschrieben wurden? Das sind die kritischsten Teile ihres Produkts! Wenn da auch nur ein Fehler eingebaut wird, könnte das fatale Folgen für ihr Geschäftsmodell bedeuten. Sie wollen hier eventuell eine Änderung dieser Prozesse? Leider ist das sehr schwierig, da sich keiner unserer Programmierer traut diese Komponenten anzugreifen, da die weder verständlich entwickelt wurden noch mit irgendwelchen Tests versehen sind. Die Gefahr ist groß etwas kaputt zu machen. Hier müssen wir ansetzen, wir brauchen ein Sicherheitsnetz, damit dieses Kernstück erweitert und geändert werden kann ohne hohem Risiko ausgesetzt zu sein.

[@DavidTielke]

Da läuft es sogar mir kalt den Rücken runter - gut geschildert :) Hat es funktioniert? :D Gruß David

[@conqirich5705]

Kommt drauf an, ob es eine Legacy Anwendung ist. Wenn ja würde ich nicht viel an dem Legacy Code refactorn und schauen, das mein Code was rein kommt gut strukturiert ist, getestet und eventuell von dem Legacy Code separiert ist. Sonst kann man den Kunden darauf hinweisen, dass es sich später nicht rechnet, wenn man den Code nicht refactored und das es Geld kostet, weil zu lang dauert und der jetzige Zustand zu komplex ist.

[@DavidTielke]

Hey, danke für die Antwort :) Leider ist das ja nicht immer so einfach eigenen Code von Bestandsquellcode zu trennen.... :( Gruß David

[@stefanalpers7415]

Ich zeige ihm die if-Abfrage mit 6 schließenden Klammern und Bedingungen, die länger als der Bildschirm sind und anschließend das überarbeitete Ergebnis mit sprechenden Variablen- und Methodennamen. Ich hoffe dann das ihm klar wird, welche Variante besser ist.

[@DavidTielke]

Hallo Stefan, Soso... die Brechstange also, finde ich gut :D Gruß David

[@Atilla2109]

Suppi 👍

[@haawks]

Weils unser Technologie-Berater verlangt 😅 Spaß beseite:Lieber jetzt bisserl aufräumen als später komplett neu designen müssen :-)

[@DavidTielke]

😂 die erste muss ich mir merken :) Danke! Gruß David

[@CornellPuchar]

Meist reicht es schon, wenn wir mit einem besseren Design argumentieren. 😀

[@DavidTielke]

Hmm, dann habt ihr es gut. Gilt das auch für große Anwendungen? :) Gruß David

[@CornellPuchar]

@@DavidTielke je nachdem zu tun ist, wird ja regelmäßig priorisiert und terminiert