Hinweis zur Privatsphäre: Wenn Sie sich mit Ihrem GitHub-Konto anmelden, werden Ihre Quiz-Versuche in Google Firebase gespeichert, damit Sie Ihren Fortschritt verfolgen können. Diese Daten sind nur für den Kursleiter einsehbar, werden nicht anderweitig weitergegeben und nach Semesterende gelöscht. Frühere Löschung auf Anfrage beim Kursleiter. Möchten Sie anonym bleiben? Nutzen Sie den Gastmodus oder ein GitHub-Konto ohne Ihren echten Namen.
Lädt...
Melden Sie sich an, um Ihren Fortschritt zu speichern und auf allen Geräten zu sehen.
●Fortschritt wird gespeichert
03 Vorlesung 3 Quiz: Von Greenfield zu Brownfield
Punkte:0 / 15
Fragen-Übersicht
OffenRichtigFalsch
Anleitung
Dies ist ein interaktives Quiz. Melden Sie sich mit GitHub an, um Ihren Fortschritt zu speichern, oder fahren Sie als Gast fort.
Wählen Sie Ihre Antwort für jede Frage
Erhalten Sie sofortiges Feedback zu Ihrer Auswahl
Wiederholen Sie Fragen so oft Sie möchten
Verfolgen Sie Ihren Fortschritt über Sitzungen hinweg
Frage1
Definitionen
Was ist der wesentliche Unterschied zwischen Greenfield- und Brownfield-Softwareentwicklung?
✓Richtig!
Greenfield-Entwicklung beginnt mit einem leeren Verzeichnis, in dem Sie jede Entscheidung treffen — Dateinamen, Architektur, Konventionen. Brownfield-Entwicklung bedeutet Arbeiten in einer bestehenden Codebasis mit vorhandenen Einschränkungen, Konventionen und Nutzer:innen, die auf das aktuelle Verhalten angewiesen sind. Es geht nicht um das Alter der Technologie oder die Teamgröße — es geht darum, ob Sie mit einer leeren Leinwand oder einer bestehenden beginnen.
✗Nicht ganz.
Hinweis
Überlegen Sie, ob die Leinwand leer ist oder bereits etwas darauf hat.
💡Lösung
Greenfield-Entwicklung beginnt mit einem leeren Verzeichnis, in dem Sie jede Entscheidung treffen — Dateinamen, Architektur, Konventionen. Brownfield-Entwicklung bedeutet Arbeiten in einer bestehenden Codebasis mit vorhandenen Einschränkungen, Konventionen und Nutzer:innen, die auf das aktuelle Verhalten angewiesen sind. Es geht nicht um das Alter der Technologie oder die Teamgröße — es geht darum, ob Sie mit einer leeren Leinwand oder einer bestehenden beginnen.
Frage2
Branchenrealität
Wie verbringen professionelle Entwickler:innen laut der in der Vorlesung zitierten Forschung den Großteil ihrer Zeit?
✓Richtig!
Forschung von Minelli, Mocci und Lanza (2015) ergab, dass etwa 70% der Entwicklungszeit auf das Programmverstehen entfallen — Code lesen, Aufrufhierarchien navigieren und mentale Modelle davon aufbauen, wie bestehende Komponenten zusammenwirken. Die primäre Entwicklertätigkeit ist nicht das Schreiben — es ist das Lesen.
✗Nicht ganz.
Hinweis
Die Forschung verfolgte über 200 Stunden IDE-Nutzung über 740 Sitzungen.
💡Lösung
Forschung von Minelli, Mocci und Lanza (2015) ergab, dass etwa 70% der Entwicklungszeit auf das Programmverstehen entfallen — Code lesen, Aufrufhierarchien navigieren und mentale Modelle davon aufbauen, wie bestehende Komponenten zusammenwirken. Die primäre Entwicklertätigkeit ist nicht das Schreiben — es ist das Lesen.
Frage3
Testen
Wie verändert sich die Rolle von Tests beim Übergang von Greenfield zu Brownfield-Entwicklung?
✓Richtig!
Im Greenfield sind Tests Teil eines Workflows, den Sie befolgen. Im Brownfield ist die bestehende Testsuite ein Vertrag: Sie kodiert das erwartete Verhalten des Systems. “Alle Tests bestehen” ist die Mindestanforderung für jede Änderung, und pytest ist Ihr erster und letzter Befehl. Produktionsvalidierung ersetzt keine Tests — dass Nutzer:innen Fehler finden, ist nicht dasselbe wie eine Testsuite, die Regressionen verhindert.
✗Nicht ganz.
Hinweis
Was bedeutet es tatsächlich, einen Test in einer bestehenden Codebasis zu brechen?
💡Lösung
Im Greenfield sind Tests Teil eines Workflows, den Sie befolgen. Im Brownfield ist die bestehende Testsuite ein Vertrag: Sie kodiert das erwartete Verhalten des Systems. “Alle Tests bestehen” ist die Mindestanforderung für jede Änderung, und pytest ist Ihr erster und letzter Befehl. Produktionsvalidierung ersetzt keine Tests — dass Nutzer:innen Fehler finden, ist nicht dasselbe wie eine Testsuite, die Regressionen verhindert.
Frage4
KI im Brownfield
Was ist das “Kontextproblem” bei der Verwendung von KI-Werkzeugen in einer bestehenden Codebasis?
✓Richtig!
Wenn Sie eine Codebasis mit 10.000 Zeilen öffnen, hat die KI diese nie gesehen. Sie kennt weder die Verzeichnisstruktur noch die Namenskonventionen, Testmuster oder die Architektur. Ohne Kontext gibt die KI vage, generische Antworten und generiert Code, der nicht zum Stil des Projekts passt. Das Problem ist nicht zu viel Kontext oder die Fenstergröße — sondern dass die KI mit null Projektwissen startet.
✗Nicht ganz.
Hinweis
Was sieht die KI, wenn Sie ein Projekt zum ersten Mal öffnen?
💡Lösung
Wenn Sie eine Codebasis mit 10.000 Zeilen öffnen, hat die KI diese nie gesehen. Sie kennt weder die Verzeichnisstruktur noch die Namenskonventionen, Testmuster oder die Architektur. Ohne Kontext gibt die KI vage, generische Antworten und generiert Code, der nicht zum Stil des Projekts passt. Das Problem ist nicht zu viel Kontext oder die Fenstergröße — sondern dass die KI mit null Projektwissen startet.
Frage5
Projektanweisungsdateien
Was ist der primäre Zweck einer CLAUDE.md-Datei in einem Brownfield-Projekt?
✓Richtig!
Eine CLAUDE.md gibt der KI eine strukturierte Karte des Projekts: Architektur, wichtige Dateien, Testmuster, Git-Workflows, Coding-Konventionen und häufige Fallstricke. Dieselbe Frage, mit und ohne diese Datei gestellt, produziert dramatisch unterschiedliche Antwortqualität — von vagen Allgemeinplätzen bis hin zu spezifischen, genauen Referenzen. Sie ergänzt bestehende Dokumentation, anstatt sie zu ersetzen.
✗Nicht ganz.
Hinweis
Denken Sie an den Vorher-Nachher-Vergleich in der Vorlesung.
💡Lösung
Eine CLAUDE.md gibt der KI eine strukturierte Karte des Projekts: Architektur, wichtige Dateien, Testmuster, Git-Workflows, Coding-Konventionen und häufige Fallstricke. Dieselbe Frage, mit und ohne diese Datei gestellt, produziert dramatisch unterschiedliche Antwortqualität — von vagen Allgemeinplätzen bis hin zu spezifischen, genauen Referenzen. Sie ergänzt bestehende Dokumentation, anstatt sie zu ersetzen.
Frage6
Projektanweisungsdateien
Während der Kursvorbereitung erhielt die KI eine umfassende CLAUDE.md, produzierte aber dennoch Code mit PEP-8-Verstößen. Welche Lektion lehrt uns das?
✓Richtig!
CLAUDE.md ist Einfluss, nicht Durchsetzung. Wenn sich die KI auf komplexe Code-Generierung konzentriert, können Stilregeln verdrängt werden. Deshalb sind CLAUDE.md und automatisierte Werkzeuge (Pre-Commit Hooks, Linter, CI) komplementäre Schichten: Die CLAUDE.md leitet das Verhalten der KI, und die Automatisierung fängt auf, was durchrutscht. Die Datei ist nicht wirkungslos — sie verbessert die Ausgabe erheblich — aber sie kann keine Perfektion garantieren.
✗Nicht ganz.
Hinweis
Was passiert, wenn sich die KI auf eine komplexe Coding-Aufgabe konzentriert?
💡Lösung
CLAUDE.md ist Einfluss, nicht Durchsetzung. Wenn sich die KI auf komplexe Code-Generierung konzentriert, können Stilregeln verdrängt werden. Deshalb sind CLAUDE.md und automatisierte Werkzeuge (Pre-Commit Hooks, Linter, CI) komplementäre Schichten: Die CLAUDE.md leitet das Verhalten der KI, und die Automatisierung fängt auf, was durchrutscht. Die Datei ist nicht wirkungslos — sie verbessert die Ausgabe erheblich — aber sie kann keine Perfektion garantieren.
Frage7
Qualitätsstandards
Welches der folgenden Kriterien gehört zur erweiterten “Definition of Done” für Brownfield-Entwicklung, ist aber typischerweise NICHT in Greenfield-Übungen erforderlich?
✓Richtig!
Die Brownfield Definition of Done umfasst: Alle bestehenden Tests bestehen (keine Regressionen), neuer Code hat Tests, Coverage wird aufrechterhalten, Code besteht den Linter, PR ist reviewed, Dokumentation ist aktualisiert wenn sich das Verhalten geändert hat, und Konventionen werden befolgt. In Greenfield-Übungen wie der SO Challenge bedeutete “fertig” einfach “der Plot sieht richtig aus.” Der entscheidende Unterschied ist die Betonung auf dem Bewahren bestehenden Verhaltens und dem Erfüllen von Teamstandards.
✗Nicht ganz.
Hinweis
Vergleichen Sie die Tabelle in der Vorlesung, die Greenfield- und Brownfield-Kriterien gegenüberstellt.
💡Lösung
Die Brownfield Definition of Done umfasst: Alle bestehenden Tests bestehen (keine Regressionen), neuer Code hat Tests, Coverage wird aufrechterhalten, Code besteht den Linter, PR ist reviewed, Dokumentation ist aktualisiert wenn sich das Verhalten geändert hat, und Konventionen werden befolgt. In Greenfield-Übungen wie der SO Challenge bedeutete “fertig” einfach “der Plot sieht richtig aus.” Der entscheidende Unterschied ist die Betonung auf dem Bewahren bestehenden Verhaltens und dem Erfüllen von Teamstandards.
Frage8
KI im Brownfield
Worin glänzt KI in der Brownfield-Entwicklung?
✓Richtig!
KI glänzt bei Code-Erklärung, Test-Generierung, Refactoring-Vorschlägen und Dokumentationsentwürfen in Brownfield-Umgebungen. Allerdings tut sie sich schwer mit Architekturentscheidungen (dem “Warum”), ungeschriebenen Konventionen, Seiteneffekten und Zustand, Legacy-Mustern und Scope-Kontrolle. Die zentrale Erkenntnis ist, dass KI am stärksten bei Aufgaben ist, die Mustererkennung in sichtbarem Code umfassen, nicht beim Verstehen unsichtbaren Kontexts.
✗Nicht ganz.
Hinweis
Überlegen Sie, was KI schnell erledigen kann, wofür ein Mensch viel länger brauchen würde.
💡Lösung
KI glänzt bei Code-Erklärung, Test-Generierung, Refactoring-Vorschlägen und Dokumentationsentwürfen in Brownfield-Umgebungen. Allerdings tut sie sich schwer mit Architekturentscheidungen (dem “Warum”), ungeschriebenen Konventionen, Seiteneffekten und Zustand, Legacy-Mustern und Scope-Kontrolle. Die zentrale Erkenntnis ist, dass KI am stärksten bei Aufgaben ist, die Mustererkennung in sichtbarem Code umfassen, nicht beim Verstehen unsichtbaren Kontexts.
Frage9
KI im Brownfield
Warum tut sich KI mit “Legacy-Mustern” in bestehenden Codebasen schwer?
✓Richtig!
Legacy-Muster existieren, weil deren Entfernung reale Nutzer:innen betreffen würde. Die KI versteht den historischen Kontext nicht — warum ein Workaround hinzugefügt wurde, welche nachgelagerten Systeme vom aktuellen Verhalten abhängen. Sie kann lokal sinnvolle Änderungen vorschlagen, die umfassendere Einschränkungen verletzen. Während Wissens-Stichtage und fehlende Git-Historie reale Einschränkungen sind, ist das Kernproblem, dass KI nicht zwischen beabsichtigten Legacy-Mustern und tatsächlich verbesserungsfähigem Code unterscheiden kann.
✗Nicht ganz.
Hinweis
Warum könnte Code, der ‘schlecht’ aussieht, tatsächlich absichtlich dort stehen?
💡Lösung
Legacy-Muster existieren, weil deren Entfernung reale Nutzer:innen betreffen würde. Die KI versteht den historischen Kontext nicht — warum ein Workaround hinzugefügt wurde, welche nachgelagerten Systeme vom aktuellen Verhalten abhängen. Sie kann lokal sinnvolle Änderungen vorschlagen, die umfassendere Einschränkungen verletzen. Während Wissens-Stichtage und fehlende Git-Historie reale Einschränkungen sind, ist das Kernproblem, dass KI nicht zwischen beabsichtigten Legacy-Mustern und tatsächlich verbesserungsfähigem Code unterscheiden kann.
Frage10
Automatisierte Durchsetzung
Welche Rolle spielen Pre-Commit Hooks in der KI-gestützten Brownfield-Entwicklung?
✓Richtig!
Pre-Commit Hooks laufen automatisch bei jedem git commit und fangen Verstöße (wie PEP-8-Probleme von ruff) ab, bevor sie ins Repository gelangen. Sie dienen als Durchsetzungsschicht, die die Einflussschicht der CLAUDE.md ergänzt — denn selbst mit umfassenden Projektanweisungen kann KI-generierter Code immer noch Stilverstoße enthalten. Sie geben der KI kein Feedback während der Generierung, und sie ersetzen auch nicht das Code Review.
✗Nicht ganz.
Hinweis
Was läuft automatisch jedes Mal, wenn Sie ‘git commit’ eingeben?
💡Lösung
Pre-Commit Hooks laufen automatisch bei jedem git commit und fangen Verstöße (wie PEP-8-Probleme von ruff) ab, bevor sie ins Repository gelangen. Sie dienen als Durchsetzungsschicht, die die Einflussschicht der CLAUDE.md ergänzt — denn selbst mit umfassenden Projektanweisungen kann KI-generierter Code immer noch Stilverstoße enthalten. Sie geben der KI kein Feedback während der Generierung, und sie ersetzen auch nicht das Code Review.
Frage11
Werkzeugkonfiguration
Welche Datei erfüllt denselben Zweck wie CLAUDE.md, aber für GitHub Copilot?
✓Richtig!
Verschiedene KI-Werkzeuge verwenden unterschiedliche Dateinamen für dasselbe Konzept: Claude Code verwendet CLAUDE.md, GitHub Copilot verwendet .github/copilot-instructions.md, und Cursor verwendet .cursorrules. Die Dateinamen unterscheiden sich, aber Inhalt und Zweck sind identisch: Projektkontext kodieren, den das Werkzeug automatisch liest.
✗Nicht ganz.
Hinweis
Die Datei liegt im .github/-Verzeichnis.
💡Lösung
Verschiedene KI-Werkzeuge verwenden unterschiedliche Dateinamen für dasselbe Konzept: Claude Code verwendet CLAUDE.md, GitHub Copilot verwendet .github/copilot-instructions.md, und Cursor verwendet .cursorrules. Die Dateinamen unterscheiden sich, aber Inhalt und Zweck sind identisch: Projektkontext kodieren, den das Werkzeug automatisch liest.
Frage12
KI-Tagebuch
Wie verändert sich die Struktur des KI-Tagebuchs beim Übergang von einem Soloprojekt zu einer gemeinsamen Codebasis?
✓Richtig!
In einer gemeinsamen Codebasis würde die flache diary/001-xxx.md-Sequenz Merge-Konflikte erzeugen. Stattdessen verwendet das Tagebuch eine Branch-basierte Struktur: diary/feature/<branch-name>/001-xxx.md. Jeder Eintrag wird zusammen mit dem Code committet, den er dokumentiert, und Commit-Nachrichten verwenden das [diary]-Präfix. PR-Beschreibungen ergänzen das Tagebuch, ersetzen es aber nicht.
✗Nicht ganz.
Hinweis
Was würde passieren, wenn mehrere Entwickler:innen dasselbe flache Nummerierungsschema verwenden?
💡Lösung
In einer gemeinsamen Codebasis würde die flache diary/001-xxx.md-Sequenz Merge-Konflikte erzeugen. Stattdessen verwendet das Tagebuch eine Branch-basierte Struktur: diary/feature/<branch-name>/001-xxx.md. Jeder Eintrag wird zusammen mit dem Code committet, den er dokumentiert, und Commit-Nachrichten verwenden das [diary]-Präfix. PR-Beschreibungen ergänzen das Tagebuch, ersetzen es aber nicht.
Frage13
Refactoring
Was ist der primäre Sicherheitsmechanismus beim Refactoring von Code in einem Brownfield-Projekt?
✓Richtig!
Die bestehende Testsuite fungiert als Vertrag für erwartetes Verhalten. Beim Refactoring müssen alle bestehenden Tests ohne Änderung bestehen. Wenn ein Test fehlschlägt, hat das Refactoring das Verhalten geändert — Sie korrigieren das Refactoring, nicht den Test. Code Reviews helfen, aber sie können nicht alle Verhaltensänderungen so erkennen wie eine automatisierte Testsuite.
✗Nicht ganz.
Hinweis
Was tun Sie, wenn ein Test nach dem Refactoring fehlschlägt?
💡Lösung
Die bestehende Testsuite fungiert als Vertrag für erwartetes Verhalten. Beim Refactoring müssen alle bestehenden Tests ohne Änderung bestehen. Wenn ein Test fehlschlägt, hat das Refactoring das Verhalten geändert — Sie korrigieren das Refactoring, nicht den Test. Code Reviews helfen, aber sie können nicht alle Verhaltensänderungen so erkennen wie eine automatisierte Testsuite.
Frage14
Konventionen
Warum ist es wichtig, dass KI-generierter Code den bestehenden Konventionen des Projekts folgt statt generischen Best Practices?
✓Richtig!
In einem Brownfield-Projekt sind Konventionen bereits vorhanden: Benennungsmuster, Import-Reihenfolge, Docstring-Format, Teststil. Ohne expliziten Kontext (wie eine CLAUDE.md) folgt KI generischen Konventionen (PEP 8), die möglicherweise nicht zum tatsächlichen Stil des Projekts passen. Inkonsistenz macht die Codebasis schwerer lesbar und wartbar für alle Beitragenden. Dies gilt für alle Projekte, nicht nur für Open-Source-Projekte.
✗Nicht ganz.
Hinweis
Denken Sie an das Locust-Projekt, das unittest.TestCase statt pytest-Fixtures verwendet.
💡Lösung
In einem Brownfield-Projekt sind Konventionen bereits vorhanden: Benennungsmuster, Import-Reihenfolge, Docstring-Format, Teststil. Ohne expliziten Kontext (wie eine CLAUDE.md) folgt KI generischen Konventionen (PEP 8), die möglicherweise nicht zum tatsächlichen Stil des Projekts passen. Inkonsistenz macht die Codebasis schwerer lesbar und wartbar für alle Beitragenden. Dies gilt für alle Projekte, nicht nur für Open-Source-Projekte.
Frage15
Erfolg messen
Warum ist die Frage “Hat meine Änderung es langsamer gemacht?” besonders wichtig in der Locust-Codebasis?
✓Richtig!
Der gesamte Zweck von Locust ist das Messen und Erzeugen von Last. Wenn eine Änderung 5 ms Verarbeitungszeit pro Anfrage bei 10.000 Anfragen/Sekunde hinzufügt, sind das 50 Sekunden Overhead pro Sekunde. Performance ist keine nicht-funktionale Anforderung — sie IST das Produkt. Das macht Benchmarking zu einem natürlichen Bestandteil jeder Übung. Während CI-Benchmarks in manchen Projekten existieren, ist der grundlegende Grund hier der Kernzweck von Locust.
✗Nicht ganz.
Hinweis
Wofür wird Locust verwendet?
💡Lösung
Der gesamte Zweck von Locust ist das Messen und Erzeugen von Last. Wenn eine Änderung 5 ms Verarbeitungszeit pro Anfrage bei 10.000 Anfragen/Sekunde hinzufügt, sind das 50 Sekunden Overhead pro Sekunde. Performance ist keine nicht-funktionale Anforderung — sie IST das Produkt. Das macht Benchmarking zu einem natürlichen Bestandteil jeder Übung. Während CI-Benchmarks in manchen Projekten existieren, ist der grundlegende Grund hier der Kernzweck von Locust.