Nun kommen wir zu dem zentralen Thema dieses Wartung und Re-Engineering
Kapitels, jedenfalls zu der wichtigsten Technik, Refactoring.
Wir haben hier ein paar Fragen, auf die wir wieder,
wie Sie das schon kennen, dann eingehen werden.
Dafür starten wir, also wir Kapitel 4, 2,
das sind wir hier, also Refactoring.
Wir starten mal mit der Definition. Diese Definition sagt uns,
oder stammt von Martin Fauler, der diesen Begriff Refactoring geprägt hat.
Martin Fauler hat immer gesagt, ja,
ich habe das ja nur aufgeschrieben,
ich bin gar nicht der wesentliche Guru hier,
die Leute um mich herum haben das dann,
haben das so entwickelt
Wichtig ist ja hier, wenn wir das mal lesen,
a change mained to the internal structure of a software to make
it easier to understand and sheeper to modify with our changing,
it's observerable mahavior.
Also zum einen haben wir hier die Ziele dabei genannt,
die mache ich hier mal so hellblau, to make it,
easier to understand and cheaper to modify.
Es geht also in Richtung Wartbarkeit, Wartbarkeit ist der Aufwand für Veränderungen.
Ich hoffe, Sie haben das noch präsent.
Es gibt ja irgendwann eine Prüfung, ja,
da müsste man das noch wissen. Und wir haben dann,
also dieses ändern, leichter zu machen, ist Verbessern von Wartbarkeit.
Das ist das erklärte Ziel von Refactoring. Und was ist
dabei zu beachten? Was ist eine wichtige Randbedingung? Das
mache ich mal rot, with out changing, it's observel behavior.
Das heißt, wir lassen das Verhalten unverändert.
Wir hatten diese gleiche Sache eben schon,
als wir den Begriff Reverse Engineering und Re-Engineering diskutiert haben,
vor allen Dingen Re-Engineering, das pure Re-Engineering ändert nichts an der Funktionalität.
Refactoring ändert ebenfalls nichts an der Funktionalität.
Das heißt, die beiden Sachen hängen sehr eng zusammen.
Tatsächlich ist Refactoring der Kern von Re-Engineering zu Re-Engineering gehört
noch mehr
Ja, hier von Geek und Poke, ein Comic dazu.
Ich hoffe, Sie können das hier sich so vergrößern,
dass Sie es gut lesen können. Das halt, man hat,
Sie haben also über Effektorin, ziehen Sie ein bisschen her,
das Refactoring in der einfachsten Form, nur eine Umbenennung,
der ist dann auch um Umbenennung und Ziehen, als Refactoring,
weil natürlich auch ein besserer Name zu besserer Verständlichkeit beiträgt.
Ja, also Verständlichkeit und leichtere Hinbarkeit, weil man sich besser zurechtfindet.
Ja, und die beiden hier, nobody, new,
what's in this big and massy class,
we decided to refactor it
And you renamed it to Area 51. Ja, also herzlichen Glückwunsch. Ja,
das ist also natürlich die Ironie, ja, Refactoring,
da ist Umbenennung noch das Kleinste davon und dann so einen tollen Namen.
Ja, also deswegen ist es ja ein Comic.
Ich möchte kurz mit Ihnen, ach so, ich möchte,
wir wollen ja mal auf die Fragen eingehen,
das machen wir hier gleich mal.
Ja, das war also die Definition von Refactoring und ich möchte mit Ihnen darüber sprechen.
Die Ziele waren ja auch mit dabei, ja,
Wartbarkeit und jetzt möchte ich mit Ihnen darüber sprechen,
was trägt dazu bei,
das Risiko zu verringern
Das Risiko ist etwas ganz Wesentliches, wenn wir an lauffähigen Systemen arbeiten wollen.
Sie kennen den Spruch, never change a winning team.
Das trifft hier sehr stark zu. Never change a running
system. Das ist einer der Kernpunkte, dieses Reingeneering,
der die Wartung so schwierig macht und der dazu führt,
dass wir im Staged Model dann so langsam abrutschen.
Also wenn wir vielleicht einfach noch mal dahin schauen,
ja, wir wollten in diesem Stage Model,
wir müssen versuchen mit unseren geschäftskritischen Systemen immer auf dieser Stufe zu bleiben.
Und das heißt, wir müssen verhindern,
dass Wattbarkeit schlechter wird
Ich hatte bei diesem Stage-Model gesagt, ja,
man kommt ja hier immer weiter runter, weil Fehler nun mal auftreten.
Und Fehler sich publizieren, vervielfachen. Und wenn es erstmal
schlechte Wartbarkeit gibt, dann versteht man es noch schlechter,
macht noch schlechter, noch mehr etwas kaputt.
Und es gibt hier keinen Fall, der nach oben führt.
Und dieser Pfeil nach oben, das ist das Re-Engineering,
das ist das Refactoring. Mit dem Ziel, Wartbarkeit zu
verbessern. Aber wir haben hier natürlich immer die Situation,
dass wir mit hohem Risiko zu tun haben, dass keiner möchte,
dass System beeinträchtigen durch seine Handlungen und deswegen etwas umstrukturieren.
Zum Beispiel statt nur einen neuen Paar, wir müssen eine neue Rolle einführen. Dieses Rolle einführen,
vielleicht in einem System, haben wir in einem System,
wo es um Webseiten geht,
da haben wir die Rolle des Redakteurs,
da schreiben zugreifen kann und dann haben die Dolle des Lesers
und vielleicht noch die Rolle des Bildautors und vielleicht die Rolle des Chefredakteurs sozusagen super weißer über alles.
Und jetzt wollen wir eine spezielle Rolle einführen eines Lektors,
der nur, der nicht Texte verändert soll,
nur arrangiert und Überschriften verändert
Ja, nun könnte man natürlich sagen, okay,
da machen wir halt einfach nur eine Variante davon oder sowas,
aber richtig eine neue Rolle einführen.
Überall hat eine größere Auswirkung, hat was mit Umstrukturierung zu tun.
Und vielleicht will man das nicht machen wegen zu großen Risiko.
Man baut es irgendwo dran. Und dieses irgendwo dranbauen wäre eigentlich
das hier. Und wir wollen es aber richtig machen,
das heißt, wir müssten auch etwas tun für Wartbarkeit.
Zurück zu dem Thema. Die Fragen, die wir hier hatten,
war die Frage, die mit dir jetzt kümmern wollen,
wie können wir es machen,
dieses Risiko, was die Leute hindert,
Umstrukturierung zu machen,
zu verringern
Refactoring ist damit angetreten, solches Risiko zu verringern.
Und zwar dadurch, dass es eben systematisches Vorgehen macht.
Ja, also deswegen, wir wachen hier eine neue Seite.
Und ich brauche einen schwarzen Stift.
Refactoring, kalte Wartbarkeit, verbessern.
Mit geringem Risiko
So, das ist der Abschnitt 4-2 oder jetzt
diese Frage, die Antwort auf diese dritte Frage.
Zu einen gehen wir davon aus,
was die Definition schon sagt,
Refactoring soll keine Änderung des sichtbaren Verhaltens
mit sich bringen
Das hat, also damit ist gemeint, keine funktionellen Erweiterungen.
Soweit, soweit so klar. Aber das hat zur Folge,
und das ist etwas sehr Positives, dass die Tests,
die Unitests gültig bleiben.
Wir bleiben gültig, Sie können
weiter verwendet werden
Und damit haben wir die Möglichkeit,
dass Sicherheit zu haben
Nämlich die Sicherheit für die Entwickler,
dass sie bei Änderungen die Funktionalität nicht stören, nicht zerstören.
Damit wir davon profitieren, dass diese Tests da sind und
dass wir diese vermehrte Sicherheit haben.
Deswegen machen wir die Reihenfolge zuerst Refectoring und dann Erweiterungen.
Das Gleiche, was wir beim Re-Engineering auch schon gesagt haben
Also zuerst Refactoring mit Tests zur Absicherung.
Danach Erweiterungen durch das durchgeführte Refactoring ist die Wartbarkeit besser,
das heißt geringerer Aufwand.
Geringerer Aufwand durch verbesserte Wartbarkeit
Und neue, beziehungsweise geänderte Tests, ja, mit denen
wir die Funktionalität ändern, müssen wir natürlich die Tests anpassen.
Das ist der erste, der erste Schritt für Risikominimierung.
Ich mache mal hier eine Eins dran. Tests vorher zu machen
vor dem, die Reflektorin ohne Veränderungen und die Tests erhalten,
das ist der erste Punkt. Der zweite Punkt,
der dazu, der dem Reflektoring inne wohnt,
das sagte die Definition jetzt nicht, war,
dass Reflectoring als Folge von kleinen Schritten durchgeführt wird
Insgesamt haben wir dann trotzdem umfangreiche Veränderungen, aber durch die Folge.
So, diese kleinen Schritte sind dadurch gekennzeichnet,
dass jeder sehr klar ist, was er denn tut,
weil er ist wirklich klein.
Und jeder kann einfach
geprüft werden
Und weil sie so klein sind,
kann man sie auch leichter rückgängig machen.
Jeder kann bei Bedarf
rückgängig gemacht werden
So, das ist ein wichtiger Punkt für geringes Risiko.
Als dritten Punkt möchte ich nennen, dass wir ein systematisches Vorgehen haben.
Natürlich kann man das in die Wartbarkeit verbessern,
das kann man auch machen, aufgrund seiner eigenen Erfahrungen.
Man nimmt das Stück Kot und strukturiert es ein bisschen um,
Sichtbarkeit, Kapselung, Umbenennung, etwas auslagern,
ein bisschen schlanker machen, bessere Zerlegung nach Zuständigkeiten.
Super. Aber dann profitieren wir nicht davon,
dass wir diese beiden, die Punkte 1 und 2 haben,
nämlich,
dass wir Tests erhalten
Und zweitens, dass wir diese Folge von deinen Schritten machen,
von denen wir jeder zurückgehen können.
Sondern wir haben mit sehr viel größerem Risiko zu tun.
Und als drittes möchte ich nennen, dass wir diese Systematik
auch als Know-how auf Basis von gesammeltem Know-how haben.
Gesammeltes Know-how als Basis. Da gibt es Neudeutsch den Begriff Best Practice.
Dieser Begriff, was aus den USA zu uns gekommen,
weil er dafür steht, Best Practice ist der Idealweg zur Lösung.
Man wendet diesen Weg an, man befolgt diesen Weg und
es ist sicher, man kommt zur Lösung.
Man setzt entsprechend Regeln auf und alles wird gut.
Sowas greift in unser Leben immer mehr ein.
Sowas gibt es
immer stärker
Wir haben zum Beispiel in der Medizin,
haben wir diese Leitlinien, klar der Arzt,
davon abweichen, wenn er gute Gründe hat.
Aber erstmal gibt es diese Leitlinien,
die machen es der Krankenheit, dem Krankenhaus leichter zu planen,
die machen es in den Krankenhauskassen leichter, eine Abrechnung zu akzeptieren.
So ähnlich ist das hier auch.
Wir haben grundlegende Regeln, wie wir das machen.
Das sind diese Refactorings. Und Kataloge mit Sammlungen erfolgreicher Refactorings
Das ist ein ganz wichtiger Punkt, dass wir da auf die Basis,
dass wir das nicht etwa nur auf Kraft unserer Idee,
Inspiration machen, sondern diese Systematik anwenden.
Und als vierten Punkt möchte ich nennen,
dass wir etwas haben als Indikator,
wo denn etwas schlecht ist,
dass wir nicht einfach Wüst irgendwo was machen,
sondern dass wir uns darauf verlassen,
da gibt es Anzeichen für etwas Schlechtes und das
sind Bad Smells
Werden wir auch gleich besprechen, was das ist.
Beziehungsweise sie haben ja im vergangenen Jahr mit SE2
schon etwas zu diesem Thema gehört.
Wir können das hier in dieser Veranstaltung ein bisschen ausbauen.
Die Übung trägt da auch noch ein kleines bisschen dazu bei.
Als Anzeiger und für die Auswahl von Refactorings
So, soweit, es gibt hier vier Punkte,
die dazu beitragen, dass das Risiko geringer wird.
Und das sind die Sachen, die hier in der Frage drei erfragt werden,
durch welche Maßnahmen wird das Refactoring, wird das niedriger gehalten.
Und wir haben jetzt auch ganz klar darüber gesprochen,
warum sollte man Refactoring und Erweiterung voneinander trennen,
nämlich wegen dieser, wegen der Erhaltung der Tests.
Die Betsmerls als, als Anzeiger für den Bedarf nach Refactorings kamen jetzt hier schon vor,
aber da gehen wir nochmal etwas genauer darauf ein.
Wir schauen mal hier Noch haben wir noch etwas zur Einordnung zur Erläuterung,
was wir, warum wir diese Refactorings so einsetzen,
dass sie zur Wartbarkeit, zur Verbesserung sind.
Am Ende ist erklärt, dass nochmal das,
was wir im Zusammenhang mit dem Stage Model schon besprochen haben,
nämlich, wenn der Entwurf, wenn das Design,
wenn die Strukturen schlecht sind, ist es schwer,
brauchen wir höheren Aufwand, etwas zu verändern.
Und diese Änderung mit hohem Risiko, das war der Auslöser,
warum wir in dem Stage Model immer weiter runterrutschen,
weil wir nämlich risikoscheuen, weil wir dafür sorgen wollen,
weil Entwickler dafür sorgen, Dass das Risiko nicht so groß ist.
Deswegen machen sie keine großen Änderungen. Deswegen machen sie notwendige und Umstrukturierung
eigentlich nicht. Und das war das, was Technical Debt sagt.
Wir lassen unterlassen so etwas. Dieses Technical Debt war ja,
ich springe noch mal kurz zurück, wir hatten hier diesen Begriff dafür.
Wir haben Sachen, die liegen bleiben. Kurzfristige Lösungen,
die dazu beitragen, dass die Sachen liegen bleiben. Und das war ja,
dass hier in Stage Model, was dazu beiträgt,
dass der Verlust an Wartbarkeit so groß ist und dass wir eben nicht wieder hochgehen.
Und jetzt Refactoring als die Maßnahme, um wieder nach oben
zu kommen
Ja, so, und wir wollen versuchen,
diesen Code, die Umstrukturierung dazu zu nutzen,
um die Struktur eben zu verbessern, die Verständlichkeit zu verbessern.
So, bevor wir weitermachen mit den Bad Smells,
machen wir kurz Schluss,
dass Sie es nochmal nachlesen können und machen weiter mit der
nächsten Einheit