Hallo, wir sind nun mittlerweile bei Abschnitt 6-2
angekommen und damit starten wir in den Endspurt dieser Lehrveranstaltung.
Migrationsstrategien, das sind Vorgehensmuster,
die ich Ihnen hier vorstellen möchte, die inkrementell vorab arbeiten,
sehr unterstützen und damit sehr gut dazu passen zu dem,
wie wir heute in den Softwareprojekten arbeiten, nämlich iterativ.
Wir haben dazu widerfragen,
dass die Fragen beziehen sich im Wesentlichen auf diese Strategien,
auf diese Entwurfsmuster,
die Fragen 4 und die Frage
Hier ist schon die Literaturquelle angegeben,
ganz erfreulicherweise gibt es das Buch,
auf das ich mich hier mit öftersten zwei Kapiteln,
ich mich hier beziehe aufs Kapitel sechs und sieben,
gibt es jetzt im Internet zur freien Verwendung.
Sie können, Sie finden den Link im Mudel.
Frau Wiese hat den glücklicherweise gefunden.
Ich wusste das bis dahin auch noch nicht. Jedenfalls,
Sie brauchen nicht mal mehr in die Bibliothek zu gehen.
Wir verwenden Kapitel sechs und sieben, wir fangen mit sieben
an, Migrationsstrategien. Ich habe hier mal das zentrale Bild
schon mal mitgebracht und das haben Sie in den Materialien
Als nächstes Bild kommen mir dann diese Teststrategien über diese Strategien,
möchte ich mit ihnen sprechen. Die Fragen, die wir dazu haben,
beziehen sich ganz klar auf das, wie sie wirken.
Wir wollen ihnen ja nach ihrer Wirkung auswählen. Wir brauchen sie
für irgendeinen bestimmten Zweck. Und das ist hier die Hinterfrage,
vier schon mal zusammengefasst, auf welche der Ziele.
Damit können sie, sie können gleich vermuten und raten,
was für Ziele es wohl sein werden und große Überraschungen.
Das sind die allgemeinen Ziele von Software-Ring-Genering.
Wir wollen Systeme mit geringerem Risikowatten pflegen, weiterentwickeln.
Wir wollen Evolution erreichen
Sind Themen, die für uns ganz große Bedeutung haben.
Und genau das sind die Ziele, die wir mit diesen Vorgehensmustern erreichen können.
Diese Arbeit in inkrementeller Weise, diese Arbeit inkrementeller Weise durchzuführen,
ist schon der erste Punkt, das Risiko zu vermindern.
Und deswegen,
inkrementell passt das sehr gut mit den Arbeiten nach iterativen,
agilen Vorgehensweisen, wie zum Beispiel Scrum oder Extremprogramming oder noch weitere,
die heute üblich sind.
Und da können sie
diese Techniken gut einsetzen
Bei der Erläuterung würde ich jetzt mit dem mittleren,
mit dem ganzen Zentralen, Sie sehen das schon hier am Bild,
zu beginnen und kurz etwas dazu sagen.
Wir werden nicht auf alle, die es genannt sind,
einzugehen, wenn wir vor wir dann zu den Teststrategien kommen.
Also das hier ist das zentrale Bild aus Kapitel 7.
Ich habe hier immer noch die Kapitel,
die Abschnittsnummern dazugelassen, damit sie direkt den direkten Zug
zum Buch
auch haben
Auch in Bezug auf diese Frage nach den Zielen lassen Sie uns
kurz etwas gleich zu den Risiken nochmal wiederholen, zusammenfassen.
Eigentlich haben wir das ja schon in der Voranstaltung mehrfach gesagt.
Ziele sind zunächst erstmal das Verringern von Risiken.
Und diese riesigen bestehen zum Beispiel darin,
dass wir Big Bang Veränderungen Veränderungen soll das Reisen mit.
Mit sehr großen Risiken verbunden sehen.
Und deswegen versuchen wollen vorbei, diese zu vermeiden.
Und das, ja, damit das Risiko zu vermindern.
Ein weiteres großes Risiko ist viele Veränderungen gleichzeitig
Die würden dazu führen, dass Benutzer verunsichert werden. Und nun ist das leider nicht so,
dass die Benutzer, wenn sie verunsichert sind,
einfach nur ein bisschen trauriger nach Hause gehen,
sondern es ist häufig so, dass sie die Systeme ablehnen,
dass sie nicht mehr mit ihnen arbeiten wollen,
dass sie Fehler finden, wo vielleicht keine sind,
dass sie Letztlich, man kann sagen,
auch durch den Support, durch überhöht ist, sofort anfragen,
das System nachlahmlegen, aber vor allen Dingen aber,
dass sie ihren Umweltendaten ausdrücken,
nicht mehr mit dem System, nicht im neuen System,
mit dem neuen System arbeiten zu wollen.
Wir müssen also vermeiden, dass die Verunsicherung von Nutzern durch zu viele Veränderungen eintritt.
Das wäre noch ein weiterer Punkt. Ein weiteres Risiko besteht darin,
dass wir unbekannte Konsequenzen zu erwarten haben,
weil die Konsequenzen von Veränderungen aufgrund unserer Unkenntnis des Systems oder weitgehenden Unkenntnis häufig dazu führen,
dass etwas rauskommt, was wir nicht wollen,
müssen wir versuchen, unser Vorgehen zu optimieren.
Das heißt, dass wir schon gleich,
während jedes Schrittes oder nach dem Schritt gleich Feedback einholen,
um Rostoko bekommen, gibt es denn irgendwo Punkte,
die kritisch sind, die nicht funktionieren?
Oder wo wir zum Beispiel diese Benutzung Verunsicherung erreichen,
was können wir tun, um das zu verändern?
Das heißt, wir wollen nachsteuern. Das Feedback brauchen wir
, um nachzustören. Das ist der nächste Punkt,
den ich hier nennen möchte
Dass wir, dass wir die Lösungen haben,
die zu Konsequenzen führen, die wir nicht,
oder unsere Handlungen, zu Konsequenzen führen,
die wir nicht vorher absägen können.
Unser Behördenvorhersehbare Konsequenzen von Veränderungen. Und das ist ein Risiko,
das wir durch Nachsteuern Und wir können dazu Feedback einholen,
das würde uns helfen.
Dann ein weiterer Punkt ist, dass wir fehlerhafte,
nicht vollständige Lösungen haben
Ich bleibe mal bei dem Wort Veränderungen,
weil es darum geht ja schon so etwas zu machen,
wie Kohländerungen, die das Verhalten am Ende nicht beeinflussen,
aber zu einem Analog in viel führen oder sowas.
Und als letzten Punkt möchte ich hier bei den Risiken nennen,
dass wir die Daten mitnehmen.
Ja, dass wir also die Daten mit migrieren
Zu Datenmigration hatten wir ja in einer der letzten Veranstaltungen
schon einmal etwas gesagt. Also das sind die Ziele,
dass wir Risiken verhindern wollen und hier ein paar Beispiele von Risiken,
die wir so erreichen können, die wir zu sehen haben.
Schauen wir uns nach diesen einführenden Erläuterungen zu Risiken nochmal,
dass die Dinge ein, einfach nur erstmal schon von den Überschriften,
von den Titeln, der Vorgehensmuster her, so fällt wir,
gehen wir, starten wir mal hier in der Mitte,
Mic-Rates-Systems incrementally.
Nach dem, was ich über Big Bang gesagt habe,
nach dem, was sie alle über Scrum wissen,
ist das eigentlich
fast eine Selbstverständlichkeit,
Eigentlich ist doch alles, was auf dieser Folie hier steht, schon völlig klar. Ja,
also man soll die Benutzer mitnehmen, man soll ein Prototyp bauen,
wenn man es nicht ganz genau weiß, man soll Tests immer haben,
die das System begleichen, eigentlich total, total klar.
Ja, wir brauchen jedoch das hier,
weil das am Ende das, was hier in der Mitte steht,
inkrementelles Vorgehen doch so schwer zu machen ist.
Sie erinnern sich vielleicht an das Bild, was wir gesehen haben,
wo diese verschiedenen Datenbanken miteinander verknüpft sind und da waren so scheinbar
zehn Applikationen auf diesem Bild mit sechs Datenbanken und alle kreuz und quer verbunden.
Wenn die so ein Geflecht haben,
können sie eigentlich nur mit so sagt es ihnen jeder Projektleiter,
ja, das lässt diese Verknüpfung können, wenn ich auflöse,
wir müssen mit Big Bang das machen.
Das Risiko von Vorgehen, von Veränderungen wächst, überproportional stark.
Ich möchte sagen, exponentiell stark genaue Teilen habe ich allerdings nicht.
Es wird jedenfalls sehr viel stärker als linear, wenn wir
große Systeme wechseln. Wenn wir noch mal hier hingeschrieben haben,
nämlich diesen Big Bang-Ansatz, alles auf einmal verändern.
Das geht, ist noch relativ gut beherrschbar bei 100 Elementen.
Das wird schon schwierig bei 10.000 Elementen,
aber bei einer Million oder gar 10 Millionen Elemente,
da ist es eigentlich nicht mehr beherrschbar.
Das Risiko ist extrem hoch
Ich hatte vor einem Jahr ungefähr eine Gelegenheit mit einem Kollegen zu sprechen,
der bei einer Schweizer Bank,
bei der größten Schweizer Bank nach einer bestimmten Kategorie,
ein Wechsel des Kernbankensystems durchgeführt hat.
Oder jedenfalls begleitet hat auf der Seite der Risikoberater der Leute,
die einen Prozess unterstützt haben. Und ich kann Ihnen sagen,
das war ein Projekt, man hat festgestellt,
das kann man nur als Big Bang machen.
Und jeder sagt sofort, das kann nur scheitern
Aber wenn sie bei einer großen Bank den Austausch stößt,
kann Bankensystems scheitern lassen, dann ist diese Bank gescheitert.
Und da gibt es solche netten Effekte,
wie plötzlich die eintretende Unsicherheit führt dazu,
dass eine plötzlich ihre Einlagen wieder haben wollen,
was die Bank natürlich nicht hat,
weil sie die ja verliehen hat, zum großen Teil.
Und dann ist die Bank erst mal zahlungsunfähig und wenn die
Bank erst mal zahlungsunfähig ist, dann wird die beschlossen.
Und dann macht man eine Notabwicklung von Glück. Also das
wollen wir alle nicht. Wir wollen das nicht mal wissen,
so ungefähr. Aber jetzt, wir gehen zurück zur Informatikseite.
Was haben diese Leute gemacht, um zu sagen,
was das mit dem Big Bang jetzt hier so,
warum das so kompliziert ist? Die haben diesen ganzen,
das war ein Prozess über Ich glaube, acht Jahre,
ja, drei Jahre Vorbereitung und dann fünf Jahre testet,
fünf Jahre ausprobieren.
Man hat diese komplette Migration fünfmal gemacht. Man hat einen Migrationsplan gemacht,
vorbereitet, wie kann das alles gehen, wer muss alles mitspielen.
Und dann hat man so, wie eine Art Feuerwehrübung,
wo alles minutiös geplant wird oder Katastrophenschutzübungen oder wie sie so wollen.
Man hat mit allen Beteiligten und über ein Wochenende weg und
mit langen Vorbereitungen und Migrationsprogramm für die Daten.
Man hat
die komplette Migration durchgespielt
Außer, dass man das nichts davon nach außen drang.
Die Bank hat eigentlich ganz normal weitergearbeitet. Aber das ganze Team,
ich habe die Zahlen nicht präsent,
es waren jedenfalls sehr viele Leute, die beteiligt haben,
haben das ein erstes Mal geübt.
Und beim ersten Mal ging ganz, ganz viel schief.
Und man hat analysiert, was ging denn alles schief?
Warum? Wie können wir das umgehen? Was kann man
am Vorgehen ändern? Man hat es ein zweites Mal gemacht.
Nach einem Dreivierteljahr weiterer Vorbereitung einschließlich Softwareentwicklung für Migrationsprogramme.
Man hat also mit einem dann neuen Daten,
dass man dann wieder noch ein zweites Mal versucht.
Dann hat man es noch ein drittes Mal gemacht,
wieder ein halbes,
dreiviertel Jahr später
Und dann hat man es ein halbes Jahr vor dem
wirklichen Termin, hat man es ein viertes Mal gemacht.
Und bei diesem vierten Mal ging immer noch das eine oder
andere schief, aber ganz wenig.
Und man sagte, okay, wir können uns das jetzt trauen.
Und dieser Migrationstermin, den man sich ausgesucht hat,
war auch noch ein ganz besonderes Wochenende,
weil es war ein Feiertag dabei, es war ein Quartalswechsel.
Und es konnte nur an diesem Termin stattfinden.
Und die haben es tatsächlich geschöpft. Aber es war ein
gewaltiger Aufwand. Lange Vorräte, kurze Aussage,
Big Bang ist auf jeden Fall das Vorgehen,
was man vermeiden muss, insbesondere bei großem System.
Und da wir hier von geschäftskritischen Systemen reden,
müssen wir
das vermeiden
Auch wenn es diese eine ausnahmsweise Story gibt, wo mal das erfolgreich war.
Es gibt leider sehr viel mehr Storys, wo es nicht
erfolgreich war. Also versuchen Sie Big Ben zu vermeiden.
Und das geht nur, dass wir inkrementell arbeiten.
Und das ist das, was hier im Zentrum steht.
Um dieses Inkrementellarbeiten ist so schwer, weil diese ganzen Verknüpfungen
scheinbar nicht auflösbar sind. Wie können wir es trotzdem erreichen?
Wir fangen mal mit etwas relativ Selbstverständlichen an. Alles komm,
Leute, wissen das. Wir machen kurze Änderungen,
wir geben die immer wieder dem Nutzer,
wir holen Feedback ein und so weiter.
Das wäre hier der Punkt. Always have a running version
Ich gehe noch kurz auf die einzelnen Punkte ein,
was da genau dahinter steht, aber der Titel sagt ja schon fast genug.
Dann ist das, das ist eines der Punkte. Das Nächste,
der Punkte, die dazu beitragen, dass wir ein relatives,
das Risiko senken, ist diese Sache mit dem Prototyp.
Wir sind technisch orientierte Menschen, wir denken vielleicht zuerst dran,
na, der Prototyp ist dazu da,
um zu prüfen, ob es denn funktionieren kann.
Ja, super, richtig, aber,
und das hatten wir hier auf der Folie,
diese Verunsicherung von Nutzern dürfen sie nicht außer Acht lassen.
Gerade in großen Organisationen erreichen sie die Leute nicht einzeln
Da gibt es, die sind in Hierarchien eingebunden,
sie erreichen die per Kommunikation fast nicht. Wir müssen also dafür versorgen,
dass die Benutzer irgendwie vertrauen, damit vertraut hätte,
damit erzielen können, dass sie vorher damit spielen können,
dass ihre Unsicherheit abnimmt und auch dazu sind Prototypen gut geeignet.
Natürlich auch noch, um die Auftraggeber, die Geldgeber,
dem zu zeigen, was da passiert.
Das wäre also das hier, Involve the Users und Prototype
the Tucket Solution. Dann gibt es hier noch sowas ähnliches,
was auch mit dem Vertrauenschaften zu tun hat
Und Coinsurf-Familiarity hat auch mit Touristen damit zu tun,
die Veränderungen nicht zu groß werden zu lassen.
Menschen hassen Veränderungen. Ja, sie haben große Angst davor,
aber Erwachsene überspielen das, zeichnen das nicht.
Sie schieben andere Gründe vor, warum das jetzt wichtig ist.
So, von den eher technischen Sachen, wie immer eine lauffähige Version haben.
Oder immer Testwachen zu haben,
zu denen eher menschlich orientierten Sachen in Wurf the Users bird,
Confedence und so weiter, ist schon eine Weile,
aber ist schon ein Stück Abstand von der Sichtweise her,
aber wir müssen versuchen,
alles das zu haben
Und wir schauen uns dann auch diese Sachen an,
die hier unten stehen,
die eher technisch und tatsächlich für den Programmierer besser zu beherrschen sind.
Aber glauben Sie mir bitte, diese Frage,
die Benutzung mitzunehmen, ist für den Erfolg mindestens genauso wichtig.
So, und nun starten wir damit etwas zu den einzelnen Pattern zu sagen.
Für mir kommt das jetzt in einer Kurzfassung, in einer Kurzfassung,
die hoffentlich reicht, dass sie sich etwas drunter vorstellen,
wenn sie es verstehen können.
Und ich möchte sie doch durchaus einladen,
die Langfassung auch noch zu lesen.
Wie gesagt, es sind nur zwei Kapitel in diesem Buch.
Wir sind hier in Kapitel 7. Lassen Sie uns anfangen mit
7-1 in Wolf the Users
Bei dem in Walf the Users geht es dabei darum,
die Benutzer zu informiert zu halten. Die Veränderung,
die Menge von Veränderungen für die Benutzer, dadurch erträglich zu halten,
dass sie wissen, was passiert denn hier.
Nicht, dass es ein großes geheimes Projekt gibt,
wo dann auf einen Schlag mit großen Tamtam eine neue Software kommt,
die ganz anders aussieht als was sie bisher kannten.
Ein paar Unzulänglichkeiten hat, weil sie halt neu ist.
Und ansonsten viele Sachen, die sie vorher konnten,
nicht mehr macht, vielleicht weil man auch ein paar
andere Dinge damit gemacht hat,
als eigentlich gedacht wurde
Ja, also wir, die Akzeptanz erhöhen.
Wir machen das dadurch, dass die Benutzer über den Entwicklungs-,
den Reengineering-Prozess informiert sind und darin einbezogen sind
Dieses einbezogen passiert zum Beispiel darüber,
dass wir sie über Veränderungen informieren, übermieren.
Ich muss eigentlich heißen, Überveränderungen informieren,
ich kann hier zum Glück das ein bisschen schieben,
ich schreibe das gleich davor
Dass wir also den Benutzerinformationen dazu geben,
was passiert ja gerade, was sind die nächsten Schritte.
Dass wir den Benutzer informieren,
all jeden möglichen Unterstützung geben
Das kann davon gehen, dass es Wikis gibt,
wo Sachen drinsteht, dass es dem Prototyp zum Spielen gibt,
wo erstmal nichts passiert. Dass es Tutorials gibt,
dass es Workshops gibt beim Kunden, wo er damit beim Aufbenutzer,
wo er damit mit dem System gezeigt wird,
wie laufen denn seiner Arbeitsprozesse, dass man vorher eine Analyse macht,
was sind denn seine großen Befürchtungen oder was sind denn die Dinge,
die er mit dem System macht,
die man vielleicht nicht so komplett dabei hat.
Und diese Unterstützung ist dann auch
natürlich etwas mit Aufwand verbunden,
das ist ganz klar
Schreibt mir hier dieses Nummer 71 mit davor. So,
soweit das erste und gehen wir gleich mal weiter zum zweiten.
Das zweite ist hier, ich bleibe,
nehme die Folge der Nummerierung dort Confidence.
Zurück zu unserem zweiten hier, ein erinnerender Stift haben.
Gut. Bei dem Bild Confidence geht es darum,
Skeptik, Skeptis, der Benutzer zu vermeiden,
indem man ihnen die Sicherheit gibt,
den Prozess zu verstehen
Skeptische Haltung der Benutzer überwinden Durch regelmäßige Informationen Bereitstellung von Support
hatten wir eben schon gesagt, letztlich. Leichtung von Support,
wie wir eben hatten und Bereitstellung von Prototypen, das hilft jeweils.
So, der dritte Punkt ist dann dieses Zentrale,
Microrate-Systems inkrementally, das kriegen wir auf,
wenn dieses Blatt nicht mehr drauf Das ist 7-3.
Und das ist Empfehlung für das,
was eigentlich das Selbstverständlich ist,
dass wir kleine Schritte bilden,
dass wir graduell Veränderungen vornehmen und dass wir diese Veränderung jeweils immer damit verbinden,
dass es ein System gibt,
was weiterhin lauffähig ist
Kleinen Veränderungen. Dazu brauchen wir natürlich Zwischenlösungen,
das ist dann gleich ein weiteres Pattern,
was wir hier, was wir hier haben.
Und das hilft uns jeweils dem Benutzer ständig eine Laufwege,
wo es Versionen zur Verfügung haben zu geben
Am Ende sind das alles Punkte,
die nochmal separat in anderen Vorgehensmustern aufgenommen werden.
Das ist, deswegen erklären wir das jetzt in dem Zusammenhang.
Auf jeden Fall müssen wir finden. Welche von den kleinen Elementen sind gut geeignet,
zum Beispiel um so einen Cluster zu bilden,
um Blöcke zu bilden, um Versionen zu bilden.
Das ist ein kritischer Punkt,
den wir hier mit vornehmen wollen
Diese Zwischenlösungen sind etwas, was dem Benutzer hilft, einen Eindruck zu bekommen.
Aber was uns auch hilft, Feedback zum Fundbenutzer zu bekommen. Und indem wir das Feedback verarbeiten,
Sie kennen ja diesen Effekt,
dass man überall befragt wird nach dem Feedback, weil bekannt ist,
dass das allein diese Frage gefragt zu werden, ich bin wichtig,
meine Meinung interessiert hier, schon das führt dazu,
dass man sich besser mit dem System vielleicht identifizieren kann oder besser akzeptieren kann,
dass da irgendetwas vielleicht ein bisschen anders ist.
Diese Zwischenlösungen sind deswegen ein ganz wichtiger Punkt. Weil es so schwer ist,
dieses Mic-Create-Systems incumentaly in der Praxis zu haben,
sind diese ganzen Sachen, die wir hier unten haben,
mit den nächsten Nummern von 7-4 an.
Es sind am Ende Praktiken, die uns helfen,
das erfolgreich zu tun.
Lassen Sie uns mit der 7-4 starten.
Wir gehen mal wieder zu der Seite,
die wir hier haben
Dabei geht es darum, bei Prototablet, The Target Solution,
bei dem Prototyp geht es genau darum, etwas auszuprobieren,
Feedback zu bekommen,
einen Schritt zu haben, etwas Lauffähiges zu haben,
all diese Dinge helfen,
die Benutzerakzeptanz zu machen,
zu erhöhen und
technische Risiken zu verringern
Also benutze Erfahrungen zuzulassen und natürlich die Sinne zur Erfahrung
dann später einzusammeln. Und es,
natürlich ist es auch eine Hilfe, ein Prototyp zu haben,
der erstmal einen lauffähigen Zwischenschritt hat für die Entwickler
Das ist ein wichtiger Punkt, um diese Erfahrung zu haben,
aber genauso wichtig ist immer,
dass wir auch eine naufähige Version haben.
Das ist gleich
der nächste Punkt
Hier ist es ja so, dass der Name das schon eigentlich sagt,
worum es geht, dass wir immer Veränderungen am lebenden Objekt,
quasi den Benutzern, ganz frisch zeigen können.
Kurze Feedback-Schleifen. Wenn Sie sich vorstellen,
dass wir ein kleines System haben,
was drei Jahre lang entwickelt wird und dann gehen wir es zu den Benutzern,
wenn wir dann merken, und etwas wird nicht verstanden,
wird,
es ist schlecht bedienbar,
passt nicht zu den realen Sachen oder die Leute
machen derzeit etwas anderes damit,
was wir nicht wussten
Das kriegen wir alles zu spät mit,
um das noch einfließen zu lassen. Deswegen brauchen wir hier
möglichst kurzfristiges Feedback, eine erfahrene, eine lauffähige Version.
Und dass wir das inkrementell machen und die lauffähige Version haben,
das Feedback einfließen zu lassen,
können wir leichter und nachsteuern,
beziehungsweise das Vorgehen optimieren
So, aber nicht, dass sie denken, das ist so einfach.
Ja, wir müssen ja immer eine lauffähige Version zu haben,
müssen wir immer zwischen alt und neuen Ständen hin und her beschalten.
Das wird gleich eines der nächsten Punkte sein. Jetzt erstmal machen wir im Text weiter,
dass wir einen Recreation-Test haben, dass,
ich bringe mal zu dem B zurück,
dazu würde ich jetzt nichts aufschreiben,
weil wir das mit den Tests gleich nochmal separat haben,
in den Testspattern,
Test,
Vorgehenspattern,
die dann in Kapitel 6
in diesem Buch stehen
Also wir sind jetzt, haben jetzt gerade always have a Running Version gehabt,
hierzu sage ich jetzt eigentlich nichts weiter,
weil es ist schon klar, dass wir,
wenn wir lauffähige Tests haben, automatisierbare Tests möglich,
dass uns das hilft, das Risiko zu verringern.
Und das ist uns, das hilft, wenig Fehler beim Kunden zu erzeugen,
wenig Probleme beim Gründen zu erzeugen. Wenn wir mal,
ich möchte mal von dem always have a Running Version,
also wir möchten immer, dass etwas Laufähiges gibt,
egal welche Teile gerade aussehen, neu getauscht werden,
dann brauchen wir etwas, was wir im letzten Kapitel besprochen haben,
nämlich Rapper und Adapter.
Und das ist genau der Inhalt von diesem 7,
7,
das schreiben wir deswegen kurz auf
Weil wir, ups, hier waren wir schon und jetzt eine neue Seite.
Welches Stift make a bridge to the new town heißt das Ding?
Und das hat die Nummer 7,7. Im Buch.
Da gemeint ist, dass wir Rapper und Adapter benutzen.
Zum Übergang, beziehungsweise zur Koexistenz, also gleichzeitigen Existenz.
Zwischen alten und erneuerten Komponenten
Ja, also das ist das wesentliche Ziel, was wir hier erreichen wollen. So,
und das, gehen wir mal zu dem Bild zurück,
ja, dazu gehören noch, es gibt noch weitere Muster,
Vorgehensmuster, die sehr praktisch sind,
dass wir also ein korrektes Interface bereitstellen und diese Frage,
wann kommt denn so ein Interface, wann publiziert man es,
denken, na dann, wenn es reif genug ist,
wenn es keine Veränderung mehr gewinnen, wir wissen,
es ist korrekt.
Ja, und das ist hierdurch Present to Right Interface gemeint
und das durch Bayer 4-9 sehe ich gerade.
Das Ding ist Public from Published Interfaces. Ja,
wir wollen alle Interfaces an die Kunden weitergeben, darüber informieren,
aber das müssen nicht unbedingt alles Public Interfaces sein,
sondern wir können auch getrennt das machen,
dass wir manche Sachen Public machen, dass man sie benutzen kann,
aber wir andere noch viel stärker als mit Empfehlungen verbunden zum Kunden geben.
Und der nächste Punkt hier, 7-10,
ich mache auch nicht separate Überschrift, ich sage nur was dazu,
Debricate ist eine Technik, die Sie alle kennen,
denke ich jedenfalls, dass wir, dass da Compiler überwacht,
wendet irgendwo depricated, als ein Blut dransteht, dann bekomme ich erstmal eine Warnmeldung.
Und diese Warnmeldung macht mich als Entwickler darauf aufmerksam,
es gibt eine neue Version, die wird,
die Alte wird nicht mehr weit lange unterstützt sein.
Und diese Hilfe ist sehr gut für jemanden,
der entscheiden muss, was mache ich denn als nächstes.
Und da kann er merken,
zu dem und dem Teil gibt es so und so viele Sachen,
die sind alle irgendwie depricated,
dann müssen wir uns dazu vielleicht auch überhalten,
ob wir vielleicht insgesamt eine größere Änderung machen mit endgültig
Änderungen der Schnittstellen
So, das waren jetzt einige Erläuterungen zu dem Vorgehensmittel.
Und wir haben aber noch nicht weiter über Ziele gesprochen.
Doch wir haben über Ziele gesprochen,
und zwar über diese Ziele, die wir hier sehen,
Risiko vermeiden mit verschiedenen Aspekten, die wir damit anstreben.
Ja, wer ist denn mein Neusträger?
Weiter geht es nämlich mit dem nächsten Abschnitt