Home

03 Vorlesung 3 Quiz: Von Greenfield zu Brownfield

March 2026 (2240 Words, 13 Minutes)

quiz brownfield open-source claude-md testing refactoring

Neu: Interaktives Quiz verfuegbar!

Moechten Sie Ihren Fortschritt verfolgen und sofortiges Feedback erhalten? Probieren Sie unsere neue interaktive Version mit Fortschrittsverfolgung, sofortigen Erklaerungen und Punkteberechnung.

Interaktives Quiz starten →

Anleitung

Frage 1: Greenfield vs. Brownfield

Was ist der wesentliche Unterschied zwischen Greenfield- und Brownfield-Softwareentwicklung?

A) Greenfield bedeutet Arbeiten mit modernen Technologien; Brownfield bedeutet Wartung veralteter Legacy-Systeme B) Greenfield konzentriert sich auf Architekturdesign; Brownfield konzentriert sich hauptsaechlich auf Fehlerbehebung C) Greenfield bedeutet Bauen von Grund auf auf einer leeren Leinwand; Brownfield bedeutet Arbeiten in einer bestehenden Codebasis mit bestehenden Einschraenkungen D) Greenfield wird einzeln durchgefuehrt; Brownfield erfordert immer ein Team

Antwort anzeigen

Richtige Antwort: C

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 Einschraenkungen, Konventionen und Nutzer:innen, die auf das aktuelle Verhalten angewiesen sind. Es geht nicht um das Alter der Technologie oder die Teamgroesse — es geht darum, ob Sie mit einer leeren Leinwand oder einer bestehenden beginnen.

Frage 2: Zeitverteilung von Entwickler:innen

Wie verbringen professionelle Entwickler:innen laut der in der Vorlesung zitierten Forschung den Grossteil ihrer Zeit?

A) Schreiben von neuem Code von Grund auf B) Teilnahme an Meetings und Verfassen von Dokumentation C) Debugging von Produktionsproblemen D) Lesen und Verstehen von bestehendem Code (Programmverstehen)

Antwort anzeigen

Richtige Antwort: D

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 primaere Entwicklertaetigkeit ist nicht das Schreiben — es ist das Lesen.

Frage 3: Tests im Brownfield

Wie veraendert sich die Rolle von Tests beim Uebergang von Greenfield zu Brownfield-Entwicklung?

A) Tests werden weniger wichtig, weil der Code bereits durch Nutzer:innen in der Produktion validiert wurde B) Tests wandeln sich von aspirativ zu existenziell — sie kodieren den Vertrag des erwarteten Verhaltens C) Tests sollten fuer jedes neue Feature geloescht und neu geschrieben werden D) Tests muessen nur neuen Code abdecken, nicht die bestehende Funktionalitaet, die bereits funktioniert

Antwort anzeigen

Richtige Antwort: B

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 fuer jede Aenderung, 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.

Frage 4: Das Kontextproblem

Was ist das “Kontextproblem” bei der Verwendung von KI-Werkzeugen in einer bestehenden Codebasis?

A) Die KI weiss nichts ueber das Projekt — seine Architektur, Konventionen oder den spezifischen Code — es sei denn, Sie stellen diese Informationen bereit B) Die KI hat zu viel Kontext und wird ueberfordert, was zu verwirrten und widersprüchlichen Ausgaben fuehrt C) Das Kontextfenster ist immer zu klein, um eine bedeutsame Menge an Code aus bestehenden Projekten aufzunehmen D) Die KI kann ohne spezielle Konfiguration und Plugins keine Dateien in bestehenden Projekten lesen

Antwort anzeigen

Richtige Antwort: A

Wenn Sie eine Codebasis mit 10.000 Zeilen oeffnen, 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 Fenstergroesse — sondern dass die KI mit null Projektwissen startet.

Frage 5: Zweck der CLAUDE.md

Was ist der primaere Zweck einer CLAUDE.md-Datei in einem Brownfield-Projekt?

A) Alle bestehende Projektdokumentation — README, Wiki und Inline-Kommentare — durch eine einzige KI-optimierte Referenzdatei zu ersetzen B) Komprimierte Snapshots des Quellcodes des Projekts fuer schnellere KI-Verarbeitung zu speichern C) Die Parameter des KI-Modells wie Temperatur, Token-Limits und Antwortformat zu konfigurieren D) Der KI strukturierten Kontext ueber die Architektur, Konventionen und Workflows des Projekts zu geben

Antwort anzeigen

Richtige Antwort: D

