Das Video kommt von YouTube: erst beim Abspielen verbindet sich die Seite mit YouTube (Google).
Refactoring von Martin Fowler - Ein Überblick
Das Wichtigste aus dem Video
Tipp auf eine Zeit – das Video springt genau dorthin.
Transkriptautomatisch erstellt · 103 Zeilen
- hallo und ein ganz wunderschönen tag und wieder einmal herzlich willkommen zu einem neuen lern video hier auf breiten kanal entwickler lieben ist und würden
- uns am liebsten den ganzen tag tun projektmanager auf der anderen seite mögen das meist überhaupt nicht um meiden wie der teufel das weihwasser
- die rede ist von einem refactoring ich zeige dir heute warum überhaupt eine factoring machen musst was das überhaupt ist und welche voraussetzungen dafür
- unbedingt haben muss in der anwendung danach zeige ich dir warum allein refactoring eigentlich kein weg vorbeiführt was die gefahr dabei ist und
- wenn du ganz bis zum ende dann bleibst verrate ich dir im profi tipp wie genau ich grocery factorings beim 1 auch in dieser woche sollte dabei nicht
- leer ausgehen und in kooperation mit dem rhein berg it verlag können wir wieder ein fachbuch aus deren umfangreichen entwickler programm verlosen in dieser
- woche habe ich dazu das buch entwurf muss er von matthias kairos ausgewählt wie du an dieser verlosung teilnehmen kannst das verrate ich dir wie immer am
- ende dieses videos mein name ist david ilka ich bin freiberuflicher berater coach und trainer für die themen softwarequalität softwarearchitektur und
- alles was spaß macht im bereich des software den weg auf die zum kanal möchte ich dir meinen wissen ja vermitteln dass mit den teilen und sich
- damit von video zu video ein kleines stückchen besser wenn dir das video gefällt wird ist mir mit einem like und einem abo sie dabei helfen noch mehr
- entwickler jeden tag ein kleines stückchen besser zu machen wie immer verlieren wir nicht noch mehr zeit und schaum das thema refactoring mal im
- detail [Musik]
- was ist so ein refactoring denn jetzt überhaupt wenn wir software entwickeln dann schreiben wir mit quellcode statements um die funktionalen
- anforderungen umzusetzen und erstellen aus verschiedenen arten von systemen eine modularisierung darum zum beispiel mit methoden passenden komponenten
- schichten diensten und natürlich der anwendung selbst damit werden dann die nicht funktionalen anforderungen einer anbindung umgesetzt
- jedes dieser angesprochenen systeme funktioniert dabei nachdem eva prinzip hat also an der eingabe eine verarbeitung und eine ausgabe für die
- betrachtung des factorings fassen wir an dieser stelle die eingabe und die ausgabe zu einem sammelbegriff zusammen den sogenannten verhalten und die
- verarbeitung taufen wir kurzerhand um wenn dem begriff innere struktur leicht andere begriffe die bedeutung bleibt aber unverändert ein refactoring führen
- wir jetzt immer dann durch wenn wir mit der inneren struktur eines systems nicht zufrieden sind und dieses ändern möchte das heißt wenn wir mit den methoden in
- einer klasse nicht zufrieden sind führen wir einen refactoring durch wenn wir mit den klassen einer komponente nicht zufrieden sind würden wir an effekt
- bringen durch und sind wir mit der gesamten struktur einer anwendung ich zufrieden führen wir auch unterbringen wie du siehst kann man solche wie
- factorings in vielen bereichen durchführt als entwickler auf ebene der software designs oder auch als architekt auf ebene der software architektur oder
- der systemarchitektur egal auf welcher ebene das treffen durchführen möchte ist entscheidend ist dabei dass beide änderung der struktur das äußere
- verhalten des betrachteten systems vollständig konstant bleibt zusammengefasst also ein refactoring ist eine strukturelle änderung in teilen
- eine software produkte ohne dabei jedoch funktionen zu ändern oder hinzuzufügen warum und vor allen dingen wann soll es jetzt also so ein refactoring
- durchführen sowohl entwickler als auch architekten kennen das eine lösung fand man am anfang noch gut und irgendwann dann gefällt an die
- lösung irgendwie nicht wirklich immer möchte gerne so ein refactoring durchführen oder es ändern sich die nicht funktionalen anforderungen in
- einem projekt und daraufhin muss ein struktureller umbau gemacht werden wichtig dabei ist so eine factoring ist meist unglaublich aufwendig und teuer
- hat muss also dem projektmanager vorgesetzt unser chef an mehrwert dafür geben dass dieses geld in das gewünschte effekt bringen investiert wird
- die eben schon angesprochen ändern wir beim refactoring nur die struktur damit die nicht funktionalen anforderungen somit und das ist ganz ganz wichtig
- arbeiten wir an den qualitäts attributen die lesbarkeit fahrbarkeit modifizierbar keiten austauschbarkeit testpaket und so weiter und so fort
- da musste immer dann ein refactoring durchführen wenn einer oder mehrere dieser qualitäts attribute nicht wie erforderlich umgesetzt wurden im mittel
- was er in der kommunikation nach oben zu eurem vorgesetzten und als totschlagargument verwenden könnt ist die so genannte technische schuld dazu
- haben wir auf dem kanal schon ein video gemacht falls das verpasst haben soll das denke ich das nochmal hier oben rechts in der ecke mit der technischen
- schuld wird die dauer beschrieben die benötigt wird um in einem projekt von allen ist zustand zu einem soll zustand zu kommen habt ihr also ein projekt
- entwickelt dann hat das an ist zustand wurde dies aber beispielsweise so entwickelt dass die lesbarkeit des quellcodes und damit die komplexität so
- hoch geworden ist dass du in dem projekt kaum noch arbeiten kannst so habt ihr durch gemachte fehler nicht in idealzustand also die sauber
- programmierte und strukturierte anwendung die technische schuld beschreibt also die zeit die ihr in einem reh factoring investieren müsst um
- von eurem soll zustand zu dem angestrebten ist-zustand zu re faktoren das ist dass pecik linke deutsche wort für refactoring zusammengefasst heißt
- dass ihr nutzt ein refactoring um angehäufte technische schulden zu reduzieren um damit die qualitativen attribute einer dann zu machen aber
- einfach so drauflos re faktor ihren ist meistens nicht es gibt eine wichtige voraussetzungen die du beachten musste bevor du einen refactoring angeht
- schauen wir uns mal an welcher das ist mit einem refactoring wird nur die struktur nicht aber das verhalten
- geändert mit anderen worten einen durchgeführtes refactoring ist immer dann erfolgreich wenn nachher mindestens ein qualitäts attribut besser geworden
- ist ohne dass dabei die funktionalität geändert wurde klingt einfach aber leider nur in der theorie
- jeder weiß dass bei der erweiterung oder dem verändern von funktionalitäten sehr schnell ein fehler also einen weg entstehen kann ohne dass das in
- irgendeiner art und weise von euch als entwickler bemerkt werden werden nun große teile der anwendung gebaut ist diese gefahr selbstverständlich
- ebenfalls da und wenn ihr mich fragt sogar noch wesentlich wahrscheinlicher als bei einer kleinen funktional änderung oder eine erweiterung laden wir
- bei unseren einleitenden abstrakten beispiel mit unseren systemen wenn einem refactoring bedeutet dass nur die innere struktur und nicht das
- verhalten geändert wird muss also am ende bewiesen werden mehr oder weniger dass eben dieses verhalten noch so ist wie vor und das mittel der wahl sind
- dabei natürlich sortiertes das heißt auf quellcode ebene könnten mehrere unitis auf dienst ebene mehrere services und auf anwendungsebene natürlich mehrere
- systemtest dafür sorgen dass nach dem refactoring die unversehrtheit des verhaltens gegeben ist und genau da liegt in der praxis oftmals
- der hund begraben oder er das rudel runde denn wie oft kommt es denn vor dass in einem system wirklich eine ausreichende
- testabdeckung vorherrscht und so eine verifikation tatsächlich möglich ist glaubt meine erfahrung ganz ganz ganz selten ganz ehrlich selbst wenn solche
- test geschrieben wurden ist es von großer wichtigkeit dass hier nur blackbox festgeschrieben worden also tests ohne jegliche annahme über die
- innere struktur welche jahr geändert werden sollen in der praxis ist es häufig an problemen und deshalb werden leider viele refactoring mit einem enorm
- hohen risiko betrieben oftmals ist die fehler situation nach einem refactoring extrem belastend für ein unternehmen und da kommt oftmals
- auch ja sein wirklich fürchterlich hoch besonders im management weil viele tests und schlechter hof hin oder her ein reh factorings sind in nahezu jedem projekt
- eigentlich unausweichlich neben gezeigt nutzt du einen refactoring immer dann wenn du technische schulden reduzieren möchte ist auch wenn der begriff schuld
- ist leider suggeriert es muss nicht immer zwingend die schuld eines entwicklers oder eines architekten sein dass diese entsteht oftmals entsteht sie
- beispielsweise weil im laufe des projektes plötzlich ein qualitäts attribut wie wiederverwendbarkeit austauschbarkeit oder testtag als
- plötzlich eine unglaublich hohe relevanz bekommen warum auch immer oder weil eine anwendung plötzlich skalieren muss partiell ausfallsicher
- sein muss oder in einzelnen bestandteilen unabhängig bereitgestellt werden kurz gesagt in jedem projekt existiert eine solche technische schuld
- und wächst von tag zu tag weiter an wie stark dieser anstieg ist hängt davon ab wie ernst ihr das thema software-qualität wird falls da noch
- nachholbedarf es flink ich dafür auch noch mal hier oben rechts in der ecke das entsprechende video zum thema software-qualität zusammengefasst werdet
- ihr also früher oder später um ein refactoring nicht herumkommen um einen oder mehrere qualitätsanbieter erfüllen zu können oder stärken
- aber so klar und einleuchtend dass aus sicht eines entwicklers oder eines architekten auch ist so problematisch ist es für das projektmanagement bzw für
- das unternehmen ansicht wie jetzt wiederholt erwähnt wurde wird in einem reflektor nur die struktur nicht das verhalten geändert da sich frings meist
- auf größere teile der anwendung beziehen meistens sind es wie gesagt sogar die ganze anwendung dauert so ein refactoring auch dementsprechend lange
- das heißt wenn ihr einen refactoring durchführt was mehrere monate oder gar jahre dauert in das tier sehr viele ressourcen ohne dass sie in dieser zeit
- dem kunden einen funktionalen mehrwert liefern können und das ist oftmals das tatsächliche problem und meistens auch das ko kriterium in einem praxisprojekt
- gut machen wir als halb refactoring und halb feature entwicklung ist das jetzt vielleicht denken ist aber auch nicht so einfach nahezu in jeder modernen
- entwicklung nutzt man einen quellcode verwaltung und darin enthaltene branches wer denn nun in einem branche einen modus komplett restrukturiert und in
- einem parallelen feature plant eine erweiterung oder eine veränderung daran durchführt zu bekommt die ernste probleme beim späteren virgin dieser
- brandschutz das heißt parallele entwicklung und gleichzeitig rief er krimis unglaublich schwer die welt also wohl oder übel entweder keine funktion
- mehr liefern oder euch eine andere strategie überlegen ist aber unterschätzt diesem aspekt bitte nicht darüber sind schon ganz ganz viele
- unternehmen gestolpert und sehr tief gefallen das könnt ihr mir glauben aber wie macht man das dann jetzt in der praxis schauen wir uns das mal an im
- praxis wenn du als entwickler oder als architekt ein refactoring anstrebt gibt
- es genau zwei probleme zum einen musst du deinen vorgesetzten davon überzeugen weil der die schließlich die zeit dazu einräumen muss ohne am ende einen
- funktionalen mehrere zu bekommen und dieser muss die kunden während dieser zeit in irgendeiner art machen selber laune halten und ihn erklären warum für
- eine längere zeit und kein funktionalitäten wer der zukunft überzeugungsarbeit bei deinem vorgesetzten ist dabei obwohl es
- zunächst komisch klingt das größere problem aber hier hilft die gezeigte argumentation über die qualitäts attribute und die technische schuld
- versucht transparent und ehrlich aufzuzeigen was ist die ursache für die technische schuld zum beispiel schlechte anforderungen oder versäumnisse von euch
- und zeigt gleichzeitig aber auch so transparent und ehrlich wie möglich die resultierenden konsequenzen auf beispielsweise das feature immer länger
- dauern oder bestimmte unternehmensziele wie eingang in die cloud mit der aktuellen struktur so nicht umsetzbar ist ein vorgesetzter ist von rhi
- factorings nie begeistert wenn aber die risiken aufgezeigt werden wenn es nicht gemacht wird es ist meistens das argument was diesem schalter genau
- umlegen kann und wenn alles nichts hilft und steht ihm am besten einfach ein link zu diesem video danach wie das ganze ja verstehen dass überzeugen der kunden was
- meist nur bei großen refactoring notwendig ist ist meistens wesentlich einfacher als alle beteiligten zum anfang an dem aus meiner langjährigen
- erfahrung kann ich euch hier nur raten das ganze ehrlich und transparent zu machen genau wie vor dem vorgesetzten wenn die probleme in großen teilen aber
- struktur haben dann ist das dem kunden meistens eh schon aufgefallen dann gibt es ganz bestimmt schon eine große unzufriedenheit bei der entwicklungszeit
- von funktionen der großen zahl von bugs oder irgendein anderes problem ist zudem durch gekommen erklärt ehrlich und transparenz dass sie dieses problem
- erkannt habt und in jetzt ja jetzt in seinem sinne an genau dieser verbesserung arbeiten wollte damit die anwendung in zukunft besser wird und
- seine zufriedenheit steigt wie schon gesagt damit habe ich in meiner karriere eigentlich immer sehr sehr gute erfahrungen macht und auch wenn das dann
- kein refactoring ist es hält euch ja auch niemand davon ab zusammen mit dem refactoring wenn die größte teil des co neu schreibt also nicht nur um baut das
- eine oder andere feature zu implementieren was die kunden ist schon lange haben wollen dann kann man oftmals dieses feature ebenfalls noch als
- treiber für genau dieses wie factoring verkauft ich stand am anfang des videos gesagt kannst du heute wieder etwas gewinnen
- und zwar das buch entwurfs muster von matthias kraus vom rhein berg vertiefen an dieser stelle nochmal herzlichen dank für ein werk für diese tolle unterstütze
- alles was du für diese teile machen muss ist das video hier zu liken wegen kanal zu abonnieren und dann unterhalb von diesem video einen kommentar zu
- schreiben aufpassen mit deinem job argument gegenüber dem vorgesetzten warum du ein refactoring machen und auch die
- antworten bin ich richtig richtig gespannt den gewinner des preises wo sich dann in einem monat aus und benachrichtigt
- diejenige oder denjenigen dann entsprechend darüber gewonnen hast du hoffentlich heute nach diesem video an wissen mit treuem motto konnte ich dich
- damit in diesem video wieder ein kleines stückchen besser machen wie immer hilfst du mir mit einem aber und einem like unter diesem video dabei noch mehr
- entwickler jeden tag ein kleines stückchen besser zu machen solltest du jetzt noch nicht genug haben und haben hier auf der rechten seite gibt es
- nochmal ein paar videos dazu ist wirklich die einen erfolgreichen tag viel spaß bei der arbeit bis zum nächsten mal
Zum Nachlesen
RefactoringRefactoring ist ein zentraler Bestandteil der Agilen Softwareentwicklung. Dort wird meist von „kontinuierlichem“ Refactoring oder „kompromisslosem“ Refactoring …
Reengineering (Software)Ein Reengineering zur Verbesserung der Softwarequalität ist oft erforderlich, um die Qualität und Wartbarkeit von Software langfristig zu gewährleisten, da in …
Technische SchuldenAlistair Cockburn zeigt auf, dass das Aufnehmen von technischen Schulden einem der Grundwerte der agilen Softwareentwicklung, dem der aufrechterhaltbaren …
CodequalitätCodequalität ist ein Teilaspekt von Softwarequalität, mit dem insbesondere nicht-funktionale Anforderungen wie Konformität, Verständlichkeit, Analysierbarkeit, …