Der Abschnitt drin, Factoring ist etwas kürzer,
deswegen hängen wir den hier mit dran.
Dabei geht es darum, wie wir mit existierender Software umgehen.
Hier auch wieder Fragen, die wir gleich durchgehen,
aber ich möchte anknüpfen dabei, was man bei Erweiterung,
Korrekturen und so weiter, bei Änderungen macht.
Diese Änderungen hatten wir schon mal länger besprochen.
Wartung hatten wir auch schon vorher besprochen. Es kann passieren,
dass wir diese Änderungen, dass diese Änderungen negative Folgen haben.
Doch zunächst müssen wir anknüpfen dabei,
warum machen wir
die Sendung
Ja, die Änderungen müssen wir machen,
weil die reale Welt, die Welt,
die von der Software unterstützt wird, das können Produktionsprozesse sein,
das können Produkte sein, das können menschliche Handlungen sein,
die man einfach durch Computer viel einfacher macht.
Die müssen wir ändern aus irgendwelchen Gründen. Ja,
also man optimiert etwas, die Gesetze haben sich geändert oder einfach nur,
eine Datenbank wird nicht mehr unterstützt oder wir müssen jetzt ein Paket,
ein Freienwerk wechseln.
Ja, so und wir wollen das so machen,
wir wollen diese Änderungen durchführen und zwar so,
dass sie einfach gehen,
gut gehen,
inkrementell gehen,
so wie wir das von Scrum
auch kennen
Nun der Punkt, Änderungen müssen durchgeführt werden,
hatten wir gesagt, aber die Bedingungen sind häufig nicht ideal.
Häufig ist es so, dass die Struktur nicht so ganz
klar verständlich ist. Warum ist das jetzt so?
Oder wir kennen das System nicht so ganz genau.
Oder wir wissen nicht, wir haben einen hohen Zeitdruck.
Ich habe das hier mit Motivation umschrieben. Ja,
wir müssen schnell, schnell,
schnell und ob das jetzt gut ist,
ist erstmal nicht
so wichtig
Wir verstehen das System nur unverständlich, weil wir haben es
nicht geschrieben, es ist riesengroß, so etwas.
Und natürlich, wir sind uns des Risikos voll bewusst.
Es gibt diesen Spruch, never change a Winning Team.
Ja, das Gleiche kann man für Software auch sagen.
Never change a Winning System, möglichst nichts anfassen. Das heißt,
wenn wir irgendwas einbauen müssen,
eine Änderung am Mini-Job-Gesetz oder da muss eine Abteilung,
unter Abteilung gibt es jetzt Projektgruppen,
die jeweils einen eigenen Projektleiter haben, das muss irgendwie,
der Projektleiter muss als Rolle da rein.
Dann versuchen wir das nur so minimal wie möglich
zu machen, nicht so viele Aufwand.
Und natürlich, das Ganze muss sehr schnell gehen.
Wir haben nicht viel Zeit, weil wir sind für die Wartung,
wird wenig Geld ausgegeben,
deswegen wird wenig bezahlt
Wozu kommt es dann? Es kommt dazu,
dass Änderungen häufig nicht so ganz komplett durchgeführt werden,
weil man einfach das nicht System nicht voll überblickt.
Das ist gar kein böser Wille oder fehlende Qualifikation.
Der Zeitdruck ist hoch und man kennt nicht alles.
Natürlich kann man dabei auch Fehler machen.
Der Mensch macht drei Prozent Fehler, sagt man, typischerweise.
Ja, bei 100 Zeilen Code sind das drei Fehler.
Bei 10.000 Lines of Code sind das 300 Fehler.
Aber was wichtig ist, den wichtigsten Punkt möchte ich nennen,
man macht keine strukturellen Änderungen,
weil man möglichst,
weil man
das Risiko vermeiden will
Also ich füge da diese Rolle für Projektleiter ein,
aber ich ändere nicht wirklich das Konzept.
Ja, sondern ich mache da nur einen Parameter dran.
Es gibt nur einen Typen, der einen Mehrtyp in einer Wertmenge.
Und dadurch verschlechtert sich die Struktur,
dadurch verstechtert sich Verständlichkeit und die Wartbarkeit in Zukunft auch.
Dazu gleich noch zu den Fragen. Ja, also wieso
kommt es zu Änderungen? Ja, weil das die Umwelt
sich ändert. Und was ist so ein Bad Smörders,
haben wir gleich als nächstes?
Bad Smells, Bad Smell,
es riecht schlecht
Das ist ein Name, den Martin Fauler,
das Literatur kommt am Schluss, dadurch dafür eingeführt hat,
wenn Kot schlecht ist. Schlecht bezüglich Verständlichkeit, schlecht,
weil er komplexer ist, also notwendig ist, schlecht,
weil Fehler provoziert werden, weil man es eben schlecht versteht.
Oder weil die Entwurfsregeln nicht eingehalten werden. Das bedeutet nicht,
deswegen hier um unten eine kleine Definition, dass es nicht funktioniert.
Also die Tests laufen schon durch, ja,
aber es ist schlecht verständlich. Wartbarkeit war der Begriff,
den wir für Veränderungsaufwand genommen hatten,
der Aufwand Veränderungen ist hoch
Und jetzt Beispiele gleich weg in die gleich noch ein bisschen genauer durch.
Eine Methode ist sehr lang. Dadurch, das provoziert Fehler,
weil wir können gar nicht von Anfang bis Ende alles im Überblick behalten.
Etwas ist mehrfach da. Es könnte sein, wir beheben
eine Änderung, einen Fehler nur einmal oder eine Sicherheitslücke.
Ein Waver-Overflow oder irgendwas, ändern wir nur einmal statt mehrfach.
Oder Verantwortlichkeiten in einer Klasse werden sehr stark vermischt,
dann weiß man nicht genau, wo packt man das hin.
Man macht das vielleicht zweimal rein oder man findet es
überhaupt nicht. Also Bad Smells sind solche einrüchigen Stellen
Und das war, dass die Frage zwei, ja,
und ich unterscheide es sich von einem Fehler.
Wir machen mal weiter und gehen die mal in Einzelnen einige der Typen durch.
Wir können ihnen hier in einer kurzen Zeit nur so einen
kurzen Überblick geben. Ja, also zum einen Duplikat,
das sind irgendwie schwierig. Sie funktionieren natürlich und Copy Pays,
das ist eine übliche Form der Programmierung.
Ich mache ein Fenster auf und finde das fast identisch.
Ja, das kommt relativ häufig. Das Dumme ist,
wenn wir eine Änderung in einem Sub-Typ-Tubil-Card haben,
dann müssen sehr wahrscheinlich alle auftreten Duplikate
geändert werden
Und wenn man das nicht über sie macht,
wenn man das nicht findet, wenn man das nicht weiß,
dann gibt es ganz gemeine Fehler. Sie haben es gemacht,
sie sind ganz sicher und trotzdem dritter Fehler noch auf.
Dann fangen sie an zu suchen und dann, ja,
bis dahin, dass es in einem Projekt bei mir mal passiert,
dass jemand feststellt, oh, diesen ganzen Dialog,
die ganze Tabelle gibt es zweimal.
Zwischen diesen Duplikaten gibt es keine Verweise, deswegen findet man die anderen nicht.
Und das ist das, was schwierig ist.
Wir müssen davon ausgehen, Duplikate gibt es überall.
Ja, also man sagt fünf bis 25 Prozent des
gesamten Codes sind eigentlich
nur Duplikat
Deswegen ist das so, ist das schon eine ganz schöne Menge.
Und es ist auch so, dass man einfach
nur mehr Arbeit hat. Wie kann man das beheben,
Duplikate zusammenführen, indem man zum Beispiel etwas macht,
was man gemeinsam aufruft oder indem man,
was man in Oberklassen zusammenführt, abstrahiert.
Was auch beits Merz sind, wenn wir Sachen vermischen.
Zum Beispiel die berühmte Gottglas, das ist ein Bad Smell,
über den sie was nachlesen können,
dass eine Klasse sich in alles einmischt,
sich für alles zuständig führt
Das Mediator-Pattern falsch angewendet wird. Hier gehe ich jetzt nicht
weiter drauf ein. Der Keks sagt Ihnen,
das lesen Sie gern weiter, wenn Sie interessiert sind.
Also man vermischt Sachen. Und diese Vermischung von Zuständigkeiten
erfordert Wissen, was der einzelne Programmierer manchmal nicht hat.
Wir schlagen ja immer vor, trennen Sie das?
Fachliche, trennen Sie das Technische? Jeder soll seine Spezialität
haben. Und wenn wir Sachen so mischen,
dann gibt es ja plötzlich starke Kopplungen.
Dann breiten sich Änderungen stärker aus. Wenn ich eins ändere,
muss ich plötzlich ganz viel anderes ändern.
Das ist auch etwas, was schwierig ist.
Und Änderungen kommen viel häufiger für viel mehr Code vor.
Auch das führt zu mehr Änderungen, mehr Aufwand und
damit zu mehr Fehler
Die Behebung, zerlegen Sie das?
So legen Sie das in Sachen, die zuständig sind.
Aber das macht das Ganze ja schwierig. Wir haben ja
so ein Risikobewusstsein und das Risiko ist groß, dass dann die Software,
die so wichtig ist für unsere Firma, dann nicht mehr läuft.
Nächster Punkt, Kapselum wird verletzt. Kapselum ist so
ein wichtiges Prinzip von Objektorientierung, was dazu dienen soll,
dass sich Fehler nicht ausbreiten, dass Änderungen nur begrenzt lokal sind.
Aber wenn Leute das verletzen, damit es schneller geht,
damit es einfacher funktioniert oder ich brauche jetzt mal Zugriff da und da drauf,
dann diese schnellen Lösungen führen dazu, dass es insgesamt es zwar noch läuft,
aber Fehler provoziert werden, Änderungen mit höherem Aufwand sind.
Ich nenne hier einen so einen Bett Smell,
die haben meistens englische Namen, weil sie von internationalen Plattformen entwickelt sind,
Feature NV, also Neid auf Deutsch, ja,
eine Methode ist nicht zufrieden mit dem, was sie hat.
Sie hat es halt benutzt, scheinbar Sachen, die eigentlich andere haben.
Ja, vor allen Dingen Sachen aus anderen, aus anderen Klassen.
Sowas sollte man auflösen, sollte man dorthin schieben, wo das hingehört. Ja,
Zuständigkeiten sind vermischt, Übersichtlichkeit ist verringert, dadurch,
wir haben eine starke Kopplung und es fällt schwer,
die Klasse einzeln zu testen,
mal andere Klassen mit dabei sind
Und noch etwas, was das Einfache zu viel führt, auch dazu.
Ich hätte schon ganz zu Anfang genannt, nimm Syrmos lange Methode.
Wenn eine Klasse oder eine Methode übermäßig groß ist, dann ist es schwierig,
den Überblick zu bewahren, wenn ich daran was tue.
Das Fehlerrisiko steigt dadurch, Bearbeitung und Test ist schwieriger,
als es eigentlich notwendig wäre und sehr vermutlich werden da drin
Sachen vermischt, die eigentlich getrennt gehören.
Und am besten ist, wir trennen das. Wir suchen,
was gehört vielleicht, was sind vielleicht Sachen,
die nicht zusammengehören, wir zerlegen das und damit sind wir
kleinere Einheiten,
die besser handhabach sind
So, ich hatte ihn hier vier Prinzipien vorgestellt,
einige wie Feature NW und Podcast, habe ich ihn schon genannt.
Sie finden dazu noch viel mehr, diese Literaturen, diese beiden,
also diese Masterarbeit aus Helsinki und dieses Blatt hier von 2005
aus einer Firma, habe ich beide ins Mudel gelegt.
Sie können dir also gerne mal einfach mal überfliegen.
Und wenn Sie mit Ihrer Suchmaschine, gibt es noch weitere,
finden Sie noch weitere Kataloge von Badsmans. Das hilft uns,
oder das bringt es dazu, dass wir nochmal zu den Fragen springen,
ja, wir haben jetzt hier Badsmer den Nachteiligen Eigenschaften,
gerade gehört, die sind wir,
die können Sie ja gerne an einem Beispiel Ihrer Wahl erklären.
Ja, wie beheben wir das Ganze? Das war ein Betzmerz,
das sind die Sachen, die schlecht sind und jetzt das Titel,
der Titel dieses Abschnitts ist ja Refactoring,
also wir verändern etwas, refaktorisieren, etwas neu schneiden.
Und dieses Neuschneiden dafür gibt es, das kann man natürlich
irgendwie von Hand machen. Sie können einfach nur sagen,
okay, ich setze mich jetzt mal hin und mache das,
aber das Risiko ist hoch,
dass sie mit der Software dass sie an der Software etwas kaputt machen.
Deswegen empfehlen wir ihnen, und das ist das,
was mit dem Refactoring-Prinzip ist. Deswegen hat dieses Unteränderung
einen eigenen Namen, nämlich ein Refactoring. Wir versuchen,
Risikos zu verringern, etwas besser, akzeptabel für Programmierer zu machen.
Also, wir machen das Ganze als kleine Änderung.
Jede einzelne von diesen können sie leicht rückgängig machen und
man sieht sofort, da ist nichts passiert.
Damit verringern wir das Risiko. Wir machen es nur dort,
ein Stellen, wo seitens des Auftraggebers sowieso etwas
verändert werden muss
Führt dazu, wir nutzen es dazu,
dass das Verständnis über den Code sich verbreitet.
Nicht nur der Entwickler, der ursprünglich das gemacht hat,
weiß das, sondern andere kennen das auch.
Und es wird vorgeschlagen, der Kunde sollte das akzeptieren.
Ich habe hier unten gleich ein Aber hinzugefügt.
Nach meiner eigenen Erfahrung als Projekten ist es ganz schwierig,
Kunden das zu erklären, weil Refactoring tut etwas für Wartbarkeit,
für Codequalität.
Codequalität ist etwas,
was der Kunde nicht sieht
Der Kunde möchte lieber, der Auftraggeber möchte, das muss
schnell noch eingebaut werden. Diese Geschäftsregel muss noch verändert werden.
Oder diese Rolle Projektleiter muss jetzt ganz schnell eingebaut werden.
Wir brauchen das unbedingt gleich morgen. Und wenn wir dann sagen,
nein, wir machen dazu erst noch eine Reflectoring und das testen wir ausgiebig,
das dauert nicht einen Tag, sondern drei Tage,
dann sagt der Auftraggeber, nein, wozu denn brauche ich nicht?
Macht man das? Ich möchte mal zitieren, einen Spruch,
den ich gehört habe, als ich Projektleiter war,
Herr Riebisch,
wir wollen keinen Architekturpreis gewinnen
Es ist häufig ganz schwer, dass die Auftraggeber das akzeptieren,
aber sie wollen am Ende nicht akzeptieren,
wenn ihre Software durch immer solche Feuerwehraktionen ganz schnell plötzlich nicht mehr veränderbar ist.
Nicht mehr stabilisierbar, es ist kein Entwickler mehr hinkriegt,
die diese kleine Änderung einfach noch zu machen,
weil so viele neue Fehler auftreten und niemand mehr durchblickt.
Deswegen gibt es durchaus die Empfehlung. Ich denke,
die stammt von Martin Fauler aus dem Buch, was ich mehrfach zitiert habe,
was ich ja gerade als der Literatur genannt war.
Don't tell. Reden Sie nicht drüber. Machen Sie es
einfach. Er empfiehlt grundsätzlich mit jeder Veränderung,
die der Kunde bezahlt und will, dass wir immer damit einen Refactorin vorbinden.
Ja, also dieser Punkt zwei
Wir machen das immer denn, wenn wir eine kleine funktionale Änderung haben,
schauen wir uns diese Anmethode an, diese Klasse an,
damit die irgendwie schlecht ist, strukturieren wir was um.
Dass wir schrittweise Verbesserungen einführen oder Verschlechterungen nicht zulassen.
Ich möchte auf diesen Punkt Risikovermeidung eingehen.
Risikovermeidung ist etwas ganz Wichtiges und das ist das grundsätzlich.
Deswegen haben wir diese Sache, den Namen Refactoring gegeben.
Deswegen heißt es nicht nur einfach,
ich mache den Gurtschöner oder ich ändere was. Nein,
Refactoring hat etwas zu tun mit oder tiert ganz genau darauf,
dieses Risiko, ein System zu zerstören,
never change a running system,
das zu zerstören
Also, kleine Änderungen machen wir, wie schon gesagt.
Jeder kann man leicht prüfen, jeder kann man leicht rückgängig machen.
Hier ein paar Beispiele dafür. Erzeuge eine neue Klasse.
Ja, neue Klasseen schreiben. Gibt es einen Namen?
Da kann nicht viel passieren, außer den gleichen Namen gibt es schön.
Füge eine neue Methode hinzu. Da kann auch nicht viel
passieren. Kopiere den Quelltext von einer Methode in eine andere.
Da kann auch nicht viel passieren. Entferne eine Methode,
da kann schon einiges passieren,
aber wenn wir das vorher alles gemacht haben,
dass wir es rüber kopiert haben und so,
können wir sicherstellen durch Tests,
dass das System noch läuft
Also Tests, das Vorhandensein von Unitests, ist natürlich eine
ganz wichtige Voraussetzung. Dafür, dass du mit dem Entwickler
die Sicherheit vermitteln können und er die Sicherheit bekommen kann,
dass das System noch weiter arbeitet, das tut,
was ist so.
Damit diese Tests erhalten bleiben, gibt es die unbedingte Empfehlung,
Refactorings, also neue Strukturieren für Verständlichkeit und Wagbarkeit.
Nicht zu verbinden mit den Änderungen, die der Kunde will.
Also das Beispiel, was ich eben hatte,
wir müssen die Rolle des Projektleiters neu einführen.
Das machen wir erst, nachdem wir die Refactorings gemacht haben.
Wir machen erst die Refactorings,
dadurch ändert sich nichts bei der Funktionalität.
Die Tests bleiben lauffähig
Nach dem Reflektoring, machen wir den Test und dann führen wir die Rolle des Projektleiters
ein durch Änderungen und da brauchen wir natürlich ein paar neue Tests.
Das ist ganz wichtig für Risikoerhaltung, für Risikominimierung.
Und ein letzter Punkt möchte ich nennen, wir gehen systematisch vor.
Diese winzig kleinen Schritte, wie hier um ein paar Beispiele stehen,
vielleicht kommen noch ein paar Beispiele, die sind so,
dass man Fehler wirklich vermeiden kann und die Folge der Schritte,
die hat schon mal jemand ausprobiert.
Die stehen in einem Katalog, die sind geprüftes Wissen,
auch das trägt dazu bei,
das Risiko zu verringern
Natürlich ist das irgendwie, ich bin ja kreativ,
ich bin ja schlau, ich überblicke das,
warum soll ich solche simplen Schritte nach einer Anweisung machen?
Kann ich doch alles viel besser. Ja,
indem sie sich aber diszipliniert an diese Anweisungen halten,
ist ganz klar, dass sie keine Fehler machen werden.
So, wir schauen uns das mal an. Also erst zunächst,
dass mal den Martin Fauler, dessen Buch,
den ich mehrfach dispiriert habe, erwähnt habe, dem hat Erich Gamma,
der Erfinder oder Namensgeber der Designpatterns, ins Vorwort geschrieben,
das muss man doch die Werte schätzen sollen.
Manche von denen sehen offensichtlich aus,
aber fallen sie nicht in die Falle rein,
sie müssen diese kleinen, schüssel Mechanik,
diese Sache der kleinen Schritte, das mit der disziplinierten Durchführung,
das ist wirklich der Schlüssel dafür,
dass man das Ganze erfolgreich macht.
So, jetzt das als Beispiel. Wir hatten gesagt,
wenn wir etwas zu viel haben oder etwas Vermischtes, muss ich etwas ausgliedern.
Methode extrahieren, extract method ist ein so ein Refactoring aus diesen Katalogs.
Wir haben ja eben welche gesehen oder ich habe ihnen die Links gezeigt,
sie stehen im Mudel, Und wie sieht denn das aus?
Ich habe das mal hier als Bittes ist etwas vereinfacht,
wenn sie das Original anschauen, sie jetzt ein bisschen genauer noch da.
Aber hier möchte ich es ja erklären. Ja,
also zunächst, ich deklariere eine neue Methode und nehme einen Namen,
der wirklich das ausdrückt, was sie tun soll.
Übersetze ich das Ganze. Tästen kann ich das kommen,
weil das nicht auffähige Laufwege ist drin und ich sollte nur eine Fehlermeldung kriegen,
wenn irgendwie die Typen nicht passen oder der Name schon verwendet wird.
Dann kopiere ich das, was ich aus der Großen zu großen Methode rausnehmen möchte,
in die neue Methode, das kopiere ich.
Copypaste. Dabei sollte auch nichts schief gehen
Das Nächste, ich suche,
ob es da irgendwelche Referenzen gibt mit lokalen Variablen.
Die mache ich entweder entweder zu Parametern oder zu löckelhallen Variablen der neuen Methode.
Damit die ganzen Sat, dass wir die beiden Sachen getrennt werden.
Dabei, das ist nebenbei, merkt ein Schritt,
den ich hier ein bisschen vereinfacht habe.
Das macht man auch als Einzelschritte. Aber hier zu sagen,
ja, ich übersetze das neu, führe einen Test durch.
Habe ich diese Referenzen alle richtig gemacht?
Habe ich die richtigen lokalen Variablen gemacht? Funktioniert alles noch
. Wenn das noch funktioniert, super. Ansonsten kann ich
relativ einfach zurück, weil das ist ein einfacher Schritt
Und dann, ich habe die große Methode, da habe ich was rausgeschnitten.
Da platziere ich einen Aufruf. Ich übersetze das und teste
es und dann sollte es funktionieren mit den nirgendswo.
Dieses Vorgehen, in wirklich diesen kleinen Schritten,
könnte man natürlich auch einfach nur so,
ich gucke mir das an und ziehe das rüber und ändere das und das,
ohne diese Schritte machen, ohne diese Disziplin.
Aber dann ist das Risiko viel größer. Vor allen Dingen,
die Schritte sind so gestrickt, dass ich immer wieder zwischendurch testen kann.
Das ist der wesentliche Punkt. Okay, ein zweites Beispiel
, das Unbenennen einer Methode
Jemand mag sein, boah, wozu brauche ich da eine Methodik?
Muss ein System malen, die kleine Schritte umbenennen?
Habe ich schon Günther mal gemacht. Also dieses Unbenennen braucht man,
weil besser verständliche Bezeichner uns helfen, uns im Kot besser, um zurechtzufinden.
Soweit ganz simpel, ich wähle einen besseren Bezeichner,
das kann mir kein Tool abnehmen, da brauche ich wirklich etwas,
wo andere sich das Richtige vorstellen.
Das heißt, ich muss mich in André hineinversetzen. So,
normalerweise würden Sie das vielleicht einfach nur ändern und dann gucken,
wo überall, wo knallt es überall und was meldet der Compiler,
wie der Name nicht mehr vorhanden ist und das ändere ich alles
Hier ist die Empfehlung deutlich unterschiedlich. Wir sollen in eine neue Namen,
eine neue Methode machen mit diesem neuen Namen und dann den Quelltext hineinkopieren.
Und solche Anpassungen wie Methode, Feldzugriffe und sowas verschieben.
Und dann übersetzen. Schauen, ob der Compiler irgendwas meckert,
das, was nicht findet. Dann ändern wir den Rumpf
der Alpenmethode so, dass er die neue aufruft.
Das heißt, bei der Alpen bleibt nur noch der Name
erhalten und dann geht es gleich der Aufruf zu neu.
Sie ist eigentlich leer
Wir übersetzen und testen. Jetzt gibt es von der
neuen Methode eigentlich nur einen Aufrufer, nämlich die Alte.
Aber alle anderen rufen die Alte noch auf.
Es sollte kein, nichts passiert sein. Alles sollte noch
funktionieren. Trotzdem testen wir das. Und jetzt fangen wir
an und suchen alle Referenzen auf die alte Methode.
Nun ändern die so, dass sie neun aufrufen.
Jedes Mal testen. Und wenn wir das gemacht haben,
sollte es keine Aufrufe der alten Methode mehr geben,
dann können wir sie auch entfernen.
Und jetzt testen wir nochmal. Es gibt natürlich,
das Ganze ist ein bisschen komplizierter, auch hier vereinfacht Oberunterklassen.
Da muss man ein bisschen mehr beachten
Erstmal, um das Prinzip zu erklären, um das,
um zu erklären, warum machen wir das genau so?
Weil nach jedem kleinen Schritt ich leicht zurück kann,
weil ich nach jedem kleinen Schritt überschauen kann, habe ich hier was falsch gemacht.
Das Fehlerrisiko ist viel geringer und auf diese Weise,
wenn wir so mit diszipliniert mit diesen kleinen Schritten vorgehen,
haben wir ein viel kleineres Risiko, die Software kaputt zu machen.
So, dieser Schritte, das sind das, was wir
bei den Fragen hier haben. Wir haben jetzt gesagt,
dass so soll getrennt werden voneinander oder damit die Tests erhalten bleiben.
Und dieses Vorgehen haben wir jetzt an zwei Reflekte übrigens erklärt,
zum Beispiel vorgehen, Es gibt wohl noch andere, wenn sie ein anderes besser finden,
dann können sie gerne auch ein anderes erklären, wenn es zu dieser Frage kommen sollte. Ja,
es gibt eine ganze Reihe von Katalogen, die sie finden,
zum einen dieses erwähnte Buch von Martin Fauler,
der auch den Namen Refektorin geprägt hat, da wurde er betont,
nein, er hat es nur aufgeschrieben,
wir waren ein großes Team, wir haben das gemeinsam festgestellt,
dass es so etwas gibt, ja,
und es gibt noch weitere Bücher, die dann danach folgen,
zum Beispiel Kirievski, Refectoring to Patterns,
also wie führe ich Design Patterns ein durch Refectoring,
auch das ist ja etwas,
das man in Prinzipien
besser versteht
Sie sehen in den Jahreszahlen, das ist alles kein total neues Zeug,
das ist alles kein Hexenwerk, es ist erprobt,
es ist in der Industrie angekommen, aber nicht in jeder Firma.
Nehmen Sie es mit, nehmen Sie es in Ihrem beruflichen Alltag auf.
Auch hier ist es wie beim Lernen von immer,
mein Land ist nicht im Hörsal,
mein Land ist nicht durch Zuhören, freut mich,
dass Sie hier zuhören, dass Sie mir Ihr Watch schenken,
hoffentlich auch das Aufnehmen, aber Sie lernen es nur dadurch,
dass Sie es in Ihre berufliche Praxis übernehmen,
indem Sie nach und nach das eine oder andere Refactoring
selbst durchführen und das passiert,
indem Sie sich aus den Katalogs bedienen
Das, was ich bis jetzt gezeigt habe,
war alles von Hand. Tatsächlich gibt es einige Sachen,
die man daraus, die Tools daraus unterstützen können.
Ja, wir brauchen Unterstützung durch Werkzeuge, weil Werkzeuge weniger Fehler machen.
Nur wenn das Werkzeug selber einen Fehler hat. Ansonsten ist
das Werkzeug, für Disziplin ist für ein Werkzeug kein Thema.
Es macht immer Studie, das ist durch, sorry.
Dasselbe, ja. Und wir können diese Mechanics,
die kleinen Schritte, die können wir super unterstützen.
Ja, und die Entwicklungsumgebung,
wir benutzen hier Eclipse oder IntelliJ oder wie auch immer,
die unterstützen das auch weitgehend
Es gibt meistens, entweder gibt es Plug-ins oder es gibt richtig solche Funktionen.
Das hängt ein bisschen von der Programmiersprache ab, welche Dinge kompliziertes Sprachmodell haben,
wie CE Plus Plus, da kann man weniger machen,
weil nicht so richtig klar ist, was kann da passieren.
Und es ist vor allen Dingen, es ist nicht für alle Schritte das möglich.
Zum Beispiel ein gut verständlichen Namen treffen, das kann ein Tool kaum machen.
Das müssen sie machen, um zu sagen,
was ist der fachliche Name,
was es wird am besten verstanden von meinen Kollegen,
wie sehen die so drauf, wie verwende ich das?
Oder die Frage Deutsche oder Englisch hat ja
in einer der Verrückten zurückdrückenden Vorlesungen diskutiert
Also Tools helfen uns, und das macht es leichter,
diese Disziplin einzuhalten. Ja, und jetzt nochmal Literatur,
das Buch von Fouler, das Buch von Pirewski und etwas Neueres,
wo große Refekte uns und die Datenbank Refactorings drin sind,
von Stefan Rogh, Martin Lippert übrigens, zwei Leute,
die hier an dieser Uni gearbeitet haben.
Damit beenden wir die Sache, nicht ohne zwei Refactorings nochmal zu erklären,
das eine Extract Interface, also wir benutzen dieselbe Schnittstelle,
Aber es ist nur eine Teilschnittstelle.
Oder mehrere bieten die gleiche Teilschnittstelle an. Wir sollten die zusammenfassen,
dass es nur an einer Stelle ist, die Zuständigkeiten klar sind.
Auch hier, nicht etwa nur rauskopieren,
sondern da zeugen wir ein leeres Interface.
Dabei kann nichts schiefgehen. Dann deklarieren wir die Methoden
in der Klasse, wo das dazugehört.
Da sollte auch nichts schiefgehen. Dann implementieren wir das,
übersetzen, schauen, ob das funktioniert.
Das ruft bis jetzt dahin keiner auf, sollte auch nicht schiefgehen.
Und dann ersetzen wir das andere
Und übersetzen Schritt für Schritt jedes Mal, um sicherzustellen,
dass wir nichts falsch gemacht haben. Okay,
das eine Beispiel und das zweite, dieses Extract method,
lange Methoden, das hatten wir schon mal gesagt, das ist,
wo wir das auftreten, wo wir das verkürzen, auslagern.
Soweit wenden Sie das an,
machen Sie das so und es kann gut sein,
dass erfahrene ältere Kollegen Ihnen sagen wollen,
das kenne ich doch alles so,
Sie werden mehr Fehler machen als Sie.
Und Sie können natürlich Tools besser einsetzen.
Ich drücke Ihnen
die Daumen dafür