Glanz: AI MOOC Plugin f57d4cf6ddfed972564e676627867444

2026-10-21T22:13:41Z

AI MOOC Plugin f57d4cf6ddfed972564e676627867444

Neue Seite

{{T}}

{{BR}}
= Einleitung =
'''Zielgruppe:''' Auszubildende im 2. und 3. Ausbildungsjahr. '''Voraussetzungen:''' A1 oder grundlegendes Python, Dateien, Git und einfache Tests. '''Lernumfang:''' fünf bis sieben Unterrichtsstunden plus Projektarbeit.

'''Lernziel:''' Du lieferst ein kompatibles Refactoring des Importmoduls einer erfundenen Messdaten-App. Dafür sicherst du vorab das beobachtbare Verhalten, machst den Code verständlicher, führst Tests aus, prüfst die öffentliche Schnittstelle und dokumentierst eine Rücknahme. Drei Prüffragen begleiten alle Schritte: '''Sind die Ergebnisse gleich? Ist die Schnittstelle erhalten? Kann ich die Änderung zurücknehmen?'''

Die vorhandene [https://moocwiki.org/index.php?curid=60512 Grundlage auf MOOCwiki] dient als Wiederholung. Ihr aktueller Inhalt war am 22.10.2026 extern nicht lesbar; deshalb werden hier keine unbelegten Details darüber behauptet. Rufe aus deinem Vorwissen Funktionen, Dateiverarbeitung, einen Git-Commit und einen Soll-Ist-Test ab. Der Schwerpunkt liegt auf dem '''neuen Lernprodukt''', nicht auf Wiederholung. Sämtliche Messdaten, Namen und Beispiele sind synthetisch. Alles ist ohne bezahltes KI-Konto, lokal und offline bearbeitbar. Die verwendeten öffentlichen Medien sind freiwillig. Es werden keine realen Maschinen bedient, keine Sicherheitsfreigaben erteilt und keine vertraulichen Daten verarbeitet. Das Bildungsangebot ist unabhängig und weder eine offizielle Liebherr- noch eine IHK-Zertifizierung.

{{BR}}
= Warum bestehender Code Pflege braucht =
{{BR}}
== Refactoring als kontrollierte Änderung ==
'''Refactoring''' heißt: Die innere Struktur eines Programms wird verbessert, während sein vereinbartes, von außen beobachtbares Verhalten gleich bleibt. Diese Abgrenzung geht auf die etablierte Definition bei Martin Fowler zurück. '''Lesbarkeit''' meint verständliche Bezeichner und einfache Kontrollflüsse. '''Wartbarkeit''' beschreibt, wie gut ein anderes Team in Zukunft Fehler finden und Änderungen sicher umsetzen kann. '''Kohäsion''' ist die Zusammengehörigkeit einer Funktion; '''Kopplung''' beschreibt Abhängigkeiten zwischen Modulen.

Eine lange Funktion kann Einlesen, Prüfen, Berechnen und Ausgeben vermischen. Das erschwert Fehlersuche und Tests. Eine kleine Hilfsfunktion kann dagegen die Verantwortung klarer abgrenzen. Aber: Eine neue Eingaberegel, ein neuer Datentyp oder eine andere Fehlermeldung ist nicht automatisch Refactoring. Ein solches verändertes Verhalten braucht eine eigene, fachlich abgestimmte Änderung. Ziel ist nicht möglichst wenig Code oder jede erdenkliche Abstraktion, sondern ein besser verständlicher und verlässlich veränderbarer Entwurf.

{{BR}}
== Kleine Schritte und überprüfbare Annahmen ==
Führe zuerst die bisherigen Tests aus. Ändere danach nur einen zusammenhängenden Teil, lies den '''Diff''' (die Darstellung der Unterschiede), teste erneut und sichere einen kleinen '''Commit''' (gespeicherten Versionsstand). Wiederhole dies nur bei grünem Ergebnis. Das ist sicherer und erklärbarer als eine vollständige Neuschreibung des Imports auf einmal. Ein schönerer Quelltext ist für sich allein kein Kompatibilitätsnachweis.

[[File:Software Development Lifecycle Diagram.png|360px|frameless|center|alt=Zyklisches Schaubild der Phasen Entwicklung Test und Wartung]]
'''Bild und Offline-Alternative:''' Der Softwarelebenszyklus umfasst wiederholte Entwicklungs-, Test- und Wartungsphasen. [https://commons.wikimedia.org/wiki/File:Software_Development_Lifecycle_Diagram.png Dateiseite], Shawn Rider, [https://creativecommons.org/licenses/by-sa/4.0/ CC BY-SA 4.0]. Ohne Grafik: Zeichne einen Kreis aus Verstehen, Testen, Ändern und erneuter Prüfung.

'''Vertiefung:''' Mehr Hilfsfunktionen können auch zu einer unübersichtlichen Verteilung führen. Begründe die Auslagerung immer anhand einer tatsächlich klarer abgegrenzten Aufgabe.

{{BR}}
= Den bisherigen Vertrag mit Tests sichern =
{{BR}}
== Beobachtbares Verhalten und Rückwärtskompatibilität ==
Ein '''Schnittstellenvertrag''' umfasst Eingaben, Aufruf, Ergebnisse und vereinbarte Fehler. Ein bestehender Aufrufer erwartet in unserem Modell die Funktion '''importiere(text)'''. Sie nimmt einen Text entgegen und liefert eine Liste von Paaren (Name, Zahl). Jede nichtleere Zeile besteht aus Name, Semikolon und Zahl, etwa "Pumpe;12,5". Dezimalkomma und Dezimalpunkt werden akzeptiert. Leere Zeilen werden ausgelassen; die Reihenfolge bleibt erhalten. Eine Zeile mit drei statt zwei Feldern erzeugt einen ValueError mit Zeilennummer.

{| class="wikitable"
! Kriterium !! Nachweis an konkreten Beispielen
|-
| '''Gleiche Ergebnisse''' || Vorher und nachher ergeben "Pumpe;12,5" und "Ventil;7.0" dieselbe Liste mit Zahlen 12.5 und 7.0 in identischer Reihenfolge.
|-
| '''Schnittstelle erhalten''' || Derselbe Aufrufer verwendet weiter importiere(text), bekommt eine Liste und bei falscher Spaltenzahl denselben vereinbarten Fehlertyp und Fehlertext.
|-
| '''Änderung zurücknehmen''' || Nach einem grünen Testlauf wird der überschaubare Refactoring-Schritt separat in Git gesichert; im Fehlerfall lässt er sich gezielt umkehren.
|}

'''Fehlerfall:''' Bei "Pumpe;1;2" muss der Fehler "Zeile 1: Spaltenzahl" entstehen. Wenn die neue Version diesen Datensatz schweigend auslässt, ist die zugesagte Wirkung verändert. Ein Test, der ausschließlich gültige Eingaben kontrolliert, würde diese Regression übersehen. Nicht spezifizierte Sonderfälle wie NaN und nicht endliche Zahlen müssen vor einer Verschärfung der Importregeln ausdrücklich verhandelt werden.

{{BR}}
== Tests als beobachtbare Beweise ==
Ein '''Regressionstest''' sucht nach unerwünschten Rückfällen. Er umfasst Normalwerte, Randbedingungen, Fehlerreaktionen und bestehende Nutzer der Schnittstelle. Ein '''Unit-Test''' prüft einen kleinen Teil isoliert, ein Integrationstest das Zusammenspiel mehrerer Teile. Grüne Tests sind ein guter Beleg für geprüfte Fälle, kein Beweis für alle möglichen Daten, Plattformen und Versionsstände.

[[File:Testing Pyramid.svg|360px|frameless|center|alt=Testpyramide: viele Unit-Tests unten, weniger Integrationstests, wenige End-to-End-Tests]]
'''Bild und Offline-Alternative:''' Unter vielen schnellen Komponententests liegen die Grundlagen der Pyramide; darüber stehen weniger übergreifende Tests. [https://commons.wikimedia.org/wiki/File:Testing_Pyramid.svg Dateiseite], Abbe98, [https://creativecommons.org/licenses/by-sa/4.0/ CC BY-SA 4.0]. Ohne Grafik: Stelle drei Ebenen in einer Tabelle gegenüber und beschreibe, was jede prüft.

{{BR}}
= Geführtes Werkstattbeispiel: das Importmodul =
{{BR}}
== Ausgangszustand lesen ==
Lege eine Datei importmodul.py mit diesem '''frei erfundenen''' Ausgangscode an. Beachte: Eine Zeile wird nur dann ignoriert, wenn sie leer oder ausschließlich aus Leerzeichen besteht. Ein ungültiger Zahlenwert kann ebenfalls einen ValueError auslösen.

<pre>
def importiere(text):
daten = []
for nummer, zeile in enumerate(text.splitlines(), 1):
if not zeile.strip():
continue
teile = zeile.split(";")
if len(teile) != 2:
raise ValueError(f"Zeile {nummer}: Spaltenzahl")
daten.append((
teile[0].strip(),
float(teile[1].strip().replace(",", "."))
))
return daten
</pre>

'''Arbeitsdiagnose:''' In einer Schleife sind Filterung, Zerlegung, Prüfung, Umwandlung und Anhängen eng verschachtelt. Die bestehende öffentliche Funktion soll dennoch erhalten bleiben. Schreibe drei beobachtbare Anforderungen auf, bevor du Code bearbeitest.

{{BR}}
== Vier Basistests vor jeder Veränderung ==
Speichere Folgendes in test_importmodul.py und starte lokal '''python -m unittest -v'''. unittest gehört zur Python-Standardbibliothek; auch die spätere Lösung benötigt kein externes Konto.

<pre>
import unittest
from importmodul import importiere

class ImportTests(unittest.TestCase):
def test_normalfall(self):
eingabe = "Pumpe;12,5\n\nVentil;7.0"
self.assertEqual(
importiere(eingabe),
[("Pumpe", 12.5), ("Ventil", 7.0)]
)

def test_leer(self):
self.assertEqual(importiere(""), [])

def test_falsche_spaltenzahl(self):
with self.assertRaisesRegex(
ValueError, "^Zeile 1: Spaltenzahl$"
):
importiere("Pumpe;1;2")

def test_schnittstelle(self):
wert = importiere("Sensor;0")
self.assertIsInstance(wert, list)
self.assertEqual(wert[0], ("Sensor", 0.0))

if __name__ == "__main__":
unittest.main()
</pre>

Halte Anzahl und Ausgang der Tests, Python-Version und Commit-Kennung fest. Wenn bereits vor der Änderung ein Test rot ist, stoppe die Umstrukturierung und kläre den Ausgangszustand. Beurteile, welche weitere Randfallprüfung notwendig wäre. Teste nicht nur neue Eigenschaften, sondern besonders die alten Zusagen.

[[File:Testgetriebener Entwicklungsprozess.svg|320px|frameless|center|alt=Deutsche Ablaufgrafik zum Zyklus von Test und Implementierung]]
'''Bild und Offline-Alternative:''' Die Grafik zeigt wiederholte Test- und Entwicklungsschritte. [https://commons.wikimedia.org/wiki/File:Testgetriebener_Entwicklungsprozess.svg Dateiseite], MovGP0; Lizenzhinweis auf der Dateiseite vor Weiterverwendung selbst kontrollieren. Unser Beispiel verwendet zunächst Charakterisierungstests für bereits vorhandenes Verhalten. Ohne Bild: Schreibe „Test vor Änderung – kleiner Schritt – derselbe Test erneut“.

{{BR}}
== Ein verhaltenserhaltender Eingriff ==
Ersetze nun '''nur''' den Inhalt von importmodul.py durch diese klar gegliederte Variante. Die Hilfsfunktion ist als intern gekennzeichnet. Keine neue Regel wird hinzugefügt.

<pre>
def _lese_zeile(zeile, nummer):
teile = zeile.split(";")
if len(teile) != 2:
raise ValueError(f"Zeile {nummer}: Spaltenzahl")
name = teile[0].strip()
wert = float(teile[1].strip().replace(",", "."))
return name, wert

def importiere(text):
daten = []
for nummer, zeile in enumerate(text.splitlines(), 1):
if not zeile.strip():
continue
daten.append(_lese_zeile(zeile, nummer))
return daten
</pre>

'''Prüfe konkret:''' Erstens müssen alle vier vorhandenen Tests mit '''unveränderten''' Erwartungen erfolgreich sein. Zweitens dürfen importiere(text), Listenformat und vereinbarter Fehlertext nicht geändert sein. Drittens muss die Änderung in einem eigenen Commit oder als benannte Vorher-Kopie zurücknehmbar sein. Prüfe den Diff: Wenn ein Agent auch test_importmodul.py heimlich verändert hat, ist sein Ergebnis kein ausreichender Nachweis. Bewahre unveränderte Ausgangstests auf.

'''Fehlerfall begründen:''' Eine fehlerhafte Zeile kann auf einen versehentlichen Exportfehler hinweisen. Laut unserem Übungsvertrag ist die passende Reaktion eine Ausnahme. Lautloses Überspringen wäre nicht nur eine andere technische Implementierung, sondern könnte fehlerhafte Eingangsdaten verschleiern.

{{BR}}
== Importprüfung ausdrücklich als zweite Anforderung ==
Erst nach dem Refactoring soll die Messdaten-App optional strengere '''Importprüfung''' erhalten: Leere Namen und nicht endliche Zahlen werden dann abgelehnt. Das wäre eine '''bewusste Änderung des Außenverhaltens''', weil die Altversion beispielsweise " ;5" nicht zurückgewiesen hat. Formuliere zuerst Akzeptanzkriterien und eigene Tests; entscheide mit dem Auftraggeber, ob eine neue Funktion oder eine versionierte Schnittstelle benötigt wird. Implementiere diese Erweiterung in einem '''separaten Commit'''. Bewahre ältere Aufrufer und deren Datenformate im Blick. Nenne dies nicht Refactoring, auch wenn der Code dabei lesbarer wird.

{{BR}}
= KI-Agenten, Berechtigungen und menschliches Review =
{{BR}}
== Enger Auftrag statt pauschaler Autonomie ==
Ein Coding-Agent ist ein Werkzeug, das Vorschläge erstellt und mit begrenzten Berechtigungen Projektfunktionen verwenden kann. Seine Erklärung, alles sei korrekt, ersetzt weder ausführbare Tests noch Review. Der folgende Auftrag lässt sich auch ohne KI als persönliche Arbeitsliste nutzen:

<pre>
Projekt: synthetische Messdaten-App.
Ändere nur importmodul.py.
Ziel: Zeilenparser intern auslagern.
Nicht ändern: importiere(text), Rückgabeliste,
Reihenfolge, Fehlerklasse, vereinbarter Fehlertext.
Nutze unveränderte bestehende unittest-Tests.
Keine Netzwerkzugriffe, neuen Pakete oder Geheimnisse.
Keine Produktionsdateien, keine Maschinenbefehle.
Liefere Diff, Testprotokoll, Risiken, Rücknahmeplan.
Frage bei Vertragsunsicherheit vor jeder Änderung.
</pre>

'''Least Privilege''' heißt minimal nötige Rechte: zunächst lesen, anschließend nur für die ausdrücklich ausgewählte Datei schreiben, Tests ausschließlich in einer isolierten Lernumgebung. '''Prompt Injection''' bezeichnet eine Manipulation, bei der ein fremder Text wie ein höherwertiger Handlungsauftrag erscheinen soll. Auch README-Inhalte, Kommentare oder Toolantworten können solche Anweisungen enthalten; sie überschreiben nicht den menschlichen Auftrag. Ein Agent darf sich weder selbst reale Betriebsrechte erteilen noch eine Sicherheitsfreigabe ersetzen.

{{BR}}
== Review- und Freigabegrenzen ==
Ein '''Review''' kontrolliert Risiken unabhängig von der Codeerstellung. Ein menschlicher Reviewer prüft den Diff, die Testbasis, öffentliche Schnittstellen, Grenzfälle, Änderungen außerhalb des Auftrags und den Rücknahmeweg. Bei fehlender Evidenz wird nicht gemergt. Ein fachlicher Änderungswunsch und ein technisches Refactoring werden als getrennte Arbeitspakete protokolliert.

{| class="wikitable"
! Tätigkeit !! Grenze !! Nachweis
|-
| Änderung vorschlagen || Nur synthetisches Projekt || Sichtbarer Diff
|-
| Tests ausführen || Lokale Übungsumgebung || Wiederholbarer Testlauf
|-
| Neue Importregel beschließen || Mensch mit Fachverantwortung || Akzeptanzkriterien
|-
| Merge genehmigen || Berechtigter menschlicher Reviewer || Review-Protokoll
|-
| Reale Maschinen steuern || Hier ausdrücklich verboten || Keine Verbindung vorhanden
|}

Die [https://modelcontextprotocol.io/docs/2026-07-28/tutorials/security/security_best_practices MCP Security Best Practices, Stand 28.07.2026] behandeln unter anderem Risiken von Berechtigung und Weitergabe von Tokens bei MCP-Implementierungen. Das [https://doi.org/10.6028/NIST.AI.600-1 NIST-Profil AI 600-1, Juli 2024] unterstützt die strukturierte Betrachtung generativer KI-Risiken. Diese Leitlinien ersetzen '''keine''' Produktprüfung und bestätigen nicht, dass irgendein konkreter Agent, eine Maschine oder dieses Übungsprogramm sicher ist.

{{BR}}
== Git als Rücknahme- und Reviewhilfe ==
Erstelle einen eigenen Arbeitsbranch, committe die Tests und die Strukturänderung getrennt und lass die Änderung prüfen. '''git diff''' zeigt die Änderungen. '''git status''' zeigt den Arbeitsstand. Für eigene ungesicherte Änderungen ist vor git restore eine Sicherung wichtig. Ein bereits gemeinsam geteilter Commit wird in der Regel mit einem dokumentierten '''git revert''' durch einen Gegencommit rückgängig gemacht, statt gemeinsame Historie unkontrolliert zu überschreiben. Prüfe nach jeder Rücknahme erneut die Tests.

[[File:Basic git branching workflow (GitLab).svg|420px|frameless|center|alt=Git-Arbeitszweig mit eigener Änderung und geplanter Integration]]
'''Bild und Offline-Alternative:''' Branch, Prüfung und Zusammenführung werden getrennt gedacht. [https://commons.wikimedia.org/wiki/File:Basic_git_branching_workflow_(GitLab).svg Dateiseite], TheresNoTime, [https://creativecommons.org/licenses/by-sa/4.0/ CC BY-SA 4.0]. Ohne Bild: Skizziere main – Übungsbranch – Review – Merge.

[[File:Merge bugFix.gif|320px|frameless|center|alt=Animierte Git-Geschichte eines Bugfix-Branches beim Merge]]
'''Animation und Offline-Alternative:''' Ein Bugfix-Zweig wird zusammengeführt; notiere die Commit-Abfolge als Text. [https://commons.wikimedia.org/wiki/File:Merge_bugFix.gif Dateiseite], MonkeyWaffle, [https://creativecommons.org/licenses/by-sa/4.0/ CC BY-SA 4.0].

'''Video, deutsch:''' {{#ev:youtube|https://www.youtube.com/watch?v=v1ibwg3zaQQ|500|center}} [https://www.youtube.com/watch?v=v1ibwg3zaQQ Git in 60 Minuten, Mit Mario, 2022]. Der öffentliche Videoeintrag beschreibt unter anderem Branch, Merge und Rücknahme. Verfügbarkeit und Einbettung können sich ändern. '''Offline:''' Erkläre anhand einer eigenen gezeichneten Commitfolge, wie du eine schlechte Änderung isoliert zurücknimmst.

{{BR}}
= Selbstständiger Transfer und langfristige Wartbarkeit =
{{BR}}
== Eigenständiges Importmodul liefern ==
Erstelle auf Grundlage der zwei Beispielversionen ein eigenes, '''kompatibles''' Refactoring. Ergänze mindestens zwei weitere Charakterisierungstests. Nutze absichtlich einen Fehlerfall, etwa "Motor;3;5", und begründe die erwartete Reaktion. Prüfe die drei Kriterien im Abgabeprotokoll nicht nur mit Ja oder Nein, sondern mit tatsächlicher Eingabe, tatsächlichem Ergebnis, Funktionsaufruf und Rücknahme-Commit. Optional überträgst du denselben Ablauf auf ein neues synthetisches Importformat; dessen Verhaltensänderung ist klar getrennt zu kennzeichnen.

{{BR}}
== Wartung in sechs Monaten ==
Eine kurze README enthält: öffentlichen Vertrag, Beispielzeilen, Testbefehl, bekannten Fehlertext, Python-Version, akzeptierte Grenzen, offene Fragen und Rücknahmeverfahren. Beschreibe, wie eine unbekannte Person die Tests reproduzieren kann. Prüfe bei neuen Python-Versionen erneut; übertriebene Abstraktion, versteckte Abhängigkeiten und ungeklärte KI-Vorschläge erhöhen Wartungskosten. Bewerte die Änderung nach Verständlichkeit und unabhängiger Wiederholbarkeit, nicht nach der Menge erzeugten Codes.

'''Video, englische Vertiefung:''' {{#ev:youtube|https://www.youtube.com/watch?v=bsU7AFjh4m8|500|center}} [https://www.youtube.com/watch?v=bsU7AFjh4m8 ArjanCodes: Python-Code schrittweise überarbeiten, 2025]. Der Inhalt betrifft allgemeine Python-Lesbarkeit und nicht die erfundene Messdaten-App. '''Offline:''' Identifiziere selbst drei Verbesserungen in der ausgelagerten Hilfsfunktion.

'''Hörimpuls:''' [[File:Computer keyboard.ogg|none|Geräusche einer Computertastatur]]. [https://commons.wikimedia.org/wiki/File:Computer_keyboard.ogg Dateiseite], russiandoll, Public Domain. Die Geräusche belegen Aktivität, '''nicht''' korrektes Programmverhalten: Erkläre, warum ein vorzeigbares Testprotokoll stärkere Evidenz ist. '''Ohne Ton:''' Stelle Tätigkeitsbericht und Testergebnis schriftlich gegenüber.

{{BR}}
= Interaktive Aufgaben =
Bei den Multiple-Choice-Aufgaben gibt die interaktive Quizfunktion eine Richtig-/Falsch-Rückmeldung. Die Lösungen werden nicht als frei sichtbare Antwortliste vorangestellt. Nach jeder Aufgabe sollst du zusätzlich einen belegbaren Grund für deine Wahl formulieren.

{{BR}}
== Quiz: Teste dein Wissen ==
{{MC}}
'''Was unterscheidet Refactoring von einer neuen Funktion?'''
(Die innere Struktur ändert sich bei gleichbleibendem vereinbartem Verhalten)
(!Neue Dateiformate sind automatisch erlaubt)
(!Der Funktionsname muss immer geändert werden)
(!Tests werden nach der Änderung gelöscht)
{{E}}

{{MC}}
'''Wie lässt sich das Kriterium gleiche Ergebnisse konkret prüfen?'''
(Alte und neue Version mit identischen Eingaben vergleichen)
(!Nur die Zahl der Zeilen vergleichen)
(!Nur eine KI nach ihrer Einschätzung fragen)
(!Nur auf eine schöne Formatierung achten)
{{E}}

{{MC}}
'''Was gehört zum Schnittstellenvertrag des Beispiels?'''
(Funktionsname Argument und vereinbarter Rückgabewert)
(!Nur der Name einer lokalen Variablen)
(!Die Farbe des Editors)
(!Die Dateigröße eines Screenshots)
{{E}}

{{MC}}
'''Was bedeutet es wenn eine neue Prüfung bislang erlaubte Daten ablehnt?'''
(Es ist eine gesondert zu vereinbarende Verhaltensänderung)
(!Es ist immer nur eine kosmetische Änderung)
(!Die alten Tests dürfen still gelöscht werden)
(!Es ist automatisch rückwärtskompatibel)
{{E}}

{{MC}}
'''Warum ist ein Test für eine fehlerhafte Zeile wichtig?'''
(Auch ein vereinbarter Fehlertyp gehört zum beobachtbaren Verhalten)
(!Fehler dürfen stets ignoriert werden)
(!Nur gute Eingaben müssen getestet werden)
(!Fehlerfälle ersetzen die normalen Tests)
{{E}}

{{MC}}
'''Welche Berechtigung braucht ein Agent für einen ersten Änderungsvorschlag?'''
(Möglichst nur Einsicht in die erlaubten synthetischen Projektdateien)
(!Unbegrenzten Zugang zur Produktion)
(!Zugang zu sämtlichen Geheimnissen)
(!Rechte zur Maschinensteuerung)
{{E}}

{{MC}}
'''Was beweisen bestandene Regressionstests?'''
(Die untersuchten Fälle verhalten sich wie erwartet)
(!Es existieren keinerlei anderen Fehler)
(!Ein menschliches Review ist überflüssig)
(!Jede mögliche Eingabe wurde geprüft)
{{E}}

{{MC}}
'''Wie lässt sich ein geteilter Fehlercommit transparent rückgängig machen?'''
(Durch einen überprüften Revert-Commit)
(!Durch heimliches Überschreiben aller fremden Commits)
(!Durch Löschen des gesamten Repositories)
(!Durch Abschalten sämtlicher Tests)
{{E}}

{{MC}}
'''Was bedeutet eine mit Unterstrich benannte Python-Hilfsfunktion?'''
(Sie ist gemäß Namenskonvention für interne Nutzung vorgesehen)
(!Python verbietet jeden Aufruf dieser Funktion)
(!Die Funktion ist automatisch sicherheitszertifiziert)
(!Der Rückgabetyp muss ein String werden)
{{E}}

{{MC}}
'''Was unterstützt Wartbarkeit auf lange Sicht?'''
(Klare Verträge Tests kleine Änderungen und verständliche Dokumentation)
(!Unbeschränkte Änderungen ohne Versionsverlauf)
(!Das Löschen von Fehlerprotokollen)
(!Das alleinige Vertrauen auf KI-Vorschläge)
{{E}}

{{BR}}
== Memory ==
Finde mindestens fünf zusammengehörende Begriffspaare.

<div class="memo-quiz">
{|
|-
| Refactoring || Strukturänderung bei erhaltenem vereinbartem Verhalten
|-
| Regressionstest || Erneute Prüfung bereits zugesagter Ergebnisse
|-
| Schnittstelle || Für Aufrufer sichtbarer Funktionsvertrag
|-
| Review || Unabhängige Prüfung des Änderungsvorschlags
|-
| Commit || Dokumentierter gespeicherter Versionsstand
|-
| Rückwärtskompatibilität || Bisherige Aufrufer funktionieren weiterhin
|}
{{E}}

{{BR}}
== Drag-and-Drop ==
Ordne jedem Begriff die passende Handlung zu.

<div class="lueckentext-quiz">

{| class="wikitable"
! Passenden Begriff zuordnen
! Handlung
|-
| '''Vertrag'''
| Frühere Eingaben Ausgaben und Fehlertypen festhalten
|-
| '''Charakterisierungstest'''
| Bestehendes Verhalten vor der Umstrukturierung messen
|-
| '''Extraktion'''
| Zusammengehörenden Zeilenparser als Hilfsfunktion auslagern
|-
| '''Diffprüfung'''
| Nur tatsächlich beauftragte Zeilenänderungen prüfen
|-
| '''Rücknahme'''
| Nach einem Fehler gezielt einen gesicherten Änderungsstand umkehren
|}
{{E}}

{{BR}}
== Kreuzworträtsel ==
Trage zu jedem Hinweis ein einziges Wort ein.

<div class="kreuzwort-quiz">
{|
|-
| Vertrag || Vereinbarung über Aufruf Ergebnis und Fehler
|-
| Regression || Rückfall in ein früher behobenes Problem
|-
| Lesbarkeit || Verständlichkeit eines Quelltextes
|-
| Schnittstelle || Sichtbarer Zugangspunkt eines Programmmoduls
|-
| Wartbarkeit || Eignung für spätere Pflege und Erweiterung
|-
| Review || Unabhängige Prüfung eines Codes
|}
{{E}}

{{BR}}
== LearningApps ==
[https://learningapps.org/index.php?s=Refactoring+mit+KI+Bestehende+Programme+verbessern Suche nach passenden ergänzenden Übungen]. Die konkreten Treffer werden nicht als geprüft behauptet.
<iframe> https://learningapps.org/index.php?s=Refactoring+mit+KI+Bestehende+Programme+verbessern </iframe>
'''Offline-Alternative:''' Erstelle sechs Kartenpaare zu Refactoring, Vertrag, Test, Branch, Review und Revert.

{{BR}}
== Lückentext ==
<quiz display=simple>
{'''Setze den passenden Fachbegriff ein.'''<br>
|type="{}"}
Ein Refactoring erhält das vereinbarte { Verhalten } eines Programms.
Die nach außen zugängliche Funktion bildet eine { Schnittstelle }.
Ein Test gegen unbeabsichtigte Rückfälle heißt { Regressionstest }.
Der Zeilenparser wird als eigene { Hilfsfunktion } ausgelagert.
Ein Vergleich zweier Quelltextversionen heißt { Diff }.
Ein gesicherter Git-Änderungsstand heißt { Commit }.
Ein zusätzliches fachliches Prüfpaar Augen ist das { Review }.
Zum transparenten Umkehren eines geteilten Commits dient ein { Revert }.
Die langfristige Änderbarkeit nennt man { Wartbarkeit }.
Alte Aufrufer sollen ihre { Kompatibilität } behalten.
</quiz>

{{BR}}
= Offene Aufgaben =
{{BR}}
=== Leicht ===
# [[Refactoring]]: Erkläre den Unterschied zwischen einer inneren Strukturänderung und einer neuen Importfunktion in vier eigenen Sätzen.
# [[Python]]: Führe importiere lokal mit zwei erfundenen Zeilen aus und notiere Eingabe, Rückgabewert und Datentyp.
# [[Regressionstest]]: Ergänze einen Test für drei Leerzeilen und begründe das erwartete Ergebnis.
# [[Programmierschnittstelle]]: Kennzeichne im Beispiel den öffentlichen Namen und die neue private Hilfsfunktion.

{{BR}}
=== Standard ===
# [[Modultest]]: Ergänze zwei Randfalltests und zwei Fehlerfalltests, ohne die ursprünglichen Tests umzuschreiben.
# [[Git]]: Erstelle einen Test-Commit und einen getrennten Refactoring-Commit; erkläre dem Partner die Unterschiede.
# [[Code-Review]]: Tausche den Diff mit einer anderen Person und dokumentiere zwei nachvollziehbare Review-Entscheidungen.
# [[Fehlerbehandlung]]: Begründe an "Motor;3;5", weshalb ein stilles Ignorieren nicht rückwärtskompatibel wäre.

{{BR}}
=== Schwer ===
# [[Rückwärtskompatibilität]]: Plane eine strengere Importprüfung als eigene Funktion oder Version mit eigenem Ticket und neuen Akzeptanztests.
# [[Versionsverwaltung]]: Simuliere in einem Übungsbranch einen Regressionstestfehler und führe eine dokumentierte kontrollierte Rücknahme durch.
# [[Künstliche Intelligenz]]: Erstelle einen begrenzten Agentenauftrag, prüfe einen hypothetischen unerlaubten Dateizugriff und erkläre den Stopp.
# [[Softwarewartung]]: Übertrage die drei Kompatibilitätskriterien auf einen synthetischen JSON-Import samt README, Grenzfällen und Review.

{{:Offene Aufgabe - MOOC erstellen}}

{{BR}}
= Lernkontrolle =
# [[Softwarequalität]]: Begründe am Beispiel die Trennung von besserer Struktur und identischem beobachtbarem Verhalten.
# [[Testabdeckung]]: Ordne vier konkrete Testfälle den Vertragszusagen zu und benenne eine verbleibende Unsicherheit.
# [[Rückwärtskompatibilität]]: Entscheide, ob ein neuer Pflichtparameter vereinbarte Aufrufer bricht, und schlage eine sichere Alternative vor.
# [[Fehlerbehandlung]]: Erkläre die erwartete Reaktion auf drei Spalten und welche Änderung daran fachlich neu genehmigt werden müsste.
# [[Git]]: Beschreibe den Rücknahmeweg nach einem schon geteilten fehlerhaften Commit und begründe deine Entscheidung.
# [[Code-Review]]: Formuliere begründete Annahme- oder Ablehnungsentscheidungen für einen KI-Diff mit zusätzlichen Datenprüfungen.

{{BR}}
= Lernnachweis =
'''Lernprodukt:''' Ein lauffähiges, kompatibel refaktoriertes Python-Importmodul mit unveränderter Funktion importiere(text), einer begründeten Hilfsfunktion, einem reproduzierbaren unittest-Testpaket und einer kurzen Wartungsdokumentation.

'''Abgabe:''' Ausgangsversion und Refactoring-Version; unveränderte vier Basistests plus zwei eigene Fälle; Testprotokoll mit Python-Version und tatsächlichen Ergebnissen; Diff oder klar beschriebene Änderung; separater Git-Commit oder benannte Sicherungskopie; menschliche Review-Notiz; klarer Rücknahmeplan; begründeter Fehlerfall; Trennung eventuell neuer Validierungsregeln vom eigentlichen Refactoring. Ohne Internet, KI oder Git ist eine dokumentierte manuelle Versionierung zulässig.

'''Bewertungsraster:''' 30 Prozent korrekte Kompatibilitätsbelege; 25 Prozent Klarheit der Struktur; 20 Prozent Fehlerszenarien und offene Unsicherheiten; 15 Prozent Review und Rücknahme; 10 Prozent langfristige Dokumentation und Transfer. Weise jedes der drei Kernkriterien an einem wirklichen Beispiel nach und erkläre eigene Entscheidungen.

{{BR}}
= OER und Wikipedia =
'''Recherche- und Medienstand: 22.10.2026.''' Die aufgeführten Versionen und Videodatensätze wurden bei der Recherche geprüft, doch künftige Aktualisierungen und Embedding-Beschränkungen bleiben möglich.
* [https://refactoring.com/ Martin Fowler: Refactoring] – primäre Definition von Refactoring und Katalog; Buchauflage 2018, Webpräsentation fortlaufend.
* [https://docs.python.org/3/library/unittest.html Python: unittest] – offizielles Testmodul; dokumentierte Website-Version bei Recherche Python 3.15.1.
* [https://git-scm.com/docs/git-revert Git: git revert] – offizielle Anleitung zur gezielten Rücknahme eines Commits; Versionsdetails sind lokal zu prüfen.
* [https://modelcontextprotocol.io/docs/2026-07-28/tutorials/security/security_best_practices Model Context Protocol: Security Best Practices] – Security-Dokumentation in der Fassung vom 28.07.2026.
* [https://doi.org/10.6028/NIST.AI.600-1 NIST AI 600-1] – Generative AI Profile, Juli 2024; freiwilliges Risikomanagement und keine App-Zertifizierung.
* [https://de.wikipedia.org/wiki/Refactoring Wikipedia: Refactoring] und [https://de.wikipedia.org/wiki/Regressionstest Wikipedia: Regressionstest] – ergänzende, frei zugängliche Einordnungen.
* [https://moocwiki.org/index.php?curid=60512 Bereits vorhandene Lernbasis] – als Voraussetzung genannt; Seiteninhalt konnte nicht vollständig überprüft werden.

<iframe> https://de.m.wikipedia.org/wiki/Refactoring </iframe>

'''Dateiseiten, Urheberschaft und Nutzungsrechte:'''
{| class="wikitable"
! Dateiname !! Dateiseite !! Autor !! Lizenz
|-
| File:Software Development Lifecycle Diagram.png || [https://commons.wikimedia.org/wiki/File:Software_Development_Lifecycle_Diagram.png Wikimedia Commons] || Shawn Rider || [https://creativecommons.org/licenses/by-sa/4.0/ CC BY-SA 4.0]
|-
| File:Testing Pyramid.svg || [https://commons.wikimedia.org/wiki/File:Testing_Pyramid.svg Wikimedia Commons] || Abbe98 || [https://creativecommons.org/licenses/by-sa/4.0/ CC BY-SA 4.0]
|-
| File:Basic git branching workflow (GitLab).svg || [https://commons.wikimedia.org/wiki/File:Basic_git_branching_workflow_(GitLab).svg Wikimedia Commons] || TheresNoTime || [https://creativecommons.org/licenses/by-sa/4.0/ CC BY-SA 4.0]
|-
| File:Merge bugFix.gif || [https://commons.wikimedia.org/wiki/File:Merge_bugFix.gif Wikimedia Commons] || MonkeyWaffle || [https://creativecommons.org/licenses/by-sa/4.0/ CC BY-SA 4.0]
|-
| File:Testgetriebener Entwicklungsprozess.svg || [https://commons.wikimedia.org/wiki/File:Testgetriebener_Entwicklungsprozess.svg Wikimedia Commons] || MovGP0 || [https://commons.wikimedia.org/wiki/File:Testgetriebener_Entwicklungsprozess.svg Lizenz auf der Dateiseite vor Nachnutzung prüfen]
|-
| File:Computer keyboard.ogg || [https://commons.wikimedia.org/wiki/File:Computer_keyboard.ogg Wikimedia Commons] || russiandoll || [https://commons.wikimedia.org/wiki/File:Computer_keyboard.ogg Gemeinfrei laut Dateiseite]
|}

'''Videos:''' [https://www.youtube.com/watch?v=v1ibwg3zaQQ Mit Mario: Git-Tutorial, 25.11.2022] und [https://www.youtube.com/watch?v=bsU7AFjh4m8 ArjanCodes: Python-Refactoring, November 2025]. Öffentliche Videodatensätze waren auffindbar; aktuelles Abspielen und Einbetten sind plattformabhängig und die Videos wurden nicht als OER-lizenziert verifiziert. Alle Kernaufgaben sind auch ohne externe Medien durch Text und lokale Dateien lösbar.

{{BR}}
= Verknüpfte Lernbereiche =
{| align=center
{{:D-Tab}}
'''[[Refactoring]]'''
# [[Lesbarkeit]]
# [[Wartbarkeit]]
# [[Rückwärtskompatibilität]]
# [[Code-Review]]
'''[[Softwaretest]]'''
# [[Regressionstest]]
# [[Modultest]]
# [[Testautomatisierung]]
# [[Fehlerbehandlung]]
'''[[Versionsverwaltung]]'''
# [[Git]]
# [[Commit]]
# [[Branch (Versionsverwaltung)|Branch]]
# [[Änderungsmanagement]]
'''[[KI-Agent]]'''
# [[Künstliche Intelligenz]]
# [[Informationssicherheit]]
# [[Softwarequalität]]
# [[Softwareentwicklung]]
|}
[[Category:Sprache:Deutsch]]
[[Category:Locale:de-DE]]
[[Category:Programmierung]]
[[Category:Berufsausbildung]]
[[Category:Softwareentwicklung]]
[[Category:Informatik]]
[[Category:Python]]

{{BR}}
= aiMOOC-Projekte =
[[Category:AI_MOOC]] [[Category:GPT aiMOOC]]
{{MT}}

Refactoring mit KI - Bestehende Programme verbessern - Versionsgeschichte

Glanz: AI MOOC Plugin f57d4cf6ddfed972564e676627867444