Eine CLAUDE.md gibt der KI eine strukturierte Karte des Projekts: Architektur, wichtige Dateien, Testmuster, Git-Workflows, Coding-Konventionen und haeufige Fallstricke. Dieselbe Frage, mit und ohne diese Datei gestellt, produziert dramatisch unterschiedliche Antwortqualitaet — von vagen Allgemeinplaetzen bis hin zu spezifischen, genauen Referenzen. Sie ergaenzt bestehende Dokumentation, anstatt sie zu ersetzen.

Frage 6: Grenzen der CLAUDE.md

Waehrend der Kursvorbereitung erhielt die KI eine umfassende CLAUDE.md, produzierte aber dennoch Code mit PEP-8-Verstoessen. Welche Lektion lehrt uns das?

A) CLAUDE.md-Dateien sind wirkungslos, weil KI-Modelle benutzerdefinierte Anweisungen bei der Generierung komplexen Codes ignorieren B) Die CLAUDE.md war zu kurz und benoetigte mehr Regeln ueber Python-spezifische Stilkonventionen, um wirksam zu sein C) CLAUDE.md bietet Einfluss, nicht Durchsetzung — automatisierte Werkzeuge wie Linter und Pre-Commit Hooks werden als ergaenzende Schicht benoetigt D) PEP-8-Verstoesse sind in KI-generiertem Code akzeptabel, da die KI funktionale Korrektheit ueber Stileinhaltung priorisiert

Antwort anzeigen

Richtige Antwort: C

CLAUDE.md ist Einfluss, nicht Durchsetzung. Wenn sich die KI auf komplexe Code-Generierung konzentriert, koennen Stilregeln verdraengt werden. Deshalb sind CLAUDE.md und automatisierte Werkzeuge (Pre-Commit Hooks, Linter, CI) komplementaere Schichten: Die CLAUDE.md leitet das Verhalten der KI, und die Automatisierung faengt auf, was durchrutscht. Die Datei ist nicht wirkungslos — sie verbessert die Ausgabe erheblich — aber sie kann keine Perfektion garantieren.

Frage 7: Definition of Done

Welches der folgenden Kriterien gehoert zur erweiterten “Definition of Done” fuer Brownfield-Entwicklung, ist aber typischerweise NICHT in Greenfield-Uebungen erforderlich?

A) Der Code muss kompilieren und grundlegende Unit-Tests bestehen, die von den Entwickler:innen geschrieben wurden B) Alle bestehenden Tests bestehen, Code per PR reviewed, Konventionen befolgt, Coverage aufrechterhalten C) Der Code muss automatisierte Formatierungspruefungen bestehen und Inline-Dokumentation fuer jede Funktion haben D) Die Entwickler:innen muessen die Projekt-Roadmap aktualisieren und alle Stakeholder ueber die Aenderung informieren

Antwort anzeigen

Richtige Antwort: B

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 geaendert hat, und Konventionen werden befolgt. In Greenfield-Uebungen 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 Erfuellen von Teamstandards.

Frage 8: KI-Staerken im Brownfield

Worin glaenzt KI in der Brownfield-Entwicklung?

A) Erklaeren von bestehendem Code, Generieren von Tests fuer bestehende Module und Vorschlagen von Refactoring-Mustern B) Treffen von Architekturentscheidungen darueber, warum die Codebasis auf eine bestimmte Weise strukturiert ist C) Verstehen ungeschriebener Konventionen und impliziten Teamwissens, das nirgendwo dokumentiert ist D) Automatisches Erkennen und Beheben aller Seiteneffekte in nebenlaeufigem und zustandsbehaftetem Code

Antwort anzeigen

Richtige Antwort: A

KI glaenzt bei Code-Erklaerung, Test-Generierung, Refactoring-Vorschlaegen und Dokumentationsentwuerfen 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 staerksten bei Aufgaben ist, die Mustererkennung in sichtbarem Code umfassen, nicht beim Verstehen unsichtbaren Kontexts.

Frage 9: KI-Schwaechen im Brownfield

Warum tut sich KI mit “Legacy-Mustern” in bestehenden Codebasen schwer?

A) KI-Modelle haben einen Wissens-Stichtag, der sie daran hindert, aeltere APIs und veraltete Bibliotheksversionen zu verstehen B) Mancher Code existiert aus historischen Gruenden (Rueckwaertskompatibilitaet, alte Bug-Workarounds), und KI kann “Verbesserungen” vorschlagen, die Dinge kaputt machen C) KI hat keinen Zugang zur Versionskontrollhistorie, die noetig ist, um zu verstehen, wie sich der Code entwickelt hat D) KI neigt dazu, Legacy-Code mit den neuesten Framework-Versionen umzuschreiben, was Kompatibilitaetsprobleme mit bestehender Infrastruktur verursacht

