Willkommen zu einer neuen Einheit von Software Re-Engineering,
nachdem wir uns bisher damit beschäftigt haben, zu analysieren,
wo Schwachstellen liegen, indem wir uns auf das Systemebene bewegt haben.
Das war das erste, zu analysieren, wo könnte,
wo sollte man darauf sich konzentrieren, wo sollte man priorisieren,
Abdeckungsanalyse, was ist überhaupt das Interessante mit der Visualisierung,
wo sind auffällige Stellen und wir untersucht haben,
was für Schwachstellen es auf Seiten des Entwurfs gibt,
bis dahin zu versuchen,
Strukturen zu erkennen,
soweit sie denn noch erkennbar sind
Wollen wir uns jetzt damit beschäftigen, wie das Ganze auf Quellcode-Ebene aussieht.
Quellcode-Ebene ist traditionell die Ebene, wo man am meisten tun kann,
weil diese Ebene, weil Quellcode natürlich verfügbar ist.
So ganz natürlich ist das nicht. Es gibt durchaus Systeme,
für die man nur den Binärcode hat,
aber die müssen wir bei dieser Lehrveranstaltung außen vor lassen.
Wir kümmern uns um Veranstaltungen, um Systeme, Legacy-Systeme,
die wertvoll sind, die es wert sind, überarbeitet zu werden,
die man braucht und für die der Quellcode auf jeden Fall
eine wichtige Informationsquelle zur Verfügung stellt,
damit wir dort Verbesserungsmaßnahmen durchführen können.
Verbesserungsmaßnahmen selbst werden im Kapitel 4 besprochen und wir sind jetzt da bei zu untersuchen,
was können wir denn auf Code-Ebene feststellen, was kann man tun,
was genau sind dort für Maßnahmen fest zu tun.
Dieser Abschnitt 3, 4 beginnt mit Bett Smells und dazu
haben wir hier so ein paar Fragen und wir fangen gleich
an damit, was ist ein Bett Smell?
Wir haben also hier 3, 4, 1 It's mells.
Und diese Bad Smells sind, wie der Name schon sagt,
irgendwie etwas Anrüchiges. Ja, anrüchig im Sinne von,
es stinkt. So hat der Autor diesen Begriff geprägt.
Und das ist ein sehr anschauliches, sprachliches Bild.
Und deswegen wurde das aufgegriffen. Ja,
es handelt sich um Mängel bezüglich Wartbarkeit,
insbesondere Verständlichkeit
Und es geht um Quellcode. Man gibt auch solche Mängel,
gibt es natürlich bezüglich Wartbarkeit und Verständlichkeit auch auf Architekturebene.
Das sind dann eher Architekturdefizite, Erosionen, das sind andere Sachen.
Wir beschäftigen uns vorrangig mit den Sachen jetzt in diesem Abschnitt,
die es auf Quellcode gibt, auf Quellcode-Ebene gibt.
Und dabei handelt es sich
nicht um Fehler
Also nichts, was ich mit dem Testen finden würde.
Also funktionieren tut das alles. Also dieses klassische Argument funktioniert doch.
Das würde bei Bad Smells, und das ist schon in Dika,
wenn jemand seinen Quellcode so begründet, könnte man schon denken,
also er weiß eigentlich schon selbst, er oder sie,
dass das so nicht gut verständlich ist.
Also es geht ganz besonders um Verständlichkeit
Bevor wir zum Beispiel kommen, warum hilft uns so etwas?
Wenn es darum geht, im Quellcode, Dinge zu finden,
solche Mängel zu finden bezüglich Wartbarkeit und Verständlichkeit,
dann kann man natürlich sagen, okay,
wir schauen uns den Code an, ein Experte wird uns sagen,
was dort dran schlecht ist und wo es schlecht ist und wo es Überarbeitung lohnt.
Und das, was wir dann tun,
ist, aber wir investieren Arbeit,
wir investieren Arbeit und insbesondere Zeit von einer knappen Ressource,
nämlich die Entwickler, die so etwas können,
die engagiert und qualitativ motiviert sind, genug sind, das zu verbessern.
Und davon haben wir nicht so viele, wie wir bräuchten.
Und deswegen ist das eigentlich eine Investitionsentscheidung.
Wir müssen uns entscheiden, worauf konzentrieren wir uns?
Wo ist das richtig? Ja? Wir brauchen das.
Home-Re-Engineering-Maßnahmen zu entscheiden, Insbesondere für das Refactoring. Das werden wir
im Kapitel 4 genauer behandeln. Da geht es darum,
um solche Verbesserungsmaßnahmen und wo sollte man Refactoring machen?
Dies für diese Entscheidung brauchen wir Entscheidungskriterien
Eigentlich ist dieses Ende, das ist eine Entscheidung über eine Investition.
Wir investieren Kraft, wir investieren Zeit, wir investieren Geld.
Und diese Entscheidung, solche Entscheidungen muss man begründen.
Und deswegen ist Betsmer, sind Betsmerls als Entscheidungskriterien.
Sehr gut geeignet
Und zwar deswegen, weil sie breit akzeptiert sind.
Und so eine Art, sie so eine Art Katalog darstellen,
ein Katalog von bösen Sachen, die man nicht machen soll.
Es gibt sowas auch für Design-Patterns, das sind
die Anti-Patterns oder Design-Flaws oder so etwas, unterschiedlich ausgeprägt.
Diese Bets Merz sind jedenfalls, sie liegen vor
Um zu sagen, das ist ein gutes Entscheidungskriterium,
das möchte ich den Weg gehen, zu sagen,
was sind denn schlechtere Kriterien?
Zum Beispiel schlechtere Entscheidungskriterien wären Ästhetik.
Nein, das schreibt man mit Haaren
Bei Ästhetik ist es so, Ästhetik liegt im Auge des Betrachters.
Also sie machen eine Kundinspektion mit jemandem und sie sagen,
sie sind der Experte oder sie sind ein bisschen erfahrener Kollege oder einfach nur ein Kollege.
Und sie sagen, hm, das und das sieht komisch aus,
das gefällt mir nicht. Und dann sagt der andere,
mir gefällt es. Und schon ist die Diskussion zu Ende
. Deswegen, Ästhetik ist als Entscheidungskriterium nicht geeignet.
Ich schreibe jetzt mal ungeeignet, weil subjektiv. Natürlich sind
Bad Smells in irgendeiner Form auch subjektiv, weil sie jemanden gefunden hat.
Ja, aber sie stehen immerhin im Katalog,
sie sind, die Community hat denen zugestimmt.
So, also Ästhetik wird irgendwie schlecht, ist schlecht akzeptabel.
So, dann könnte man natürlich noch sagen, ja,
wir haben ja Metriken. Ja, die Metriken,
die hatten wir hier, wenn ich gehe nochmal zu der Gliederung zurück,
das war irgendwo hier auf so einer Folie.
Ja, genau, wir hatten hier die Metriken hier am Anfang,
als wir uns gesamtes System betrachten konnten wollten.
Da waren sie auch gut geeignet. Sie sagen generell,
dort und dort ist was Schlechtes,
aber sie sagen uns nicht genau,
was ist wo
Untertitel der Amara.org-Community Was ist wo zu tun? Dabei helfen
Metriken uns nicht. Und dann können wir noch sagen,
natürlich, wir nehmen jemanden, der,
man hat irgendwie so ein Bauchgefühl.
Ich sage, das sieht ein bisschen schlecht aus.
Ja, das ist so ein bisschen so ähnlich
wie die Ästhetik.
Also ich könnte Intuition
durchaus nehmen
Warum nicht? Ja, Kurtinspektion wird für einen Menschen gemacht.
Und der eine ist mehr erfahren, der andere.
Wenn sie natürlich den Überguru haben, ja,
repräsentiert den Erfahrungsschatz, da wird man nicht widersprechen.
Aber wenn sie nicht ganz der Guru sind,
könnte es sein, jemand widerspricht.
Und dann ist Intuition wenig nachvollziehbar. Also, das sind
erstmal Bad Smells und warum können wir sie als Entscheidungskriterium verwenden?
Ja, wir hatten hier Was ist ein Betsmell?
Das war die Frage dazu. Lassen Sie uns hier
fortsetzen mit ein paar Beispielen. Solche Beispiele helfen uns.
Oder ich möchte ein paar Beispiele angeben.
Ich möchte Sie ermutigen, durchaus weitere zu suchen.
Wir können hier nur kurz drauf eingehen.
Ich möchte Sie einfach nur mit einem konkreten Beispiel ausstatten.
Eins gehen wir gleich mal durch und schauen,
wie wir das für Refactoring-Entscheidungen
dann verwenden können
Wir nehmen erst mal so ein relativ einfaches,
was einfach dadurch gekennzeichnet ist, dass etwas zu viel ist.
Long method ist der Name eines dieser Betts Mells.
Long method ist einfach eine Methode, die sehr lang ist.
Da können wir gleich mal das Kriterium mit den Metriken
hier anwenden, ist ein Mangel bezüglich Wartbarkeit.
Was ist daran? Es handelt sich nicht um einen Fehler
. Also diese lange Methode, die ist durchaus korrekt,
die tut, was sie soll. Testfälle laufen durch,
aber es ist die bezüglich Wartbarkeit ist etwas mangelhaft.
Und was ist daran mangelhaft
Ist wenig übersichtlich. Wenn sie so zehn Bildschirmseiten haben,
um da durchzuscrollen, durch schöne lange Methode,
dann ist doch die Gefahr,
dass ich was nicht ganz mehr in Erinnerung habe,
was irgendeine sieben Seiten vorher war, die ist relativ groß.
Und damit ist die Gefahr, dass ich was falsch mache,
das Risiko, dass ich was falsch mache, relativ stark.
Außerdem ist die Gefahr, wenn so eine Methode so lang ist,
würde man vermuten, oh, wer weiß,
da ist vielleicht einiges vermischt, was eigentlich gar nicht unbedingt zusammengehört.
Das heißt, diese Methode ist für mehrere Sachen zuständig,
schlecht modularisiert, also auch vielleicht nicht so gut bezüglich Wartbarkeit
und Strukturiertheit
Also einfach nur die Methode ist lang. Es bedeutet nicht,
es gibt sicherlich Gründe, warum eine Methode genau so lang sein muss.
Irgendwie ein komplizierter Algorithmus, der in sich
schon eingeschlossenes Ganzes darstellt und irgendwie nicht sinnvoll verlegt wird.
Solche Ausnahmefälle mag es geben. Deswegen, es handelt sich
nur um Intenikator. Nur ein Punkt, der sagt,
schau da mal genauer hin und ist das vielleicht etwas Schlechtes?
Es gibt keine Regel zu sagen,
ab 42 Zeilen ist eine Methode zu lang,
weil so viel passt genau auf meinem Bildschirm.
Nein, so scharf ist das nicht, sondern einfach,
wenn etwas sehr lang ist,
ist Verständlichkeit wahrscheinlich gering
Musik Nein, wir finden das ein bisschen anders.
Die Struktur ist eventuell
Durch Vermischung von Zuständigkeiten
So, wir können, diese Methode werden wir uns gleich
noch mal ein bisschen genauer angucken, worin die denn besteht.
Und ich möchte, aber ich möchte gleich mal zu der
anderen Frage zurückgehen, die wir hier hatten.
Wie kann man sowas die Frage 3, wie kann man
so etwas maschinell suchen? Und da haben wir,
können wir bei diesem Fall eine relativ einfache Antwort geben.
Das ist relativ leicht zu finden durch eine Metrik
Indem wir einfach nur sagen,
zeig uns die langen Methoden oder sie können die Visualisierung benutzen,
wo wir diese Code-City hatten. Sie erinnern sich,
die Höhe eines Balkens war für irgendetwas und die Länge eines Kastens,
da könnte man die raussuchen,
die irgendwie aus der Reihe tanzen und die uns sowas da fehlt.
Sowas ähnliches gibt es noch für,
gibt es noch für ganze Klassen, Large Class.
Es kann gute Gründe geben, warum eine Klasse wirklich groß ist.
Aber sehr wahrscheinlich sind da immer Methoden hinzugekommen, hinzugekommen,
hinzugekommen, die vielleicht gar nicht unbedingt dazu gehören.
Also ich habe die Übersichtlichkeit,
es beeinträchtigt quasi die gleichen Sachen, die wir hier haben.
Das wäre durchaus denkbar
Dann noch etwas, was auch mit so viel zu tun
hat, Long Parameterlist. Einfach nur ein Beispiel,
wenn wir sehr viele Parameter übergeben, könnte es sein,
dass die Zuständigkeiten nicht klar geklärt seien.
So, das nächste, was wir auch noch nehmen können,
wäre oder ein anderes, was ich angeben möchte,
was ein bisschen einen anderen Typ hat,
ist Duplicated Code
Darauf gehen wir in dem nächsten Abschnitt nochmal ein.
Das sind eigentlich Klone. Ja, also copy-paste.
So etwas, was durch Copy-paste entstanden ist,
das ist nicht wirklich ein Fehler. Es funktioniert schon,
aber ich müsste dann Änderungen an mehreren Stellen machen,
wenn sich etwas schlechter ist.
Wir gehen gleich noch drauf ein in am nächsten Abschnitt.
Dann würde ich noch etwas nehmen,
was auch bezüglich Wartbarkeit und diese Vermischung von Zuständigkeiten
ein bisschen so ähnlich ist,
einfach nur nennen
Die Vagint Change, dabei geht es darum, dass Veränderungen
dazu geführt haben, dass die Zuständigkeiten nicht mehr klar sind.
Und Änderungen betreffen dann mehr abhängiger,
als man eigentlich möchte
Sehr ähnlich mit solchen Änderungen ist noch etwas, das heißt Shotgun,
Searchery. Das ist etwas, was so ein bisschen aus
dem amerikanischen kommt. Shotgun, Searchery ist also eine,
der Name, wenn sie es wörtlich übersetzen, Schussverletzung.
Wir haben das vermutlich alle noch nicht gesehen. Wer allerdings die Jäger kennt,
der hat vielleicht da mal eine Chance zu sehen.
Also dann ist irgendwie so alles vollett zerfetzt. Das zerfetzt
meint den Code, wie er bei der Auswirkung von Änderungen aussieht.
Also ich habe eine kleine Änderung und da muss ich
dort und dort und dort überall etwas tun.
Und das, was dann passiert, ist dann,
dass am Ende das Ganze sehr zerfasert aussieht.
Also hier ist es so, dass Und die Struktur ist dabei sehr kaputt.
Und noch etwas aus Objektorientierung möchte ich nur nennen.
Parrell in Hurrigans. Higher Key. Da hat jemand Genalisierung,
Spezialisierung falsch verstanden. Hat vielleicht Parametrierung nicht eingegesetzt oder sollte vielleicht
über generische Methoden einsetzen, dass also man Vererbung oder Spezialisierungshierarchien mehrfach macht.
Und dadurch kommt es zu Duplikatenredundanz
All diese Dinge sollen ihnen nur einen Eindruck geben,
worum es bei Kuh und Merz geht.
Wir sprechen ein bisschen genauer drüber, wenn wir Refactoring machen,
wie wir einen Refactoring-Advent von Long Method machen.
Wir hatten hier noch ein paar mehr Fragen dazu und auf die
möchte ich wenigstens so ein bisschen eingehen.
Diese Fragen sind vielleicht welche, die wir nicht ganz genauso
in der Prüfung haben können
Wie zum Beispiel die hier, wie kann man Bats mehr
suchen oder wie kann man bei der Suche mit schlechten Ergebnissen umgehen?
Das ist ein bisschen eine umständliche Frage. Zum erst mal,
was ist ein qualitativ schlechtes Suchergebnis? Qualitativ eine Suchergebnissuche ist dann gut,
wenn sie präzise das liefert, was tatsächlich das Wirkliche ist.
Also, wir finden 100 Prozent von den Sachen,
die drin sind, das ist Record und alles,
was in unserer Ergebnisliste ist, ist auch wirklich ein Treffer.
Das ist Precition. Precition und Record für diejenigen von ihnen,
die sich schon mit Suche beschäftigt haben,
sind die die suchen die typischen Kriterien für die Qualität einer Suche.
Was machen wir also, wenn Presition und Rico bei der Suche,
bei der maschinellen Suche nach einem Bad Small nicht so richtig gut sind?
Dann haben wir eine Liste, die man erst mal,
die man auf jeden Fall nicht irgendwie automatisch oder mechanisch abhaken kann und sagen,
wir machen die alle weg, wir reparieren die alle,
wo gerade noch auf Knopfdruck automatisch, könnte man ja sicher denken,
sondern wir können die dann immer noch nutzen, um als Indikator zu dienen.
Also wir finden einige Punkte, wo wir sagen,
das könnte sein, das könnte sein,
das könnte sein, aber wir als Menschen entscheiden,
ist es tatsächlich ein Bad Small oder ist es vielleicht ein positiv,
ein Treffer, der nicht wirklich ein Treffer ist.
Also indem wir einfach, wir können die trotzdem,
diese Suchergebnisse sind trotzdem hilfreich bei der Suche,
aber wir müssen die Suche, sie macht die Suche nur ein bisschen aufwendiger.
Wir müssen einfach bei als weiteren Suchschritt oder als weiteren Schritt vor der Bearbeitung
erstmal nochmal genauer prüfen. Dann können wir trotzdem damit umgehen,
auch wenn wir etwas schlechter finden. Ja, so,
dann noch, Bads Mels auf Architektur und Code-Ebene.
Darauf möchte ich auch noch eingehen, dass es nämlich
unterschiedliche Ziele gibt
Manchmal haben wir, wir haben ja vorher davon gesprochen,
von Entwurf, von Architekturqualität, im vorgehenden Abschnitt.
Und hier sprechen wir von Code-Qualität. Und es kann durchaus sein,
dass wir auf Code-Ebene etwas haben, was irgendwie komisch aussieht,
aber es ist eigentlich so gerollt.
Beispiel, wir wollen ein klares Interface haben,
was nach außen alles bündelt, was an Informationen rausgeht.
Und dieses Interface könnte man zum Beispiel bilden mithilfe einer Fassadenklasse
oder sowas,
mit dem versagen müssen
Und dann könnt ihr natürlich so eine Bets Maul sagt dann,
oh, das ist eine Klasse, die hat ganz viele Methoden,
aber kaum Operationen, also kaum Quellcode, die macht fast nichts.
Sie macht eigentlich nur Durchleitung. Könnte die denn vielleicht
etwas sein, die sich so Zuständigkeiten von anderen aneignet?
Da gibt es auch noch einen Namen dazu,
NB Neid und diese Methoden, die sind solche,
könnte dann als etwas Schlechtes verstanden werden.
Was ich damit sagen möchte, ist,
es gibt manchmal Kompromisse auf der Code-Ebene oder Kompromisse auf der Architekturebene,
die man eingeht,
um jeweils andere Ebene besser zu machen
Also es kann durchaus sein, wir haben ein bestimmtes Architekturmuster
und nehmen dafür Smells auf Code-Ebene in Kauf.
Es hat also gar keinen Zweck, alle Kurzmerz wegmachen zu wollen.
Es kann sein, dabei beeinträchtigt man die Architektur.
Und sowas nebenbei bemerkt, sowas gibt es auch für Testbarkeit.
Es kann sein, sie machen Super, wollen super coole
Tests machen und dabei beeinträchtigen sie die Lesbarkeit des Codes ein bisschen.
Also man kann nicht jedes Ziel gleichzeitig gut erreichen und deswegen gibt es hier,
muss man hier bei Bad Smells auf Architektur und Kohlebene manchmal Kompromisse machen und sie unterscheiden sich,
die Frage zählt ja auf Unterscheidbarkeit,
sie unterscheiden sich vor allen Dingen in den Zielen,
die ich erreichen möchte
Also möchte ich eine klare Struktur im Großen haben,
wie zum Beispiel klare Zuständigkeiten auf klassen Modulebene?
Oder möchte ich gut lesbaren Code haben? Das wäre
die Code Smells. Oder die Qualität auf Code Ep.
Soweit zu diesem Thema