Refactoring von Martin Fowler - Ein Überblick

Подписаться 17 тыс.

Просмотров 5 тыс.

50% 1

Ein Refactoring (ursprünglich von Martin Fowler erwähnt) ist für die Steigerung der Softwarequalität in der Softwareentwicklung (Software Engineering) unausweichlich - wir geben mit "Refactoring von Martin Fowler - Ein Überblick" heute einen Überblick und ein Beispiel. Dabei kann so ein Refactoring sowohl im Legacy Code (C#, Java, JavaScript, Python, PHP, etc.) als auch in der Software Architektur oder dem User Interface (UI) durchgeführt werden. Aber so ein Refactoring ist aufwendig, teuer und in der Zeit können keine neuen Funktionalitäten geliefert werden. Deshalb ist ein Refactoring bei Entwicklern beliebt, aber bei Verantwortlichen meist nicht. Wir schauen uns in diesem Video das Thema Refactoring mal etwas genauer an, schauen was ein Refactoring ausmacht und welche Voraussetzungen ein solchen Refactoring ausmacht. Am Ende solltest Du nicht nur ein solides Verständnis von Refactorings haben, sondern mit dem Profi-Tipp am Ende auch Deine Vorgesetzten davon überzeugen können.
Kapitel
[00:00] Start
[01:43] Was ist ein Refactoring?
[03:27] Warum werden Refactorings durchgeführt?
[05:35] Voraussetzungen für ein Refactoring
[07:44] Warum sind Refactorings unausweichlich?
[08:47] Die Gefahr bei Refactorings
[10:15] Profi-Tipp für Refactorings
Verlinkte Videos
Technische Schuld - • Technical Debt / Techn...
Softwarequalität - • Softwarequalität Teil ...
▬ Über diesen Kanal ▬▬▬▬▬▬▬▬▬▬▬▬
Seit vielen Jahren arbeite ich als Consultant, Coach und Trainer für professionelle Softwareentwicklung mit den Schwerpunkten Softwarequalität, Softwarearchitektur sowie Prozessmanagement. Auf meinem Kanal möchte ich Euch mein Wissen und meine langjährige Erfahrung in diesen Bereichen vermitteln - natürlich kostenlos. Dabei versuche ich stets Euch das Wissen so zu vermitteln, dass Ihr damit direkt in der Praxis loslegen könnt und das ganze immer mit guten Portion Humor. Lernen soll ja schließlich Spaß machen :)
▬ Empfohlene Videos ▬▬▬▬▬▬▬▬▬▬▬▬
Wie viel Softwarequalität Ihr braucht - • Architekturen - Von Mo...
Warum Software unwartbar wird - • Warum Software unwartb...
Architektur - Modularisierung - • Architektur - Modulari...
Was ist Architektur - • Was ist Architektur?
Warum Architektur - • Warum Architektur für ...
▬ Wichtige Links ▬▬▬▬▬▬▬▬▬▬▬▬
Abonniere meinen Kanal: / @davidtielke
Alle Videos: / @davidtielke
▬ Social Media ▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬
► Twitter: / davidtielke
► Xing: www.xing.com/profile/David_Ti...
► LinkedIn: / david-tielke-06140912b
▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬

Наука

Опубликовано:

5 июл 2024

Ссылка:

Скачать:

Готовим ссылку...

Добавить в:

Мой плейлист

Посмотреть позже

Комментарии : 86

@DavidTielke 3 года назад

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!

@razielstriker564 3 года назад

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 3 года назад

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

@NordmannDK 3 года назад

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 3 года назад

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

@marcusreinicke 3 года назад

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

@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

@michaelbierbaum4735 3 года назад

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 3 года назад

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

@IxFreeZe4TW 3 года назад

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 3 года назад

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 3 года назад

Herzlichen Dank für das Video.

@DavidTielke 3 года назад

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

@heischono4917 3 года назад

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 3 года назад

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

@christianhuber4048 3 года назад

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

@DavidTielke 3 года назад

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

@christianhuber4048 3 года назад

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

@guidoerfen7944 3 года назад

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 3 года назад

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

@breakerx6212 3 года назад

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 3 года назад

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

@martinbernasconi9208 3 года назад

"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 3 года назад

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

@davidmuller6723 3 года назад

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 3 года назад

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

@17plus9 Год назад

Die Neuentwicklung ist das beste Refactoring.

@marcusreinicke 3 года назад

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 3 года назад

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

@markuskruger1889 10 месяцев назад

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.

@marcusschone296 3 года назад

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 3 года назад

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

@Tiriondil 11 месяцев назад

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.

@xeracles3042 3 года назад

"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 3 года назад

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

@xeracles3042 3 года назад

@@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.

@seventone4039 2 года назад

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

@ChristianHartmannBerlin 2 года назад

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 2 года назад

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 RU-vid, deshalb versuche ich im Moment so ein bisschen ein Zwischending :) Gruß David

@biask89 3 года назад

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 3 года назад

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 3 года назад

@@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 3 года назад

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

@Atilla2109 Год назад

Suppi 👍

@nifix777 3 года назад

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

@DavidTielke 3 года назад

Hey, sehr gut und die anderen? Gruß David

@lukasb9163 3 года назад

"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 3 года назад

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

@lukasb9163 3 года назад

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

@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.

@stefanalpers7415 3 года назад

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 3 года назад

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

@Sunny-wh6jr 3 года назад

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 3 года назад

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

@sennah2672 3 года назад

Plattform/Struktur lässt das neue Feature nicht zu, ist abgekündigt, inkompatibel zum nächsten System-/Schnittstellen-Update oder nicht mehr zeitgemäß (x86, Ansi, Optik, ...). Wir laufen gegen eine Wand. Jetzt noch einfach zu machen. Auswirkugen und Risiken unbekannt - Spagetti ... deshalb ist bei Abschätzung die Analysezeit & Test massiv erhöht, später dann ggf. in Refactoring ummünzen. Bei Änderungen: 10%-20% für Refactoring einmassieren. Wird dann hoffentlich von PM akzeptiert und ggf. indirekt auf den Kunde umgelegt. (Anm: Erst unabhängiges Refactoring, dann Änderung !)

@DavidTielke 3 года назад

Hallo Johannes, Sehr cool, schön wenn schon solche Argumente bei Dir/Euch Gehör finden :) Gruß David

@Diddelmann 3 года назад

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

@DavidTielke 3 года назад

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

@Diddelmann 3 года назад

@@DavidTielke Beim Kunden

@ThePeterDuh 3 года назад

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 3 года назад

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

@ernstgreiner5927 3 года назад

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 3 года назад

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 3 года назад

@@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 3 года назад

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 3 года назад

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

@hightower-yt 3 года назад

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 3 года назад

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

@sennah2672 3 года назад

Fowler mit Beispiel zum Refactoring auf Methoden-Ebene: ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-6wDoopbtEqk.html

@DavidTielke 3 года назад

Klasse, danke! Gruß David

@SebastianSack 3 года назад

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 3 года назад

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 3 года назад

@@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_ 3 года назад

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 3 года назад

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

@medn_ 3 года назад

@@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 3 года назад

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

@medn_ 3 года назад

@@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 3 года назад

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

@conqirich5705 3 года назад

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 3 года назад

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