Antwort anzeigen

Richtige Antwort: B

Legacy-Muster existieren, weil deren Entfernung reale Nutzer:innen betreffen wuerde. Die KI versteht den historischen Kontext nicht — warum ein Workaround hinzugefuegt wurde, welche nachgelagerten Systeme vom aktuellen Verhalten abhaengen. Sie kann lokal sinnvolle Aenderungen vorschlagen, die umfassendere Einschraenkungen verletzen. Waehrend Wissens-Stichtage und fehlende Git-Historie reale Einschraenkungen sind, ist das Kernproblem, dass KI nicht zwischen beabsichtigten Legacy-Mustern und tatsaechlich verbesserungsfaehigem Code unterscheiden kann.

Frage 10: Pre-Commit Hooks

Welche Rolle spielen Pre-Commit Hooks in der KI-gestuetzten Brownfield-Entwicklung?

A) Sie geben der KI waehrend der Code-Generierung Echtzeit-Feedback, wodurch ihre Ausgabe konsistenter mit den Projektkonventionen wird B) Sie stellen sicher, dass kein Code ohne vorherige KI-gestuetzte Pruefung und Freigabe ins Repository committet werden kann C) Sie ersetzen die Notwendigkeit manueller Code Reviews, indem sie umfassende automatisierte Qualitaetspruefungen bei jeder Aenderung durchfuehren D) Sie fangen automatisch Stilverstoesse und Linting-Fehler ab, bevor Code ins Repository gelangt

Antwort anzeigen

Richtige Antwort: D

Pre-Commit Hooks laufen automatisch bei jedem git commit und fangen Verstoesse (wie PEP-8-Probleme von ruff) ab, bevor sie ins Repository gelangen. Sie dienen als Durchsetzungsschicht, die die Einflussschicht der CLAUDE.md ergaenzt — denn selbst mit umfassenden Projektanweisungen kann KI-generierter Code immer noch Stilverstoesse enthalten. Sie geben der KI kein Feedback waehrend der Generierung, und sie ersetzen auch nicht das Code Review.

Frage 11: Aequivalente zu Projektanweisungsdateien

Welche Datei erfuellt denselben Zweck wie CLAUDE.md, aber fuer GitHub Copilot?

A) .github/copilot-instructions.md B) .copilotrc C) copilot.config.json D) .github/workflows/copilot.yml

Antwort anzeigen

Richtige Antwort: A

Verschiedene KI-Werkzeuge verwenden unterschiedliche Dateinamen fuer 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.

Frage 12: KI-Tagebuch in gemeinsamen Codebasen

Wie veraendert sich die Struktur des KI-Tagebuchs beim Uebergang von einem Soloprojekt zu einer gemeinsamen Codebasis?

A) Das Tagebuch wird nicht mehr benoetigt, weil gemeinsame Projekte stattdessen PR-Beschreibungen verwenden B) Jedes Teammitglied fuehrt ein separates privates Tagebuch ausserhalb des Repositorys, um Merge-Konflikte zu vermeiden C) Es wechselt von einer flachen nummerierten Sequenz zu einer Branch-basierten Struktur mit Unterordnern pro Feature Branch D) Das Tagebuchformat bleibt gleich, aber Eintraege werden automatisch von der CI/CD-Pipeline zusammengefuehrt

Antwort anzeigen

Richtige Antwort: C

In einer gemeinsamen Codebasis wuerde 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]-Praefix. PR-Beschreibungen ergaenzen das Tagebuch, ersetzen es aber nicht.

Frage 13: Sicherheit beim Refactoring

Was ist der primaere Sicherheitsmechanismus beim Refactoring von Code in einem Brownfield-Projekt?

A) Die bestehende Testsuite verifiziert, dass refaktorisierter Code das urspruengliche Verhalten bewahrt B) Die KI garantiert, dass refaktorisierter Code funktional aequivalent zur urspruenglichen Implementierung ist C) Einmaliges manuelles Ausfuehren der Anwendung nach dem Refactoring reicht aus, um die Korrektheit zu verifizieren D) Code Reviews durch erfahrene Entwickler:innen sind der primaere Mechanismus zum Erkennen von Refactoring-Fehlern

Antwort anzeigen

Richtige Antwort: A

Die bestehende Testsuite fungiert als Vertrag fuer erwartetes Verhalten. Beim Refactoring muessen alle bestehenden Tests ohne Aenderung bestehen. Wenn ein Test fehlschlaegt, hat das Refactoring das Verhalten geaendert — Sie korrigieren das Refactoring, nicht den Test. Code Reviews helfen, aber sie koennen nicht alle Verhaltensaenderungen so erkennen wie eine automatisierte Testsuite.

