Refactoring von Martin Fowler - Ein Überblick
David Tielke
https://www.youtube.com/watch?v=jaMTZ6NzvEg

Transkript (automatisch erstellt)

0:00 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
0:08 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
0:15 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
0:24 unbedingt haben muss in der anwendung danach zeige ich dir warum allein refactoring eigentlich kein weg vorbeiführt was die gefahr dabei ist und
0:31 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
0:41 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
0:49 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
0:58 ende dieses videos mein name ist david ilka ich bin freiberuflicher berater coach und trainer für die themen softwarequalität softwarearchitektur und
1:06 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
1:14 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
1:22 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
1:29 detail [Musik]
1:47 was ist so ein refactoring denn jetzt überhaupt wenn wir software entwickeln dann schreiben wir mit quellcode statements um die funktionalen
1:55 anforderungen umzusetzen und erstellen aus verschiedenen arten von systemen eine modularisierung darum zum beispiel mit methoden passenden komponenten
2:03 schichten diensten und natürlich der anwendung selbst damit werden dann die nicht funktionalen anforderungen einer anbindung umgesetzt
2:11 jedes dieser angesprochenen systeme funktioniert dabei nachdem eva prinzip hat also an der eingabe eine verarbeitung und eine ausgabe für die
2:19 betrachtung des factorings fassen wir an dieser stelle die eingabe und die ausgabe zu einem sammelbegriff zusammen den sogenannten verhalten und die
2:26 verarbeitung taufen wir kurzerhand um wenn dem begriff innere struktur leicht andere begriffe die bedeutung bleibt aber unverändert ein refactoring führen
2:35 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
2:43 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
2:49 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
2:57 factorings in vielen bereichen durchführt als entwickler auf ebene der software designs oder auch als architekt auf ebene der software architektur oder
3:05 der systemarchitektur egal auf welcher ebene das treffen durchführen möchte ist entscheidend ist dabei dass beide änderung der struktur das äußere
3:13 verhalten des betrachteten systems vollständig konstant bleibt zusammengefasst also ein refactoring ist eine strukturelle änderung in teilen
3:21 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
3:34 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
3:41 lösung irgendwie nicht wirklich immer möchte gerne so ein refactoring durchführen oder es ändern sich die nicht funktionalen anforderungen in
3:48 einem projekt und daraufhin muss ein struktureller umbau gemacht werden wichtig dabei ist so eine factoring ist meist unglaublich aufwendig und teuer
3:55 hat muss also dem projektmanager vorgesetzt unser chef an mehrwert dafür geben dass dieses geld in das gewünschte effekt bringen investiert wird
4:02 die eben schon angesprochen ändern wir beim refactoring nur die struktur damit die nicht funktionalen anforderungen somit und das ist ganz ganz wichtig
4:09 arbeiten wir an den qualitäts attributen die lesbarkeit fahrbarkeit modifizierbar keiten austauschbarkeit testpaket und so weiter und so fort
4:17 da musste immer dann ein refactoring durchführen wenn einer oder mehrere dieser qualitäts attribute nicht wie erforderlich umgesetzt wurden im mittel
4:25 was er in der kommunikation nach oben zu eurem vorgesetzten und als totschlagargument verwenden könnt ist die so genannte technische schuld dazu
4:33 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
4:39 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
4:47 entwickelt dann hat das an ist zustand wurde dies aber beispielsweise so entwickelt dass die lesbarkeit des quellcodes und damit die komplexität so
4:54 hoch geworden ist dass du in dem projekt kaum noch arbeiten kannst so habt ihr durch gemachte fehler nicht in idealzustand also die sauber
5:02 programmierte und strukturierte anwendung die technische schuld beschreibt also die zeit die ihr in einem reh factoring investieren müsst um
5:08 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
5:17 dass ihr nutzt ein refactoring um angehäufte technische schulden zu reduzieren um damit die qualitativen attribute einer dann zu machen aber
5:25 einfach so drauflos re faktor ihren ist meistens nicht es gibt eine wichtige voraussetzungen die du beachten musste bevor du einen refactoring angeht
5:32 schauen wir uns mal an welcher das ist mit einem refactoring wird nur die struktur nicht aber das verhalten
5:42 geändert mit anderen worten einen durchgeführtes refactoring ist immer dann erfolgreich wenn nachher mindestens ein qualitäts attribut besser geworden
5:49 ist ohne dass dabei die funktionalität geändert wurde klingt einfach aber leider nur in der theorie
5:56 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
6:04 irgendeiner art und weise von euch als entwickler bemerkt werden werden nun große teile der anwendung gebaut ist diese gefahr selbstverständlich
6:11 ebenfalls da und wenn ihr mich fragt sogar noch wesentlich wahrscheinlicher als bei einer kleinen funktional änderung oder eine erweiterung laden wir
6:20 bei unseren einleitenden abstrakten beispiel mit unseren systemen wenn einem refactoring bedeutet dass nur die innere struktur und nicht das
6:27 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
6:36 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
6:46 systemtest dafür sorgen dass nach dem refactoring die unversehrtheit des verhaltens gegeben ist und genau da liegt in der praxis oftmals
6:53 der hund begraben oder er das rudel runde denn wie oft kommt es denn vor dass in einem system wirklich eine ausreichende
7:01 testabdeckung vorherrscht und so eine verifikation tatsächlich möglich ist glaubt meine erfahrung ganz ganz ganz selten ganz ehrlich selbst wenn solche
7:10 test geschrieben wurden ist es von großer wichtigkeit dass hier nur blackbox festgeschrieben worden also tests ohne jegliche annahme über die
7:18 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
7:26 hohen risiko betrieben oftmals ist die fehler situation nach einem refactoring extrem belastend für ein unternehmen und da kommt oftmals
7:33 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
7:42 eigentlich unausweichlich neben gezeigt nutzt du einen refactoring immer dann wenn du technische schulden reduzieren möchte ist auch wenn der begriff schuld
7:55 ist leider suggeriert es muss nicht immer zwingend die schuld eines entwicklers oder eines architekten sein dass diese entsteht oftmals entsteht sie
8:02 beispielsweise weil im laufe des projektes plötzlich ein qualitäts attribut wie wiederverwendbarkeit austauschbarkeit oder testtag als
8:09 plötzlich eine unglaublich hohe relevanz bekommen warum auch immer oder weil eine anwendung plötzlich skalieren muss partiell ausfallsicher
8:16 sein muss oder in einzelnen bestandteilen unabhängig bereitgestellt werden kurz gesagt in jedem projekt existiert eine solche technische schuld
8:24 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
8:31 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
8:39 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
8:51 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
8:59 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
9:07 auf größere teile der anwendung beziehen meistens sind es wie gesagt sogar die ganze anwendung dauert so ein refactoring auch dementsprechend lange
9:14 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
9:22 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
9:29 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
9:37 entwicklung nutzt man einen quellcode verwaltung und darin enthaltene branches wer denn nun in einem branche einen modus komplett restrukturiert und in
9:44 einem parallelen feature plant eine erweiterung oder eine veränderung daran durchführt zu bekommt die ernste probleme beim späteren virgin dieser
9:51 brandschutz das heißt parallele entwicklung und gleichzeitig rief er krimis unglaublich schwer die welt also wohl oder übel entweder keine funktion
9:58 mehr liefern oder euch eine andere strategie überlegen ist aber unterschätzt diesem aspekt bitte nicht darüber sind schon ganz ganz viele
10:05 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
10:13 praxis wenn du als entwickler oder als architekt ein refactoring anstrebt gibt
10:23 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
10:31 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
10:38 eine längere zeit und kein funktionalitäten wer der zukunft überzeugungsarbeit bei deinem vorgesetzten ist dabei obwohl es
10:45 zunächst komisch klingt das größere problem aber hier hilft die gezeigte argumentation über die qualitäts attribute und die technische schuld
10:52 versucht transparent und ehrlich aufzuzeigen was ist die ursache für die technische schuld zum beispiel schlechte anforderungen oder versäumnisse von euch
10:59 und zeigt gleichzeitig aber auch so transparent und ehrlich wie möglich die resultierenden konsequenzen auf beispielsweise das feature immer länger
11:06 dauern oder bestimmte unternehmensziele wie eingang in die cloud mit der aktuellen struktur so nicht umsetzbar ist ein vorgesetzter ist von rhi
11:14 factorings nie begeistert wenn aber die risiken aufgezeigt werden wenn es nicht gemacht wird es ist meistens das argument was diesem schalter genau
11:21 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
11:28 meist nur bei großen refactoring notwendig ist ist meistens wesentlich einfacher als alle beteiligten zum anfang an dem aus meiner langjährigen
11:35 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
11:43 struktur haben dann ist das dem kunden meistens eh schon aufgefallen dann gibt es ganz bestimmt schon eine große unzufriedenheit bei der entwicklungszeit
11:50 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
11:57 erkannt habt und in jetzt ja jetzt in seinem sinne an genau dieser verbesserung arbeiten wollte damit die anwendung in zukunft besser wird und
12:04 seine zufriedenheit steigt wie schon gesagt damit habe ich in meiner karriere eigentlich immer sehr sehr gute erfahrungen macht und auch wenn das dann
12:12 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
12:20 eine oder andere feature zu implementieren was die kunden ist schon lange haben wollen dann kann man oftmals dieses feature ebenfalls noch als
12:27 treiber für genau dieses wie factoring verkauft ich stand am anfang des videos gesagt kannst du heute wieder etwas gewinnen
12:33 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
12:41 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
12:49 schreiben aufpassen mit deinem job argument gegenüber dem vorgesetzten warum du ein refactoring machen und auch die
12:56 antworten bin ich richtig richtig gespannt den gewinner des preises wo sich dann in einem monat aus und benachrichtigt
13:02 diejenige oder denjenigen dann entsprechend darüber gewonnen hast du hoffentlich heute nach diesem video an wissen mit treuem motto konnte ich dich
13:10 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
13:16 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
13:23 nochmal ein paar videos dazu ist wirklich die einen erfolgreichen tag viel spaß bei der arbeit bis zum nächsten mal