Wir starten jetzt mit dem Abschnitt 34.4 Refactoring bei Legacy-Systemen.
Wie sie das aus der Gliederung sehen, schließt sich das
an Refactoring. Und vielleicht haben sie sich gefragt,
was ist denn da der Unterschied? Wir erinnern uns,
das Refactoring bei 4-3 nach der Definition von Martin Fauler
hängt davon ab, dass wir oder bezieht sich darauf,
dass wir das Ganze auf Sicherheit orientiert haben und durch Tess ganz wesentlich absichern und so weiter.
Und das ist genau der Punkt, warum wir nochmal
eine andere Situation haben
Wenn wir wirklich Legacy-Systeme haben. Und zwar haben wir hier
besondere Herausforderungen und das ist gleich das, womit wir starten wollen.
Die besonderen Herausforderungen bestehen darin, dass wir,
das schreiben wir wieder auf, Legacy, wir erinnern uns,
beziehen den Begriff, beziehen wir auf wertvolle Software wertvoll,
weil sie einen hohen Geschäftswert hat,
weil sie Geschäftsprozesse wesentlich unterstützt.
Und deswegen ist sie geschäftskritisch. Deswegen ist sie wichtig,
dass sie, ist mir wichtig, dass sie erhalten bleibt.
Und die Herausforderung besteht zum einen dabei, dass Nee,
keine Besonderungsgute Qualitätentwurfsqualität haben. Ja, also ich schreibe das
mal ein bisschen, Anführungszeichen, nicht sehr hoch.
Wir haben keinen Schrott, bitteschön, das haben wir nicht.
Aber Modularität, zum Beispiel Modularität. Verständlichkeit. Nein,
das schreibt man. Das ist nicht so besonders gut.
Das ist der eine Punkt
Bestimmt durch die Legacy-Software. Du bist mit Rereengineering ist ein hohes Risiko verbunden.
Sie kennen diesen Spruch, Never Changer Winning Team.
Hier heißt er dann Never Changer Touch a Running System.
The Running soll das heißen. Das machen wir doch korrekt
Dieses Risikobewusstsein ist dadurch verstärkt,
dass wir häufig... Dass wir häufig keine so gute Struktur haben,
die Unitests in der Form zulassen,
wie wir sie bei einem Testfirst-Ansatz doch entwickeln würden.
Sondern häufig sind nur größere Tests möglich.
Das führt dazu, dass die Entwickler
sehr risikobewusst vorgehen
. Perfekt ruhigen oder wir können es noch ein bisschen allgemeiner formulieren,
Reengineering runterbleibt. Ja, eben genau, weil sie sich
weil das Reingengineering eben Gefahren mit sich bringt. So,
das führt dazu, dass weiterhin, natürlich ist,
muss man auch sagen, ganz klar,
der Auftraggeber möchte eigentlich nicht für Re-Engineering bezahlen,
weil das Reingeneering für ihn keinen sichtbaren Gewinn bringt, keinen sichtbaren Mehrwert.
Er möchte neue Features haben, neue Eigenschaften, Anpassungen,
ein bestehender Optimierung der Softwareanpassung, eine neue Geschäftsprozesse,
all das möchte er haben, aber Re-Engineering eigentlich eher nicht.
Und da die Entwickler selber noch Hemmungen haben,
machen sie das sehr selten. Ja, und im Ergebnis
Es entsteht mehr schlechter Code oder beziehungsweise Codeverschlechterung.
Es entsteht viel neuer Code mit schlechter Struktur.
Wir schreiben das mal ein bisschen eingeschränkt mit
mäßig schlechter Struktur
Seltene Surre-Engineering. Wobei man ganz klar sagen muss,
die Entwickler bemühen sich um guten Code.
Sie bemühen sich um gute Entwurfsqualität, aber die Verständlichkeit ist
nicht so hoch. Das hat damit zu tun,
dass wir halt, ups, das war falsch,
wie kriege ich denn das wieder hin hier.
Das müssen wir schnell mal reparieren
Das hieß hier Entwurfsqualität. Ich sollte ja eigentlich wischen und
jetzt ist es kaputt hier bei ihm. Und den Spruch
kriegt man auch wieder hin, never change. Mein nimmes System. Sorry,
also die Entwurfsqualität ist nicht so besonders gut, ja,
das ist hier, das ist der Punkt,
den wir hier oben nannten und dadurch ist die Verständlichkeit nicht so groß und man macht
Man macht durchaus mehr Fehler als normalerweise, als man das machen würde,
wenn man alles verstehen würde. Und zusätzlich ist natürlich so,
dass man Re-Engineering nicht macht, auch wenn es notwendig wäre,
wenn man mal eine große Klasse, die immer weiter wächst,
verkleinern sollte, wenn man eine Datenbanktabelle aufteilen sollte,
wenn man einen Pattern einführen sollte für ein Konzept,
was man irgendwie auch anders.
Man macht es so, dass es eben läuft mit geringstmöglichem Aufwand.
Und das ist die Konsequenzverschlechterung von Wartbarkeit.
Und das wird eben verstärkt durch dieses Risikobewusste herangehen, Ja,
das ist durchaus dieses konservierende Verhalten ist dann, mache ich mal durchaus.
Konservierend im Sinne von etwas aufrechterhalten, etwas erhalten,
das möchten die Entwickler, aber eigentlich tragen sie nicht dazu bei,
dass die Qualität erhalten bleibt.
Ja, so und wir könnten das auch mit dem Spruch
begründen, Angst ist ein schlechter Reitgeber
Tatsächlich gehen die Entwickler sehr vorsichtig um. Und wir können das begzeichnen,
dadurch durch die Methode Edit and Prey,
so tut es jedenfalls, so sagt es jedenfalls,
der Autor Michael Feders, der hier für die Literatur,
der uns ein Buch hier gegeben hat.
Ja, also diese Methode, Edit and Predia,
so wie er die nennt, Mir steht schon darin,
dass man wo Änderungen genau analysiert.
Wenn die Änderungen durchführt und dann prüft, aber trotz
sehr genauem Arbeiten Treten neue Fehler auf, ganz zwangsläufig.
Und zwar ist eine der Ursachen,
dass Sicherheit fehlt
Testen kann einfach nicht alle von den vorhandenen,
von den Fehlern finden, die man macht.
Und insgesamt kann man das bezeichnen, dass man ungenügend methodisch vorgeht.
Das ist eines der Herangehensweisen. Und wir sollten versuchen,
dass wir jetzt das in irgendeiner Form ändern.
Und ich schreibe mal, hey, die Literaturquelle hin,
die steht irgendwie in Literaturverzeichnissen,
Nein, Michael schreibt sich. Wenn das schon... Nee,
man merkt, dieses Buch kann ich Ihnen sehr empfehlen.
Allerdings ist es nicht wirklich schön, als Lehrbuch aufbereitet,
weil es eigentlich mehr eine Sammlung von Episoden ist.
Ich habe Ihnen das hier in meinem Text aufbereitet, die Inhalte.
Ich hoffe, Sie sind so besser verständlich und methodischer,
aber ich möchte Sie trotzdem ermutigen,
sich durchaus bei Interesse in das Buch mal reinzuschauen.
So, also ich möchte Ihnen eine bessere Methodik vorschlagen,
beziehungsweise Michael Feders schenkt uns eine bessere Methode
vor und er gibt uns,
gibt er den Namen Cover and Modify
Ihr Ball bemerkt, ist das Gegenstand der Fragen 10 und 11
, ja, die besonderen Herausforderungen beim Refactoring.
Das war die Frage 10. Und jetzt dieses Edit and Pray versus Cover and Modify ist,
ist das, was wir jetzt bei Frage 11 besprechen.
Mit diesem Cover and Modify meint er ein umfassendes Testen zu ermöglichen,
was am Ende sich auswirkt,
wie ein Sicherheitsnetz für den Entwickler
Musik Dieses Sicherheitschefnetz soll er schaffen durch durch eine Testabdeckung von
bestimmten Bereichen, wo das Verhalten,
das interessante Verhalten passiert
Und das meint er, jetzt mit Cover, nämlich so eine Art,
wie ummanteln eines Bereiches mit Test, Schutz, Schutzummandlung sozusagen.
Und das soll so eine ähnliche Rolle spielen wie das,
was wir sonst mit Kapseln machen, nämlich,
dass wir zu Ende diesen Test-First-Ansatz am Ende überführen,
für Legacy-Systeme auch.
Und dass die Frage kleine oder große Tests werden wir
im nächsten Abschnitt besprechen