Frage 14: Coding-Konventionen

Warum ist es wichtig, dass KI-generierter Code den bestehenden Konventionen des Projekts folgt statt generischen Best Practices?

A) Generische Best Practices wie PEP 8 stehen oft in Konflikt miteinander, daher werden projektspezifische Regeln benoetigt, um Mehrdeutigkeiten aufzuloesen B) KI-Modelle koennen ohne explizite Konventionsdateien ueberhaupt keinen Code generieren, was zu Kompilierungsfehlern fuehrt C) Das Befolgen von Konventionen ist hauptsaechlich fuer Open-Source-Projekte wichtig, bei denen externe Beitragende Konsistenzrichtlinien benoetigen D) Ohne Uebereinstimmung mit bestehenden Konventionen erzeugt KI-generierter Code Inkonsistenzen, die die Codebasis schwerer lesbar und wartbar machen

Antwort anzeigen

Richtige Antwort: D

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 moeglicherweise nicht zum tatsaechlichen Stil des Projekts passen. Inkonsistenz macht die Codebasis schwerer lesbar und wartbar fuer alle Beitragenden. Dies gilt fuer alle Projekte, nicht nur fuer Open-Source-Projekte.

Frage 15: Performance im Brownfield

Warum ist die Frage “Hat meine Aenderung es langsamer gemacht?” besonders wichtig in der Locust-Codebasis?

A) Locust ist ein ausgereiftes Projekt mit angesammelter technischer Schuld, das eine sorgfaeltige Performance-Ueberwachung jeder Aenderung erfordert B) Python ist eine interpretierte Sprache, daher hat jede Codeaenderung einen ueberproportionalen Einfluss auf die Ausfuehrungsgeschwindigkeit im Vergleich zu kompilierten Sprachen C) Locust ist ein Lasttestframework, bei dem Performance DAS Produkt ist — Overhead wirkt sich direkt auf sein zentrales Wertversprechen aus D) Die Locust-Maintainer erzwingen strikte Performance-Benchmarks in der CI, die jeden PR ablehnen, der messbare Verlangsamungen verursacht

Antwort anzeigen

Richtige Antwort: C

Der gesamte Zweck von Locust ist das Messen und Erzeugen von Last. Wenn eine Aenderung 5 ms Verarbeitungszeit pro Anfrage bei 10.000 Anfragen/Sekunde hinzufuegt, sind das 50 Sekunden Overhead pro Sekunde. Performance ist keine nicht-funktionale Anforderung — sie IST das Produkt. Das macht Benchmarking zu einem natuerlichen Bestandteil jeder Uebung. Waehrend CI-Benchmarks in manchen Projekten existieren, ist der grundlegende Grund hier der Kernzweck von Locust.

Bewertungsleitfaden

Wichtige Erkenntnisse zum Merken

  1. Brownfield dominiert — 60-80 % der professionellen Entwicklung ist Wartung bestehender Systeme, nicht das Bauen neuer
  2. Lesen uebertrumpft Schreiben — etwa 70 % der Entwicklerzeit entfallen auf Programmverstehen
  3. Tests sind Vertraege — Im Brownfield kodiert die Testsuite erwartetes Verhalten und ist Ihr primaeres Sicherheitsnetz
  4. Kontext ist entscheidend — KI weiss nichts ueber Ihr Projekt, es sei denn Sie teilen es mit, ueber CLAUDE.md oder aehnliche Dateien
  5. CLAUDE.md ist Einfluss, nicht Durchsetzung — Kombinieren Sie sie mit Lintern, Pre-Commit Hooks und CI fuer Zuverlaessigkeit
  6. KI ist nuetzlicher UND gefaehrlicher — Mehr Code zu erklaeren, aber mehr zu zerstoeren und mehr Konventionen zu verletzen
  7. Die Definition of Done erweitert sich — Tests bestehen, Coverage aufrechterhalten, Linter sauber, PR reviewed, Tagebuch vollstaendig
  8. Konventionen sind vorgegeben — Sie befolgen sie, nicht setzen sie; kodieren Sie sie, damit KI sie auch befolgt
  9. Branch-basiertes Tagebuch — In gemeinsamen Codebasen organisieren Sie Tagebucheintraege nach Feature Branch
  10. Refactoring braucht ein Sicherheitsnetz — Erst Tests schreiben, dann refaktorisieren; die Tests beweisen, dass das Verhalten bewahrt wird
© 2026 Dominik Müller   •  Powered by Soopr   •  Theme  Moonwalk