Zu früh programmieren
Der Code beginnt, bevor Inputs, Outputs, Randbedingungen und Bewertungskriterien klar sind.
INFORMATIK RATGEBER · DEUTSCHLAND
Git-Abgabe an der Universität vorbereiten
Ein praktischer Ratgeber für Studierende, die ihre Informatik-Aufgabe selbst bearbeiten und dabei strukturierter, sicherer und nachvollziehbarer vorgehen möchten.
Bei vielen Informatik-Aufgaben entsteht der größte Zeitverlust nicht durch das eigentliche Programmieren, sondern durch unklare Anforderungen, ungeprüfte Annahmen und zu spätes Testen. Dieser Leitfaden hilft dir, die Aufgabe in kleine überprüfbare Schritte zu teilen.
Nutze die Schritte als Checkliste und passe sie an dein Modul an. Wenn dein Dozent eine bestimmte Bibliothek, Programmiersprache, Dateistruktur oder Dokumentationsform verlangt, haben diese Vorgaben immer Vorrang.
saubere Commits
Schreibe zuerst auf, woran du erkennst, dass dieser Schritt erledigt ist. Verwende ein kleines Beispiel statt sofort mit dem gesamten Projekt zu arbeiten. So kannst du Fehler leichter reproduzieren und musst später weniger gleichzeitig verändern.
Achte dabei auf Versionen, Pfade, Eingabeformate, erwartete Ausgaben und Randfälle. Speichere wichtige Zwischenergebnisse, damit du später im Bericht oder Gespräch erklären kannst, wie du von der Aufgabenstellung zur Lösung gekommen bist.
Wenn etwas nicht funktioniert, notiere die genaue Fehlermeldung und den kleinsten Fall, der das Problem auslöst. Ändere anschließend nur eine Annahme oder Einstellung und prüfe erneut. Dieses Vorgehen ist langsamer als zufälliges Probieren für zwei Minuten, aber deutlich schneller als stundenlanges Raten.
README prüfen
Schreibe zuerst auf, woran du erkennst, dass dieser Schritt erledigt ist. Verwende ein kleines Beispiel statt sofort mit dem gesamten Projekt zu arbeiten. So kannst du Fehler leichter reproduzieren und musst später weniger gleichzeitig verändern.
Achte dabei auf Versionen, Pfade, Eingabeformate, erwartete Ausgaben und Randfälle. Speichere wichtige Zwischenergebnisse, damit du später im Bericht oder Gespräch erklären kannst, wie du von der Aufgabenstellung zur Lösung gekommen bist.
Wenn etwas nicht funktioniert, notiere die genaue Fehlermeldung und den kleinsten Fall, der das Problem auslöst. Ändere anschließend nur eine Annahme oder Einstellung und prüfe erneut. Dieses Vorgehen ist langsamer als zufälliges Probieren für zwei Minuten, aber deutlich schneller als stundenlanges Raten.
Secrets entfernen
Schreibe zuerst auf, woran du erkennst, dass dieser Schritt erledigt ist. Verwende ein kleines Beispiel statt sofort mit dem gesamten Projekt zu arbeiten. So kannst du Fehler leichter reproduzieren und musst später weniger gleichzeitig verändern.
Achte dabei auf Versionen, Pfade, Eingabeformate, erwartete Ausgaben und Randfälle. Speichere wichtige Zwischenergebnisse, damit du später im Bericht oder Gespräch erklären kannst, wie du von der Aufgabenstellung zur Lösung gekommen bist.
Wenn etwas nicht funktioniert, notiere die genaue Fehlermeldung und den kleinsten Fall, der das Problem auslöst. Ändere anschließend nur eine Annahme oder Einstellung und prüfe erneut. Dieses Vorgehen ist langsamer als zufälliges Probieren für zwei Minuten, aber deutlich schneller als stundenlanges Raten.
Build und Tests frisch ausführen
Schreibe zuerst auf, woran du erkennst, dass dieser Schritt erledigt ist. Verwende ein kleines Beispiel statt sofort mit dem gesamten Projekt zu arbeiten. So kannst du Fehler leichter reproduzieren und musst später weniger gleichzeitig verändern.
Achte dabei auf Versionen, Pfade, Eingabeformate, erwartete Ausgaben und Randfälle. Speichere wichtige Zwischenergebnisse, damit du später im Bericht oder Gespräch erklären kannst, wie du von der Aufgabenstellung zur Lösung gekommen bist.
Wenn etwas nicht funktioniert, notiere die genaue Fehlermeldung und den kleinsten Fall, der das Problem auslöst. Ändere anschließend nur eine Annahme oder Einstellung und prüfe erneut. Dieses Vorgehen ist langsamer als zufälliges Probieren für zwei Minuten, aber deutlich schneller als stundenlanges Raten.
HÄUFIGE FEHLER
Was Studierende bei solchen Aufgaben oft zu spät bemerken
Viele Probleme entstehen nicht durch mangelnde Fachkenntnisse, sondern weil wichtige Details erst kurz vor der Abgabe geprüft werden. Nutze diese Punkte als Gegencheck, während du noch Zeit zum Korrigieren hast.
Nur den Normalfall testen
Das Beispiel aus der Aufgabenstellung funktioniert, aber leere, große oder ungültige Eingaben wurden nie geprüft.
Umgebung nicht dokumentieren
Versionen, Bibliotheken, Pfade oder Startbefehle fehlen und das Projekt lässt sich nicht reproduzieren.
Bericht und Code widersprechen sich
Die Dokumentation beschreibt eine ältere Implementierung oder Ergebnisse, die inzwischen geändert wurden.
Fehler zufällig ändern
Mehrere Dinge werden gleichzeitig angepasst, sodass unklar bleibt, welche Änderung den Fehler tatsächlich behoben hat.
Abgabedateien nicht prüfen
Temporäre Dateien sind enthalten, Pflichtdateien fehlen oder sensible Zugangsdaten landen versehentlich im Repository.
VOR DER ABGABE
Eine kurze Abschlussprüfung spart viele unnötige Fehler
Öffne das Projekt möglichst aus einer sauberen Umgebung oder einem frisch geklonten Repository. Führe die wichtigsten Tests erneut aus und kontrolliere, ob alle Dateien, Screenshots, Diagramme und Verweise vorhanden sind.
Lies danach die Aufgabenstellung ein letztes Mal neben deiner Abgabe. Diese einfache Gegenprüfung zeigt oft, dass zwar technisch viel gearbeitet wurde, aber eine kleine formale Anforderung noch fehlt.
Projekt startet oder baut sauberwichtige Tests laufen erneutkeine Zugangsdaten im RepositoryREADME und Bericht passen zum CodeDateinamen und Formate stimmen
WENN DU HILFE BRAUCHST
Formuliere eine technische Frage, die sich prüfen lässt
Je genauer du beschreibst, was passiert, desto schneller lässt sich ein Problem eingrenzen. Statt nur „es funktioniert nicht“ zu schreiben, nenne die Eingabe, das tatsächliche Ergebnis, das erwartete Ergebnis und die genaue Fehlermeldung. Bei theoretischen Aufgaben kannst du zusätzlich sagen, welche Definition oder welcher Schritt der Herleitung unklar ist.
Wenn du Screenshots sendest, achte darauf, dass relevante Zeilen lesbar sind und keine Passwörter, Tokens oder persönlichen Daten sichtbar sind. Bei Code ist ein kleiner relevanter Ausschnitt meist hilfreicher als mehrere tausend Zeilen ohne Kontext.
BEISPIEL EINER GUTEN FRAGE
„Bei Eingabe [3, 1, 2] erwarte ich [1, 2, 3], aber meine Funktion gibt [1, 3, 2] zurück. Der Fehler tritt nur auf, wenn die Liste mehr als zwei Elemente hat. Ich habe die Schleife und meinen aktuellen Test angehängt.“
So eine Frage liefert genug Kontext, um Ursache, Annahmen und nächsten Test gezielt zu untersuchen.
STUDENTISCHE CHECKLISTEbrief understoodsmall test caseimplementation checkededge cases testedexplanation ready
WENN DU NOCH FESTSTECKST
Formuliere das Problem so konkret wie möglich
Eine gute Hilfsfrage enthält vier Dinge: Was verlangt die Aufgabe? Was hast du versucht? Was passiert tatsächlich? Was hast du stattdessen erwartet? Mit diesen Informationen lässt sich ein Programmier- oder Verständnisproblem viel schneller eingrenzen.
Frage besprechen