Schwachstellen, Analyse, das ist hier als Gliederungspunkt aufgeführt,
wirkt bei uns jetzt nicht so eine ganz große Rolle spielen,
setzen wir hier nur an,
wäre jetzt hier erkennen von Schwachstellen.
Und diese paar Schwachstellen,
weißen,
sind Entwurfsfehler
Entscheidungen, die eigentlich revidiert werden müssten,
dann müssen wir das Bildchen hier mal vom Dozenten mal ein Stück wegschieben,
nicht mehr passende Entscheidungen und aufgeschobene Änderungen,
zu denen werden wir später nochmal kommen unter dem Begriff Technical Debt.
Soweit erstmal zu dem 3-3-1
lassen Sie uns gleich weitermachen mit dem Gliederungspunktprogramm verstehen
Beim Programm verstehen, dazu haben wir hier diese beiden Fragen.
Drei Frage 1 und zwei, worin bestehen die Ziele? Programm verstehen ist eine der grundsätzlichen Herausforderungen,
wenn wir mit alter Software zu tun haben,
mit Software, die wir nicht selbst geschrieben haben,
Software, die von jemand anders übernommen ist, das,
was der Begriff Legacy ja ausdrückt.
Dazu brauchen wir eine neue Seite, die ist hier Moment,
da muss ich schnell noch mit der Gliederung gucken,
die Gliederung, der hat Linux.hess 3, 3,
2, Programm verstehen, dass wir das auch konsistent haben,
3, 3, 2, Programm verstehen.
So, wie gesagt, 3, 3,
1 hatten wir hier unten ein bisschen. Nicht,
dass sie das suchen, das haben wir nur ganz kurz,
dieses Gliederungspunkt existiert, leider quasi nicht. Also Programm verstehen,
3, 3, 2, Dabei geht es uns darum,
dass wir... Dass wir erkennen, wie ein Programm funktioniert.
Und zwar nicht nur, wie es von außen funktioniert,
was es tut, sondern wie es intern funktioniert,
also wie es technisch funktioniert
Und das ist sozusagen eine Art Wissenserwerb.
Denn wir können typischerweise das nirgendwo nachlesen,
wenn wir Glück haben, ist es gut dokumentiert,
die Bezeichner sind aussagekräftig,
aber in vielen Fällen müssen wir
die Funktionsweise uns erst erschließen
Diese Aufgabe ist sehr umfangreich, unfreundliches Datei. Vollen Wartungstätigkeiten
. Das möchte ich mit Zahlen aus einer Studie bringen,
dass das Programm verstehen. Circa 47 Prozent des Aufwands
erfordert das eigentlich ändern, die eigentliche Änderung durchführen.
25 Prozent. Testen circa 28 Prozent. Jetzt hoffe ich
mal, dass das zusammen 100 Prozent ergibt.
Ja, das tut es. Integration, das wäre ja,
dass wir zum Beispiel Daten konvertieren, wo Sachen da zusammenführen.
Deswegen, also hier, der Schwerpunkt ist,
das ist hier
das Programmverstehen
Das ist auch erfahrungsgemäß, ist das häufig so,
dass man, ich weiß nicht, wie ihre persönlichen Erfahrungen sind,
zum Verstehen brauche ich die meiste Zeit.
Manchmal auch in Schleifen, dass ich zu Anfang dachte,
ich habe es verstanden, tue ich was, merke,
oh, das war es doch nicht und dann nochmal,
nochmal zurück.
Die Herausforderungen sind vielfältig
Wir müssen vom konkreten Programmcode von den einzelnen Anweisungen abstrahieren.
Wir müssen Bezüge herstellen. Was wir aber bessern.
Bezüge. Oder zu Dingen aus der realen Welt
Zum Beispiel fachliche Objekte. Geschäftsregeln. US Cases. Ja,
also die müssen wir am Ende in der Brug in den
Programmcode herstellen. Das Nächste, eine weitere Herausforderung ist,
dass wir technische Lösungen wiedererkennen
Musik Zum Beispiel, dass wir einen Design-Pattern erkennen,
dass wir einen bestimmten Algorithmus, einen bestimmten Sortieralgorithmus erkennen.
Oder dass wir typische Strukturen für eine bestimmte Domäne erkennen
Das sind wichtige Herausforderungen und das alles erfordert nicht nur
kognitive Fähigkeiten, sondern hohes, umfangreiches Fach ist.
Dabei gibt es zwei grundlegende Vorgänge. Lassen Sie uns hier
mit einem neuen Blatt weitermachen. Und zwar zunächst erstmal.
Holt ihm ab, verstehen, wie starte also bei Anweisungen,
die ich finde
Ich finde dort irgendwelche Strukturen, sei es Programmstrukturen, Datenstrukturen.
Ich versuche Abstraktionen zu bilden und Strukturen zu erkennen,
Und dann versuche ich da in diese Bezüge herzustellen.
Im Züge zu dem, was wir hier gerade eben geschrieben hatten,
also Bezüge zu fachlicher Struktur und zu technischen Lösungen.
Ja, das versuchen wir hier herzustellen. Solche,
das wäre das Button-Up-Verstehen und am Ende habe ich Konzepte erkannt,
die Natürlich habe ich diese Abstraktionen, die ich hier gebildet habe,
die sind zunächst erst mal sowas wie eine Hypothese, eine Arbeitsthese,
mit der ich erst mal diese Idee verfolge ich und schaue nach, passt das woanders?
Und dann würde ich sagen, ja,
ich bin relativ sicher, das ist ein Entwurfskonzept,
ein Entwurfsprinzip, eine spezielle Lösung oder etwas Technisches.
Demgegenüber steht das Top-Down-Vorgehen Hm. Ich gehe aus für eine
fachliche Struktur und von Beobachtung im Verhalten des Programms.
Und Technik, dass ich Abstraktionen, technische Lösungen erwarte.
Und diese dann suche
Und ich habe dann entweder,
ich finde das oder ich finde es nicht,
das wäre die Möglichkeit, wenn ich es finde, dann Jahura,
ich habe dann diese gefunden irgendwo im Code erkannt.
Und kann solche Zuordnungen treffen, das wäre wieder das,
genau, was wir auf dem vorhergehenden Bild hier haben,
diesen Bezug herstellen, Bezug herstellen, so fachliche Struktur,
Bezug zu technischen Lösungen aufgrund eben von Erwartungen, die wir hatten.
Ja, also dem ich von Top-Down-Erwartungen bilde. Ja,
also diese beiden Vorgehensweisen existieren natürlich nicht in der puren Form
nur Top-Down oder nur beiden ab, sondern ich mische beide miteinander.
Das ist auch genau das, was die Frage hier sagt.
Wir sollen das miteinander verknüpfen. Verknüpfen in dem Fall
funktioniert so, dass wir hier,
indem wir mit Hypothesen arbeiten
. . . . Wir stellen Hypothesen auf. Wir versuchen
die zu verifizieren oder eben zu falsifizieren, also zu sagen,
ja, sie sind richtig oder sie sind falsch.
Ja, das machen wir beim Button-Up-Vorgehen,
indem wir von den Anweisungen aufgehen,
uns gucken, ob wir Abstraktionen finden,
die uns irgendwie bekannt vorkommen
Oder umgekehrt, dass wir von der fachlichen Struktur ausgehen und dann Erwartungen bilden. Das kann,
ich möchte es mit einem kleinen Beispiel illustrieren, sie erkennen,
im Quellcode, hier gibt es Anweisungen, wie so eine Art,
da wirst du eine Tabelle und das wirst du wie so eine Art Sprungtabelle.
Und sie denken sich,
so was habe ich im Compiler schon mal gesehen,
wir arbeiten Mädchen mit XML, vielleicht ist das so,
wie so eine Art Token-Tabelle, wo ich zu bestimmten Elementen springe,
die dann für den Token eine Bedeutung haben.
Und dann haben sie eine Hypothese aufgestellt, okay,
das könnte so eine Art Token-Tabellenz sein
Gleichzeitig wissen sie, das hatte das XML verarbeitet wird,
dass wir dort Token haben. Und sie gucken dann vielleicht
ganz gezielt nach bestimmten Token nach so einem Text im XML-Code,
wo man die verarbeitet, wo sind die Steuerzeichen von XML,
wo werden die verwendet.
Und dann suchen sie die und erkennen die im Quellcode.
Dieses Übergehen von dem einen zum anderen, das ist das,
was ich jetzt hier als Hypothesen bezeichnet habe.
Die Hypothese, okay, dieses XML braucht irgend sowas wie so ein Scanner.
Und da brauchen wir sowas wie eine Tokentabelle,
nehmen wir mal an, der Entwickler hat das so ähnlich organisiert,
wie man einen Compiler bauen würde
Setzt natürlich voraus, dass sie das Konzept der des Compiler-Boys kennen,
dass sie Konzepte so das Konzept an Token-Tabelle kennt.
Sonst werden sie nur merken, okay,
das ist eine Referenztabelle irgendwie. Also das ist das,
was wir hier auch vom vorhergehenden Mann sagen, Herausforderungen,
da muss ich natürlich die technischen Lösungen auch kennen,
dass ich
sie wiedererkennen kann