{"id":830,"date":"2026-07-30T12:22:30","date_gmt":"2026-07-30T12:22:30","guid":{"rendered":"https:\/\/matforge.org\/?p=830","raw":"https:\/\/matforge.org\/?p=830"},"modified":"2026-07-30T12:22:30","modified_gmt":"2026-07-30T12:22:30","slug":"best-practices-for-maintaining-scientific-code","status":"publish","type":"post","link":"https:\/\/matforge.org\/de\/best-practices-for-maintaining-scientific-code\/","title":{"rendered":"Best Practices for Maintaining Scientific Code","raw":"Best Practices for Maintaining Scientific Code"},"content":{"rendered":"Reading Time: <\/span> 8<\/span> minutes<\/span><\/span>

Wissenschaftlicher Code beginnt oft als schnelles Skript. Ein Forscher muss einen Datensatz bereinigen, eine Simulation ausf\u00fchren, ein Modell testen, eine Zahl generieren oder eine Hypothese \u00fcberpr\u00fcfen. Der Code kann zun\u00e4chst f\u00fcr eine Person und eine unmittelbare Aufgabe geschrieben werden. Im Laufe der Zeit kann dasselbe Skript Teil eines ver\u00f6ffentlichten Papiers, einer Dissertation, eines Labor-Workflows, eines Open-Source-Projekts oder eines langfristigen Rechenmodells werden.<\/p>\n

Wenn Code wissenschaftliche Ergebnisse beeinflusst, wird er Teil der Forschung selbst. Es sollte verst\u00e4ndlich, reproduzierbar, testbar und sicher zu \u00e4ndern sein. Schlecht gepflegter Code kann die \u00dcberpr\u00fcfung von Ergebnissen erschweren, die zuk\u00fcnftige Arbeit verlangsamen und Fehler einleiten, die schwer zu erkennen sind.<\/p>\n

Die Aufrechterhaltung des wissenschaftlichen Codes bedeutet nicht, jedes Forschungsskript in ein gro\u00dfes kommerzielles Softwareprodukt zu verwandeln. Es bedeutet, gen\u00fcgend Struktur und Disziplin zu verwenden, damit der Code von Ihrem zuk\u00fcnftigen Selbst, Mitarbeitern, Rezensenten und jedem vertrauen kann, der sp\u00e4ter auf der Arbeit aufbauen muss.<\/p>\n

Warum wissenschaftlicher Code gewartet werden muss<\/h2>\n

Der wissenschaftliche Code lebt oft l\u00e4nger als erwartet. Ein kleines Analyseskript kann f\u00fcr einen zweiten Datensatz wiederverwendet werden. Eine Simulation kann die Grundlage f\u00fcr ein Papier werden. Ein Notebook kann mit einem Mitarbeiter geteilt werden. Ein Modell kann von einem zuk\u00fcnftigen Studenten im selben Labor erweitert werden.<\/p>\n

Dadurch entsteht ein Problem. Der Code, der w\u00e4hrend der Woche, in der es geschrieben wurde, klar war, kann Monate sp\u00e4ter verwirrend werden. Dateipfade k\u00f6nnen kaputt gehen. Bibliotheksversionen k\u00f6nnen sich \u00e4ndern. Parameter k\u00f6nnen vergessen werden. Datenreinigungsschritte k\u00f6nnen unklar sein. Eine Figur ist m\u00f6glicherweise nicht wiederherzustellen, da sich niemand daran erinnert, welches Skript sie produziert hat.<\/p>\n

Wartung hilft, diese Probleme zu vermeiden. Es sch\u00fctzt die Zuverl\u00e4ssigkeit des Rechercheprozesses, indem es den Code erleichtert, zu \u00fcberpr\u00fcfen, erneut auszuf\u00fchren, zu testen und zu aktualisieren. In der Computerforschung ist dies keine zus\u00e4tzliche B\u00fcrokratie. Es ist Teil der Forschungsqualit\u00e4t.<\/p>\n

Schreiben Sie zuerst Code f\u00fcr Ihr zuk\u00fcnftiges Selbst<\/h2>\n

Die erste Person, die vom sauberen wissenschaftlichen Kodex profitiert, ist normalerweise der Autor. Nach ein paar Monaten von einem Projekt kann sich sogar Ihr eigener Code ungewohnt anf\u00fchlen. Gute Benennung, Struktur und Kommentare helfen Ihnen, zur Arbeit zur\u00fcckzukehren, ohne von Null zu beginnen.<\/p>\n

Verwenden Sie Variablen- und Funktionsnamen, die erkl\u00e4ren, was sie darstellen. Ein Name wie Temperature_Kelvin<\/strong> ist n\u00fctzlicher als temp2<\/strong>. Eine Funktion mit dem Namen calculate_growth_rate<\/strong> ist leichter zu verstehen als die process_data<\/strong>.<\/p>\n

Teilen Sie lange Skripte in kleinere Funktionen auf. Ein einzelnes Skript, das Daten l\u00e4dt, bereinigt, ein Modell ausf\u00fchrt, Diagramme generiert und Ergebnisse speichert, ist schwierig zu debuggen. Kleinere Funktionen erleichtern den Test und die Wiederverwendung des Workflows.<\/p>\n

Kommentare sollten Entscheidungen erkl\u00e4ren, nicht offensichtlichen Code wiederholen. Ein Kommentar ist am n\u00fctzlichsten, wenn erkl\u00e4rt wird, warum eine Methode, ein Schwellenwert, eine Annahme oder ein Parameter ausgew\u00e4hlt wurde.<\/p>\n

Behalten Sie eine klare Projektstruktur bei<\/h2>\n

Wissenschaftliche Projekte k\u00f6nnen schnell chaotisch werden, wenn sich Skripte, Rohdaten, verarbeitete Daten, Notizb\u00fccher, Zahlen und Ergebnisse in einem Ordner befinden. Eine \u00fcbersichtliche Struktur erleichtert die Navigation und verringert die Wahrscheinlichkeit, die falsche Datei zu verwenden.<\/p>\n

project-name\/\n  README.md\n  data\/\n    raw\/\n    processed\/\n  src\/\n  notebooks\/\n  scripts\/\n  results\/\n  figures\/\n  tests\/\n  docs\/\n  environment.yml\n<\/code><\/pre>\n
Die genaue Struktur kann variieren, aber die Logik sollte klar sein. Rohdaten sollten von verarbeiteten Daten getrennt werden. Stabiler Quellcode sollte von explorativen Notebooks getrennt werden. Ergebnisse und Zahlen sollten leicht auf den Code zur\u00fcckverfolgt werden, der sie generiert hat.<\/p>\n
Der Ordner data\/raw<\/strong> sollte Originaldaten enthalten, die nicht manuell bearbeitet werden. Der Ordner Data\/Processed<\/strong> kann bereinigte oder transformierte Daten enthalten. Der Ordner src<\/strong> sollte wiederverwendbaren Code enthalten. Der Ordner Notebooks<\/strong> kann zur Erkundung verwendet werden. Der Ordner Tests<\/strong> sollte \u00dcberpr\u00fcfungen enthalten, die best\u00e4tigen, dass der wichtige Code weiterhin funktioniert.<\/p>\n
Verwenden Sie die Versionskontrolle von Anfang an<\/h2>\n
Die Versionskontrolle hilft dabei zu verfolgen, wie sich der Code im Laufe der Zeit \u00e4ndert. Git ist das g\u00e4ngigste Werkzeug, aber das Prinzip ist wichtiger als die spezifische Plattform: Sie sollten in der Lage sein zu sehen, was sich ge\u00e4ndert hat, wann es sich ge\u00e4ndert hat und warum.<\/p>\n
Ohne Versionskontrolle erstellen Forscher h\u00e4ufig Dateien mit Namen wie Analysis_Final<\/strong>, Analysis_Final2<\/strong>, Analysis_New<\/strong> oder Analysis_Really_Final<\/strong>. Dies wird schnell verwirrend und unzuverl\u00e4ssig.<\/p>\n
Zu den Gewohnheiten f\u00fcr die Versionskontrolle geh\u00f6ren das Erstellen kleiner logischer Commits, das Schreiben aussagekr\u00e4ftiger Commit-Nachrichten, die Verwendung von Verzweigungen f\u00fcr Experimente und das Markieren der Codeversion, die f\u00fcr ein Papier oder einen Bericht verwendet wird.<\/p>\n
Seien Sie vorsichtig mit gro\u00dfen Datens\u00e4tzen und sensiblen Informationen. Nicht alles geh\u00f6rt in ein Git-Repository. Gro\u00dfe Dateien, private Daten, Anmeldeinformationen und eingeschr\u00e4nkte Forschungsmaterialien sollten \u00fcber geeignete Speichersysteme und Zugriffskontrollen gehandhabt werden.<\/p>\n
Dokumentieren Sie den Zweck, die Eingaben und Ausgaben<\/h2>\n
Die Dokumentation muss nicht lang sein, um n\u00fctzlich zu sein. Zumindest sollten einige praktische Fragen beantwortet werden: Was bewirkt dieser Code, welche Daten ben\u00f6tigt er, wie laufen Sie ihn und welche Ergebnisse sollte er produzieren?<\/p>\n
Eine gute Readme ist der Einstiegspunkt in ein wissenschaftliches Codeprojekt. Es sollte den Projektzweck, Installationsschritte, Abh\u00e4ngigkeiten, grundlegende Nutzung, Datenaufbereitung, erwartete Ausgaben und Kontakt- oder Betreuerinformationen erl\u00e4utern.<\/p>\n
Wenn der Code eine Ver\u00f6ffentlichung oder einen \u00f6ffentlichen Datensatz unterst\u00fctzt, sollte in der Readme auch erl\u00e4utert werden, wie die Arbeit zitiert werden soll und welche Version des Codes die ver\u00f6ffentlichten Ergebnisse hervorgebracht hat.<\/p>\n
Die Dokumentation sollte schrittweise geschrieben werden. Wenn Sie bis zum Ende des Projekts warten, werden m\u00f6glicherweise bereits viele Details vergessen. Einige w\u00e4hrend der Entwicklung geschriebene Notizen k\u00f6nnen Stunden sp\u00e4ter sparen.<\/p>\n
Separate Konfiguration vom Code<\/h2>\n
Der wissenschaftliche Code h\u00e4ngt h\u00e4ufig von Parametern ab: Dateipfade, Modelleinstellungen, Schwellenwerte, zuf\u00e4llige Seeds, Ausgabeordner, Datensatzversionen und Experimentieroptionen. Wenn diese Werte in Skripten ausgeblendet sind, wird der Workflow fragil.<\/p>\n
Besonders h\u00e4ufig sind hartcodierte Pfade. Ein Skript funktioniert m\u00f6glicherweise nur auf dem Laptop einer Person, da es auf einen lokalen Ordner verweist. Wenn eine andere Person es ausf\u00fchrt, schl\u00e4gt das Skript sofort fehl.<\/p>\n
Ein besserer Ansatz besteht darin, die Konfiguration vom Code zu trennen. Verwenden Sie Konfigurationsdateien, Befehlszeilenargumente, Umgebungsvariablen oder eindeutig benannte Parameterdateien. Dies erleichtert die Wiederholung und den Vergleich.<\/p>\n
Wenn Parameter sichtbar sind, wird der Forschungsprozess transparenter. Jemand, der die Arbeit \u00fcberpr\u00fcft, kann sehen, welche Einstellungen verwendet wurden, anstatt lange Skripte zu durchsuchen.<\/p>\n
Machen Sie die rechnerische Umgebung reproduzierbar<\/h2>\n
Wissenschaftlicher Code l\u00e4uft nicht isoliert. Es h\u00e4ngt von Programmiersprachen, Bibliotheken, Compilern, Betriebssystemen und manchmal Hardware ab. Ein Skript, das heute funktioniert, kann n\u00e4chstes Jahr fehlschlagen, weil sich eine Bibliothek ge\u00e4ndert hat.<\/p>\n
Um dieses Risiko zu reduzieren, dokumentieren Sie das Rechenumfeld. Je nach Sprache und Projekt k\u00f6nnen dies Requirements.txt<\/strong>, Environment.yml<\/strong>, Sperrdateien, virtuelle Umgebungen, Container oder dokumentierte Compilerversionen umfassen.<\/p>\n
Das Ziel ist es, das Problem \u201eWorks on My Machine\u201c zu vermeiden. Ein Mitarbeiter sollte in der Lage sein, eine \u00e4hnliche Umgebung einzurichten und den Code auszuf\u00fchren, ohne zu erraten, welche Paketversionen verwendet wurden.<\/p>\n
Bei wichtigen ver\u00f6ffentlichten Arbeiten sollten Sie die genaue Codeversion und die Umgebungsinformationen archivieren, die zur Erzeugung der Ergebnisse verwendet werden.<\/p>\n
Testen Sie kritische wissenschaftliche Logik<\/h2>\n
Testen sind nicht nur f\u00fcr kommerzielle Software. Wissenschaftlicher Code kann fehlerfrei laufen und trotzdem falsche Ergebnisse liefern. Tests helfen Fehler zu fangen, bevor sie die Schlussfolgerungen beeinflussen.<\/p>\n
Nicht jeder Teil eines Forschungsprojekts erfordert umfangreiche Tests, aber die kritische Logik sollte \u00fcberpr\u00fcft werden. Dazu geh\u00f6ren Datenreinigungsfunktionen, numerische Routinen, Einheitenkonvertierungen, Randbedingungen, statistische Berechnungen und Simulationsausgaben.<\/p>\n\n\n\n\n\n\n\n
Testtyp<\/th>\nWas es sch\u00fctzt<\/th>\nBeispiel<\/th>\n<\/tr>\n
Unit-Test<\/td>\nkleines Funktionsverhalten<\/td>\nEine Normalisierungsfunktion gibt erwartete Werte zur\u00fcck.<\/td>\n<\/tr>\n
Regressionstest<\/td>\nZuvor verifizierte Ergebnisse<\/td>\nEine Simulation erzeugt immer noch den gleichen Benchmark-Ausgang.<\/td>\n<\/tr>\n
Datenvalidierungstest<\/td>\nEingabeannahmen<\/td>\nIn einem Feld, das positiv sein muss, erscheinen keine negativen Werte.<\/td>\n<\/tr>\n
Integrationstest<\/td>\nVollst\u00e4ndiges Workflow-Verhalten<\/td>\nDie Pipeline l\u00e4uft von den Eingabedaten bis zur endg\u00fcltigen Ausgabe.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
Tests sind besonders n\u00fctzlich, wenn sich Code \u00e4ndert. Ein kleiner Refaktor kann die Ergebnisse versehentlich ver\u00e4ndern. Ein Regressionstest kann Sie warnen, wenn sich eine \u00c4nderung auf die zuvor vertrauensw\u00fcrdige Ausgabe auswirkt.<\/p>\n
Behandeln Sie Daten als Teil des Codebase-Workflows<\/h2>\n
Der wissenschaftliche Code h\u00e4ngt in der Regel stark von Daten ab. Wenn der Daten-Workflow unklar ist, sind die Ergebnisse auch dann schwer zu reproduzieren, wenn der Code verf\u00fcgbar ist.<\/p>\n
Rohdaten sollten nach M\u00f6glichkeit erhalten bleiben. Bearbeiten Sie die Originaldateien nicht manuell, ohne aufzuzeichnen, was sich ge\u00e4ndert hat. Wenn Daten bereinigt oder transformiert werden m\u00fcssen, dokumentieren Sie die Schritte und behalten Sie den Verarbeitungscode.<\/p>\n
Datensatzversionen verfolgen. Zeichnen Sie auf, woher die Daten stammen, wann sie heruntergeladen oder gesammelt wurden, welche Ausschl\u00fcsse angewendet wurden, wie fehlende Werte behandelt wurden und welche verarbeitete Datei f\u00fcr jedes Ergebnis verwendet wurde.<\/p>\n
Bei wichtigen Dateien k\u00f6nnen Pr\u00fcfsummen oder Manifeste helfen, zu best\u00e4tigen, dass sich die Daten nicht unerwartet ge\u00e4ndert haben. Dies ist besonders n\u00fctzlich, wenn Sie mit gro\u00dfen Datens\u00e4tzen, gemeinsam genutztem Speicher oder lang laufenden Projekten arbeiten.<\/p>\n
Vermeiden Sie nur Notebook-Forschungspipelines<\/h2>\n
Notebooks sind n\u00fctzlich f\u00fcr die Erforschung, Visualisierung und Erkl\u00e4rung. Sie erm\u00f6glichen es Forschern, Code, Text, Diagramme und Ergebnisse an einem Ort zu kombinieren. Notebooks k\u00f6nnen jedoch schwierig zu warten werden, wenn sie die gesamte Forschungspipeline halten.<\/p>\n
H\u00e4ufige Probleme mit dem Notebook sind auslaufende Zellen, versteckter Zustand, unklare Abh\u00e4ngigkeiten, wiederholter Code, gemischte Analyse- und Produktionslogik und Schwierigkeitstestfunktionen.<\/p>\n
Ein besserer Ansatz besteht darin, Notebooks f\u00fcr die Erforschung und Kommunikation zu verwenden und stabile Funktionen in wiederverwendbare Quelldateien zu verschieben. Notebooks sollten getesteten Code aufrufen, anstatt alle wichtigen Logiken selbst zu enthalten.<\/p>\n
Bevor Sie ein Notebook freigeben oder archivieren, starten Sie es neu und f\u00fchren Sie alle Zellen von oben nach unten aus. Dies hilft zu best\u00e4tigen, dass das Notebook nicht vom versteckten Zustand fr\u00fcherer Experimente abh\u00e4ngt.<\/p>\n
Verwenden Sie nach M\u00f6glichkeit Code-Reviews oder Peer-Checks<\/h2>\n
Wissenschaftlicher Kodex profitiert von der \u00dcberpr\u00fcfung. Eine zweite Person kann unklare Annahmen, falsche Einheiten, fragile Pfade, fehlende Validierung, verwirrende Namen oder doppelte Logik bemerken, die der Autor m\u00f6glicherweise \u00fcbersehen kann.<\/p>\n
Die \u00dcberpr\u00fcfung des Codes in der Forschung muss nicht formell oder einsch\u00fcchternd sein. Schon ein kurzer Peer-Check kann die Zuverl\u00e4ssigkeit verbessern. Ein Mitarbeiter kann eine Datenreinigungsfunktion, eine Modellimplementierung, eine statistische Berechnung oder das Skript \u00fcberpr\u00fcfen, das endg\u00fcltige Zahlen generiert.<\/p>\n
Das Ziel ist keine Kritik. Ziel ist es, die Forschung vor vermeidbaren Fehlern zu sch\u00fctzen. Die wissenschaftliche Arbeit wird st\u00e4rker, wenn wichtiger Code f\u00fcr jemand anderen einfacher zu inspizieren ist.<\/p>\n
Experimente und Ergebnisse klar protokollieren<\/h2>\n
Bei wissenschaftlichen Projekten handelt es sich h\u00e4ufig um viele L\u00e4ufe mit unterschiedlichen Parametern, Datens\u00e4tzen, zuf\u00e4lligen Samen oder Modelleinstellungen. Ohne klare Protokollierung wird es schwierig zu wissen, welcher Lauf erzeugt wird.<\/p>\n
N\u00fctzliche Versuchsprotokolle k\u00f6nnen sein:<\/p>\n
    \n
  • Datum und Uhrzeit<\/li>\n
  • Code-Version<\/li>\n
  • Datensatzversion<\/li>\n
  • Rahmen<\/li>\n
  • Zuf\u00e4lliger Samen<\/li>\n
  • Software-Umgebung<\/li>\n
  • Ausgabeort<\/li>\n
  • Erfolg oder Fehlerstatus<\/li>\n
  • Kurze Hinweise zu \u00c4nderungen<\/li>\n<\/ul>\n
    Zuf\u00e4llige Samen sind besonders wichtig bei Simulationen, maschinellem Lernen, Probenahme und stochastischen Modellen. Die Aufzeichnung hilft dabei, die Ergebnisse zu reproduzieren und zu debuggen.<\/p>\n
    Fehler und Randf\u00e4lle explizit behandeln<\/h2>\n
    Beim wissenschaftlichen Rechnen k\u00f6nnen stille Ausf\u00e4lle schlimmer sein als sichtbare Fehler. Ein deutlich abst\u00fcrztes Skript ist leichter zu reparieren als ein Skript, das leise zu falschen Ergebnissen f\u00fchrt.<\/p>\n
    Validieren Sie die Eingaben, bevor Sie wichtige Berechnungen ausf\u00fchren. \u00dcberpr\u00fcfen Sie Einheiten, Bereiche, Dimensionen, fehlende Werte, Dateiexistenz und Annahmen \u00fcber die Daten. Wenn eine kritische Annahme fehlschl\u00e4gt, sollte die Pipeline klar anhalten oder warnen.<\/p>\n
    Fehlermeldungen sollten sinnvoll sein. Eine Nachricht wie Eingabedatei fehlt: Erwartete Daten \/ verarbeitete Daten \/ Clean_sample.csv <\/strong> ist viel n\u00fctzlicher als ein generischer Absturz.<\/p>\n
    Eine gute Fehlerbehandlung sch\u00fctzt die Forschungsintegrit\u00e4t, da falsche Annahmen davon abgehalten werden, sich leise in die endg\u00fcltigen Ergebnisse zu bewegen.<\/p>\n
    \u00dcbergabe und Langzeitnutzung planen<\/h2>\n
    Der wissenschaftliche Code \u00fcberlebt oft die Person, die ihn geschrieben hat. Ein Student absolviert. Ein Postdoc geht. Ein Mitarbeiter tritt sp\u00e4ter bei. Ein Labor m\u00f6chte eine Pipeline f\u00fcr ein neues Projekt wiederverwenden. Die Planung der \u00dcbergabe erleichtert diesen \u00dcbergang.<\/p>\n
    Ein wartbares Projekt sollte ein Setup-Handbuch, Beispiel-Ein- und Ausgabe, bekannte Einschr\u00e4nkungen, Workflow-Beschreibung, Issue-Tracker, Lizenz-, Zitierinformationen und archivierte Freigabe f\u00fcr ver\u00f6ffentlichte Arbeiten enthalten.<\/p>\n
    Es ist auch n\u00fctzlich, eine kurze Erl\u00e4uterung zu enthalten, was der Code nicht tut. Einschr\u00e4nkungen sind Teil der verantwortungsvollen Dokumentation. Sie helfen zuk\u00fcnftigen Benutzern zu vermeiden, den Code auf eine Weise anzuwenden, f\u00fcr die er nicht entwickelt wurde.<\/p>\n
    H\u00e4ufige Fehler zu vermeiden<\/h2>\n
    Alles in einem Skript behalten<\/h3>\n
    Ein gro\u00dfes Skript kann schnell geschrieben werden, aber es wird schwer zu lesen, zu testen, zu debuggen und wiederzuverwenden. Unterbrechen Sie stabile Logik in Funktionen und Module.<\/p>\n
    Daten manuell \u00e4ndern, ohne sie aufzuzeichnen<\/h3>\n
    Manuelle Bearbeitungen erschweren die Reproduzierbarkeit. Wenn sich Daten \u00e4ndern, sollte die \u00c4nderung dokumentiert oder \u00fcber ein Skript durchgef\u00fchrt werden.<\/p>\n
    Abh\u00e4ngig von nicht spezifizierten Softwareversionen<\/h3>\n
    Wenn Abh\u00e4ngigkeiten nicht aufgezeichnet werden, kann ein anderer Benutzer neuere Versionen installieren und unterschiedliche Ergebnisse oder Fehler erhalten.<\/p>\n
    Tests als unn\u00f6tig behandeln<\/h3>\n
    Wissenschaftlicher Code kann schwerwiegende Fehler enthalten, selbst wenn er erfolgreich ausgef\u00fchrt wird. Tests sch\u00fctzen kritische Berechnungen und Workflows.<\/p>\n
    Nur am Ende dokumentieren<\/h3>\n
    Wichtige Details werden oft am Ende eines Projekts vergessen. Dokumentieren Sie Annahmen, Parameter und Workflow-Entscheidungen, wie das Projekt entwickelt.<\/p>\n
    Letzte Gedanken: Wartbarer Code erleichtert das Vertrauen der Wissenschaft<\/h2>\n
    Maintaining scientific code is not about making research slower. Es geht darum, die Forschung leichter zu verstehen, zu wiederholen, zu \u00fcberpr\u00fcfen und zu erweitern. Ein Projekt mit klarer Struktur, Versionskontrolle, Dokumentation, Tests, reproduzierbaren Umgebungen und sorgf\u00e4ltiger Datenverarbeitung ist zuverl\u00e4ssiger als ein Projekt mit Speicher und verstreuten Dateien.<\/p>\n
    Gute Wartungspraktiken m\u00fcssen nicht \u00fcbertrieben sein. Beginnen Sie mit den Grundlagen: Namen l\u00f6schen, organisierte Ordner, Readme, Versionskontrolle, aufgezeichnete Abh\u00e4ngigkeiten, einfache Tests und dokumentierte Datenschritte. Diese Gewohnheiten schaffen eine Grundlage, die sowohl die Software als auch die darauf basierende Forschung sch\u00fctzt.<\/p>\n
    Der wissenschaftliche Kodex ist Teil der Beweise f\u00fcr wissenschaftliche Behauptungen. Wenn es gut aufrechterhalten wird, werden die Ergebnisse leichter zu vertrauen und die zuk\u00fcnftige Arbeit leichter zu bauen.<\/p>\n","protected":false,"raw":"
    Wissenschaftlicher Code beginnt oft als schnelles Skript. Ein Forscher muss einen Datensatz bereinigen, eine Simulation ausf\u00fchren, ein Modell testen, eine Zahl generieren oder eine Hypothese \u00fcberpr\u00fcfen. Der Code kann zun\u00e4chst f\u00fcr eine Person und eine unmittelbare Aufgabe geschrieben werden. Im Laufe der Zeit kann dasselbe Skript Teil eines ver\u00f6ffentlichten Papiers, einer Dissertation, eines Labor-Workflows, eines Open-Source-Projekts oder eines langfristigen Rechenmodells werden.<\/p>\n
    Wenn Code wissenschaftliche Ergebnisse beeinflusst, wird er Teil der Forschung selbst. Es sollte verst\u00e4ndlich, reproduzierbar, testbar und sicher zu \u00e4ndern sein. Schlecht gepflegter Code kann die \u00dcberpr\u00fcfung von Ergebnissen erschweren, die zuk\u00fcnftige Arbeit verlangsamen und Fehler einleiten, die schwer zu erkennen sind.<\/p>\n
    Die Aufrechterhaltung des wissenschaftlichen Codes bedeutet nicht, jedes Forschungsskript in ein gro\u00dfes kommerzielles Softwareprodukt zu verwandeln. Es bedeutet, gen\u00fcgend Struktur und Disziplin zu verwenden, damit der Code von Ihrem zuk\u00fcnftigen Selbst, Mitarbeitern, Rezensenten und jedem vertrauen kann, der sp\u00e4ter auf der Arbeit aufbauen muss.<\/p>\n
    Warum wissenschaftlicher Code gewartet werden muss<\/h2>\n
    Der wissenschaftliche Code lebt oft l\u00e4nger als erwartet. Ein kleines Analyseskript kann f\u00fcr einen zweiten Datensatz wiederverwendet werden. Eine Simulation kann die Grundlage f\u00fcr ein Papier werden. Ein Notebook kann mit einem Mitarbeiter geteilt werden. Ein Modell kann von einem zuk\u00fcnftigen Studenten im selben Labor erweitert werden.<\/p>\n
    Dadurch entsteht ein Problem. Der Code, der w\u00e4hrend der Woche, in der es geschrieben wurde, klar war, kann Monate sp\u00e4ter verwirrend werden. Dateipfade k\u00f6nnen kaputt gehen. Bibliotheksversionen k\u00f6nnen sich \u00e4ndern. Parameter k\u00f6nnen vergessen werden. Datenreinigungsschritte k\u00f6nnen unklar sein. Eine Figur ist m\u00f6glicherweise nicht wiederherzustellen, da sich niemand daran erinnert, welches Skript sie produziert hat.<\/p>\n
    Wartung hilft, diese Probleme zu vermeiden. Es sch\u00fctzt die Zuverl\u00e4ssigkeit des Rechercheprozesses, indem es den Code erleichtert, zu \u00fcberpr\u00fcfen, erneut auszuf\u00fchren, zu testen und zu aktualisieren. In der Computerforschung ist dies keine zus\u00e4tzliche B\u00fcrokratie. Es ist Teil der Forschungsqualit\u00e4t.<\/p>\n
    Schreiben Sie zuerst Code f\u00fcr Ihr zuk\u00fcnftiges Selbst<\/h2>\n
    Die erste Person, die vom sauberen wissenschaftlichen Kodex profitiert, ist normalerweise der Autor. Nach ein paar Monaten von einem Projekt kann sich sogar Ihr eigener Code ungewohnt anf\u00fchlen. Gute Benennung, Struktur und Kommentare helfen Ihnen, zur Arbeit zur\u00fcckzukehren, ohne von Null zu beginnen.<\/p>\n
    Verwenden Sie Variablen- und Funktionsnamen, die erkl\u00e4ren, was sie darstellen. Ein Name wie Temperature_Kelvin<\/strong> ist n\u00fctzlicher als temp2<\/strong>. Eine Funktion mit dem Namen calculate_growth_rate<\/strong> ist leichter zu verstehen als die process_data<\/strong>.<\/p>\n
    Teilen Sie lange Skripte in kleinere Funktionen auf. Ein einzelnes Skript, das Daten l\u00e4dt, bereinigt, ein Modell ausf\u00fchrt, Diagramme generiert und Ergebnisse speichert, ist schwierig zu debuggen. Kleinere Funktionen erleichtern den Test und die Wiederverwendung des Workflows.<\/p>\n
    Kommentare sollten Entscheidungen erkl\u00e4ren, nicht offensichtlichen Code wiederholen. Ein Kommentar ist am n\u00fctzlichsten, wenn erkl\u00e4rt wird, warum eine Methode, ein Schwellenwert, eine Annahme oder ein Parameter ausgew\u00e4hlt wurde.<\/p>\n
    Behalten Sie eine klare Projektstruktur bei<\/h2>\n
    Wissenschaftliche Projekte k\u00f6nnen schnell chaotisch werden, wenn sich Skripte, Rohdaten, verarbeitete Daten, Notizb\u00fccher, Zahlen und Ergebnisse in einem Ordner befinden. Eine \u00fcbersichtliche Struktur erleichtert die Navigation und verringert die Wahrscheinlichkeit, die falsche Datei zu verwenden.<\/p>\n
    project-name\/\n  README.md\n  data\/\n    raw\/\n    processed\/\n  src\/\n  notebooks\/\n  scripts\/\n  results\/\n  figures\/\n  tests\/\n  docs\/\n  environment.yml\n<\/code><\/pre>\n
    Die genaue Struktur kann variieren, aber die Logik sollte klar sein. Rohdaten sollten von verarbeiteten Daten getrennt werden. Stabiler Quellcode sollte von explorativen Notebooks getrennt werden. Ergebnisse und Zahlen sollten leicht auf den Code zur\u00fcckverfolgt werden, der sie generiert hat.<\/p>\n
    Der Ordner data\/raw<\/strong> sollte Originaldaten enthalten, die nicht manuell bearbeitet werden. Der Ordner Data\/Processed<\/strong> kann bereinigte oder transformierte Daten enthalten. Der Ordner src<\/strong> sollte wiederverwendbaren Code enthalten. Der Ordner Notebooks<\/strong> kann zur Erkundung verwendet werden. Der Ordner Tests<\/strong> sollte \u00dcberpr\u00fcfungen enthalten, die best\u00e4tigen, dass der wichtige Code weiterhin funktioniert.<\/p>\n
    Verwenden Sie die Versionskontrolle von Anfang an<\/h2>\n
    Die Versionskontrolle hilft dabei zu verfolgen, wie sich der Code im Laufe der Zeit \u00e4ndert. Git ist das g\u00e4ngigste Werkzeug, aber das Prinzip ist wichtiger als die spezifische Plattform: Sie sollten in der Lage sein zu sehen, was sich ge\u00e4ndert hat, wann es sich ge\u00e4ndert hat und warum.<\/p>\n
    Ohne Versionskontrolle erstellen Forscher h\u00e4ufig Dateien mit Namen wie Analysis_Final<\/strong>, Analysis_Final2<\/strong>, Analysis_New<\/strong> oder Analysis_Really_Final<\/strong>. Dies wird schnell verwirrend und unzuverl\u00e4ssig.<\/p>\n
    Zu den Gewohnheiten f\u00fcr die Versionskontrolle geh\u00f6ren das Erstellen kleiner logischer Commits, das Schreiben aussagekr\u00e4ftiger Commit-Nachrichten, die Verwendung von Verzweigungen f\u00fcr Experimente und das Markieren der Codeversion, die f\u00fcr ein Papier oder einen Bericht verwendet wird.<\/p>\n
    Seien Sie vorsichtig mit gro\u00dfen Datens\u00e4tzen und sensiblen Informationen. Nicht alles geh\u00f6rt in ein Git-Repository. Gro\u00dfe Dateien, private Daten, Anmeldeinformationen und eingeschr\u00e4nkte Forschungsmaterialien sollten \u00fcber geeignete Speichersysteme und Zugriffskontrollen gehandhabt werden.<\/p>\n
    Dokumentieren Sie den Zweck, die Eingaben und Ausgaben<\/h2>\n
    Die Dokumentation muss nicht lang sein, um n\u00fctzlich zu sein. Zumindest sollten einige praktische Fragen beantwortet werden: Was bewirkt dieser Code, welche Daten ben\u00f6tigt er, wie laufen Sie ihn und welche Ergebnisse sollte er produzieren?<\/p>\n
    Eine gute Readme ist der Einstiegspunkt in ein wissenschaftliches Codeprojekt. Es sollte den Projektzweck, Installationsschritte, Abh\u00e4ngigkeiten, grundlegende Nutzung, Datenaufbereitung, erwartete Ausgaben und Kontakt- oder Betreuerinformationen erl\u00e4utern.<\/p>\n
    Wenn der Code eine Ver\u00f6ffentlichung oder einen \u00f6ffentlichen Datensatz unterst\u00fctzt, sollte in der Readme auch erl\u00e4utert werden, wie die Arbeit zitiert werden soll und welche Version des Codes die ver\u00f6ffentlichten Ergebnisse hervorgebracht hat.<\/p>\n
    Die Dokumentation sollte schrittweise geschrieben werden. Wenn Sie bis zum Ende des Projekts warten, werden m\u00f6glicherweise bereits viele Details vergessen. Einige w\u00e4hrend der Entwicklung geschriebene Notizen k\u00f6nnen Stunden sp\u00e4ter sparen.<\/p>\n
    Separate Konfiguration vom Code<\/h2>\n
    Der wissenschaftliche Code h\u00e4ngt h\u00e4ufig von Parametern ab: Dateipfade, Modelleinstellungen, Schwellenwerte, zuf\u00e4llige Seeds, Ausgabeordner, Datensatzversionen und Experimentieroptionen. Wenn diese Werte in Skripten ausgeblendet sind, wird der Workflow fragil.<\/p>\n
    Besonders h\u00e4ufig sind hartcodierte Pfade. Ein Skript funktioniert m\u00f6glicherweise nur auf dem Laptop einer Person, da es auf einen lokalen Ordner verweist. Wenn eine andere Person es ausf\u00fchrt, schl\u00e4gt das Skript sofort fehl.<\/p>\n
    Ein besserer Ansatz besteht darin, die Konfiguration vom Code zu trennen. Verwenden Sie Konfigurationsdateien, Befehlszeilenargumente, Umgebungsvariablen oder eindeutig benannte Parameterdateien. Dies erleichtert die Wiederholung und den Vergleich.<\/p>\n
    Wenn Parameter sichtbar sind, wird der Forschungsprozess transparenter. Jemand, der die Arbeit \u00fcberpr\u00fcft, kann sehen, welche Einstellungen verwendet wurden, anstatt lange Skripte zu durchsuchen.<\/p>\n
    Machen Sie die rechnerische Umgebung reproduzierbar<\/h2>\n
    Wissenschaftlicher Code l\u00e4uft nicht isoliert. Es h\u00e4ngt von Programmiersprachen, Bibliotheken, Compilern, Betriebssystemen und manchmal Hardware ab. Ein Skript, das heute funktioniert, kann n\u00e4chstes Jahr fehlschlagen, weil sich eine Bibliothek ge\u00e4ndert hat.<\/p>\n
    Um dieses Risiko zu reduzieren, dokumentieren Sie das Rechenumfeld. Je nach Sprache und Projekt k\u00f6nnen dies Requirements.txt<\/strong>, Environment.yml<\/strong>, Sperrdateien, virtuelle Umgebungen, Container oder dokumentierte Compilerversionen umfassen.<\/p>\n
    Das Ziel ist es, das Problem \u201eWorks on My Machine\u201c zu vermeiden. Ein Mitarbeiter sollte in der Lage sein, eine \u00e4hnliche Umgebung einzurichten und den Code auszuf\u00fchren, ohne zu erraten, welche Paketversionen verwendet wurden.<\/p>\n
    Bei wichtigen ver\u00f6ffentlichten Arbeiten sollten Sie die genaue Codeversion und die Umgebungsinformationen archivieren, die zur Erzeugung der Ergebnisse verwendet werden.<\/p>\n
    Testen Sie kritische wissenschaftliche Logik<\/h2>\n
    Testen sind nicht nur f\u00fcr kommerzielle Software. Wissenschaftlicher Code kann fehlerfrei laufen und trotzdem falsche Ergebnisse liefern. Tests helfen Fehler zu fangen, bevor sie die Schlussfolgerungen beeinflussen.<\/p>\n
    Nicht jeder Teil eines Forschungsprojekts erfordert umfangreiche Tests, aber die kritische Logik sollte \u00fcberpr\u00fcft werden. Dazu geh\u00f6ren Datenreinigungsfunktionen, numerische Routinen, Einheitenkonvertierungen, Randbedingungen, statistische Berechnungen und Simulationsausgaben.<\/p>\n\n\n\n\n\n\n
    Testtyp<\/th>\nWas es sch\u00fctzt<\/th>\nBeispiel<\/th>\n<\/tr>\n
    Unit-Test<\/td>\nkleines Funktionsverhalten<\/td>\nEine Normalisierungsfunktion gibt erwartete Werte zur\u00fcck.<\/td>\n<\/tr>\n
    Regressionstest<\/td>\nZuvor verifizierte Ergebnisse<\/td>\nEine Simulation erzeugt immer noch den gleichen Benchmark-Ausgang.<\/td>\n<\/tr>\n
    Datenvalidierungstest<\/td>\nEingabeannahmen<\/td>\nIn einem Feld, das positiv sein muss, erscheinen keine negativen Werte.<\/td>\n<\/tr>\n
    Integrationstest<\/td>\nVollst\u00e4ndiges Workflow-Verhalten<\/td>\nDie Pipeline l\u00e4uft von den Eingabedaten bis zur endg\u00fcltigen Ausgabe.<\/td>\n<\/tr>\n<\/tbody><\/table>\n
    Tests sind besonders n\u00fctzlich, wenn sich Code \u00e4ndert. Ein kleiner Refaktor kann die Ergebnisse versehentlich ver\u00e4ndern. Ein Regressionstest kann Sie warnen, wenn sich eine \u00c4nderung auf die zuvor vertrauensw\u00fcrdige Ausgabe auswirkt.<\/p>\n
    Behandeln Sie Daten als Teil des Codebase-Workflows<\/h2>\n
    Der wissenschaftliche Code h\u00e4ngt in der Regel stark von Daten ab. Wenn der Daten-Workflow unklar ist, sind die Ergebnisse auch dann schwer zu reproduzieren, wenn der Code verf\u00fcgbar ist.<\/p>\n
    Rohdaten sollten nach M\u00f6glichkeit erhalten bleiben. Bearbeiten Sie die Originaldateien nicht manuell, ohne aufzuzeichnen, was sich ge\u00e4ndert hat. Wenn Daten bereinigt oder transformiert werden m\u00fcssen, dokumentieren Sie die Schritte und behalten Sie den Verarbeitungscode.<\/p>\n
    Datensatzversionen verfolgen. Zeichnen Sie auf, woher die Daten stammen, wann sie heruntergeladen oder gesammelt wurden, welche Ausschl\u00fcsse angewendet wurden, wie fehlende Werte behandelt wurden und welche verarbeitete Datei f\u00fcr jedes Ergebnis verwendet wurde.<\/p>\n
    Bei wichtigen Dateien k\u00f6nnen Pr\u00fcfsummen oder Manifeste helfen, zu best\u00e4tigen, dass sich die Daten nicht unerwartet ge\u00e4ndert haben. Dies ist besonders n\u00fctzlich, wenn Sie mit gro\u00dfen Datens\u00e4tzen, gemeinsam genutztem Speicher oder lang laufenden Projekten arbeiten.<\/p>\n
    Vermeiden Sie nur Notebook-Forschungspipelines<\/h2>\n
    Notebooks sind n\u00fctzlich f\u00fcr die Erforschung, Visualisierung und Erkl\u00e4rung. Sie erm\u00f6glichen es Forschern, Code, Text, Diagramme und Ergebnisse an einem Ort zu kombinieren. Notebooks k\u00f6nnen jedoch schwierig zu warten werden, wenn sie die gesamte Forschungspipeline halten.<\/p>\n
    H\u00e4ufige Probleme mit dem Notebook sind auslaufende Zellen, versteckter Zustand, unklare Abh\u00e4ngigkeiten, wiederholter Code, gemischte Analyse- und Produktionslogik und Schwierigkeitstestfunktionen.<\/p>\n
    Ein besserer Ansatz besteht darin, Notebooks f\u00fcr die Erforschung und Kommunikation zu verwenden und stabile Funktionen in wiederverwendbare Quelldateien zu verschieben. Notebooks sollten getesteten Code aufrufen, anstatt alle wichtigen Logiken selbst zu enthalten.<\/p>\n
    Bevor Sie ein Notebook freigeben oder archivieren, starten Sie es neu und f\u00fchren Sie alle Zellen von oben nach unten aus. Dies hilft zu best\u00e4tigen, dass das Notebook nicht vom versteckten Zustand fr\u00fcherer Experimente abh\u00e4ngt.<\/p>\n
    Verwenden Sie nach M\u00f6glichkeit Code-Reviews oder Peer-Checks<\/h2>\n
    Wissenschaftlicher Kodex profitiert von der \u00dcberpr\u00fcfung. Eine zweite Person kann unklare Annahmen, falsche Einheiten, fragile Pfade, fehlende Validierung, verwirrende Namen oder doppelte Logik bemerken, die der Autor m\u00f6glicherweise \u00fcbersehen kann.<\/p>\n
    Die \u00dcberpr\u00fcfung des Codes in der Forschung muss nicht formell oder einsch\u00fcchternd sein. Schon ein kurzer Peer-Check kann die Zuverl\u00e4ssigkeit verbessern. Ein Mitarbeiter kann eine Datenreinigungsfunktion, eine Modellimplementierung, eine statistische Berechnung oder das Skript \u00fcberpr\u00fcfen, das endg\u00fcltige Zahlen generiert.<\/p>\n
    Das Ziel ist keine Kritik. Ziel ist es, die Forschung vor vermeidbaren Fehlern zu sch\u00fctzen. Die wissenschaftliche Arbeit wird st\u00e4rker, wenn wichtiger Code f\u00fcr jemand anderen einfacher zu inspizieren ist.<\/p>\n
    Experimente und Ergebnisse klar protokollieren<\/h2>\n
    Bei wissenschaftlichen Projekten handelt es sich h\u00e4ufig um viele L\u00e4ufe mit unterschiedlichen Parametern, Datens\u00e4tzen, zuf\u00e4lligen Samen oder Modelleinstellungen. Ohne klare Protokollierung wird es schwierig zu wissen, welcher Lauf erzeugt wird.<\/p>\n
    N\u00fctzliche Versuchsprotokolle k\u00f6nnen sein:<\/p>\n
      \n
    • Datum und Uhrzeit<\/li>\n
    • Code-Version<\/li>\n
    • Datensatzversion<\/li>\n
    • Rahmen<\/li>\n
    • Zuf\u00e4lliger Samen<\/li>\n
    • Software-Umgebung<\/li>\n
    • Ausgabeort<\/li>\n
    • Erfolg oder Fehlerstatus<\/li>\n
    • Kurze Hinweise zu \u00c4nderungen<\/li>\n<\/ul>\n
      Zuf\u00e4llige Samen sind besonders wichtig bei Simulationen, maschinellem Lernen, Probenahme und stochastischen Modellen. Die Aufzeichnung hilft dabei, die Ergebnisse zu reproduzieren und zu debuggen.<\/p>\n
      Fehler und Randf\u00e4lle explizit behandeln<\/h2>\n
      Beim wissenschaftlichen Rechnen k\u00f6nnen stille Ausf\u00e4lle schlimmer sein als sichtbare Fehler. Ein deutlich abst\u00fcrztes Skript ist leichter zu reparieren als ein Skript, das leise zu falschen Ergebnissen f\u00fchrt.<\/p>\n
      Validieren Sie die Eingaben, bevor Sie wichtige Berechnungen ausf\u00fchren. \u00dcberpr\u00fcfen Sie Einheiten, Bereiche, Dimensionen, fehlende Werte, Dateiexistenz und Annahmen \u00fcber die Daten. Wenn eine kritische Annahme fehlschl\u00e4gt, sollte die Pipeline klar anhalten oder warnen.<\/p>\n
      Fehlermeldungen sollten sinnvoll sein. Eine Nachricht wie Eingabedatei fehlt: Erwartete Daten \/ verarbeitete Daten \/ Clean_sample.csv <\/strong> ist viel n\u00fctzlicher als ein generischer Absturz.<\/p>\n
      Eine gute Fehlerbehandlung sch\u00fctzt die Forschungsintegrit\u00e4t, da falsche Annahmen davon abgehalten werden, sich leise in die endg\u00fcltigen Ergebnisse zu bewegen.<\/p>\n
      \u00dcbergabe und Langzeitnutzung planen<\/h2>\n
      Der wissenschaftliche Code \u00fcberlebt oft die Person, die ihn geschrieben hat. Ein Student absolviert. Ein Postdoc geht. Ein Mitarbeiter tritt sp\u00e4ter bei. Ein Labor m\u00f6chte eine Pipeline f\u00fcr ein neues Projekt wiederverwenden. Die Planung der \u00dcbergabe erleichtert diesen \u00dcbergang.<\/p>\n
      Ein wartbares Projekt sollte ein Setup-Handbuch, Beispiel-Ein- und Ausgabe, bekannte Einschr\u00e4nkungen, Workflow-Beschreibung, Issue-Tracker, Lizenz-, Zitierinformationen und archivierte Freigabe f\u00fcr ver\u00f6ffentlichte Arbeiten enthalten.<\/p>\n
      Es ist auch n\u00fctzlich, eine kurze Erl\u00e4uterung zu enthalten, was der Code nicht tut. Einschr\u00e4nkungen sind Teil der verantwortungsvollen Dokumentation. Sie helfen zuk\u00fcnftigen Benutzern zu vermeiden, den Code auf eine Weise anzuwenden, f\u00fcr die er nicht entwickelt wurde.<\/p>\n
      H\u00e4ufige Fehler zu vermeiden<\/h2>\n
      Alles in einem Skript behalten<\/h3>\n
      Ein gro\u00dfes Skript kann schnell geschrieben werden, aber es wird schwer zu lesen, zu testen, zu debuggen und wiederzuverwenden. Unterbrechen Sie stabile Logik in Funktionen und Module.<\/p>\n
      Daten manuell \u00e4ndern, ohne sie aufzuzeichnen<\/h3>\n
      Manuelle Bearbeitungen erschweren die Reproduzierbarkeit. Wenn sich Daten \u00e4ndern, sollte die \u00c4nderung dokumentiert oder \u00fcber ein Skript durchgef\u00fchrt werden.<\/p>\n
      Abh\u00e4ngig von nicht spezifizierten Softwareversionen<\/h3>\n
      Wenn Abh\u00e4ngigkeiten nicht aufgezeichnet werden, kann ein anderer Benutzer neuere Versionen installieren und unterschiedliche Ergebnisse oder Fehler erhalten.<\/p>\n
      Tests als unn\u00f6tig behandeln<\/h3>\n
      Wissenschaftlicher Code kann schwerwiegende Fehler enthalten, selbst wenn er erfolgreich ausgef\u00fchrt wird. Tests sch\u00fctzen kritische Berechnungen und Workflows.<\/p>\n
      Nur am Ende dokumentieren<\/h3>\n
      Wichtige Details werden oft am Ende eines Projekts vergessen. Dokumentieren Sie Annahmen, Parameter und Workflow-Entscheidungen, wie das Projekt entwickelt.<\/p>\n
      Letzte Gedanken: Wartbarer Code erleichtert das Vertrauen der Wissenschaft<\/h2>\n
      Maintaining scientific code is not about making research slower. Es geht darum, die Forschung leichter zu verstehen, zu wiederholen, zu \u00fcberpr\u00fcfen und zu erweitern. Ein Projekt mit klarer Struktur, Versionskontrolle, Dokumentation, Tests, reproduzierbaren Umgebungen und sorgf\u00e4ltiger Datenverarbeitung ist zuverl\u00e4ssiger als ein Projekt mit Speicher und verstreuten Dateien.<\/p>\n
      Gute Wartungspraktiken m\u00fcssen nicht \u00fcbertrieben sein. Beginnen Sie mit den Grundlagen: Namen l\u00f6schen, organisierte Ordner, Readme, Versionskontrolle, aufgezeichnete Abh\u00e4ngigkeiten, einfache Tests und dokumentierte Datenschritte. Diese Gewohnheiten schaffen eine Grundlage, die sowohl die Software als auch die darauf basierende Forschung sch\u00fctzt.<\/p>\n
      Der wissenschaftliche Kodex ist Teil der Beweise f\u00fcr wissenschaftliche Behauptungen. Wenn es gut aufrechterhalten wird, werden die Ergebnisse leichter zu vertrauen und die zuk\u00fcnftige Arbeit leichter zu bauen.<\/p>\n"},"excerpt":{"rendered":"
      Reading Time: <\/span>  8<\/span> minutes<\/span><\/span>Wissenschaftlicher Code beginnt oft als schnelles Skript. Ein Forscher muss einen Datensatz bereinigen, eine Simulation ausf\u00fchren, ein Modell testen, eine Zahl generieren oder eine Hypothese \u00fcberpr\u00fcfen. Der Code kann zun\u00e4chst f\u00fcr eine Person und eine unmittelbare Aufgabe geschrieben werden. Im Laufe der Zeit kann dasselbe Skript Teil eines ver\u00f6ffentlichten Papiers, einer Dissertation, eines Labor-Workflows, eines […]<\/p>\n","protected":false,"raw":""},"author":3,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_locale":"de_DE","_original_post":"https:\/\/matforge.org\/?p=320","iawp_total_views":0,"footnotes":""},"categories":[2],"tags":[],"class_list":["post-830","post","type-post","status-publish","format-standard","hentry","category-fipy-documentation-examples-development","de-DE"],"yoast_head":"\nBest Practices for Maintaining Scientific Code<\/title>\n<meta name=\"description\" content=\"Erfahren Sie Best Practices f\u00fcr die Aufrechterhaltung des wissenschaftlichen Codes, einschlie\u00dflich Projektstruktur, Versionskontrolle, Dokumentation, Tests, reproduzierbare Umgebungen, Datenmanagement und Forschungsworkflows.\" \/>\n<meta name=\"robots\" content=\"index, follow, max-snippet:-1, max-image-preview:large, max-video-preview:-1\" \/>\n<link rel=\"canonical\" href=\"https:\/\/matforge.org\/de\/best-practices-for-maintaining-scientific-code\/\" \/>\n<meta property=\"og:locale\" content=\"de_DE\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"Best Practices for Maintaining Scientific Code\" \/>\n<meta property=\"og:description\" content=\"Erfahren Sie Best Practices f\u00fcr die Aufrechterhaltung des wissenschaftlichen Codes, einschlie\u00dflich Projektstruktur, Versionskontrolle, Dokumentation, Tests, reproduzierbare Umgebungen, Datenmanagement und Forschungsworkflows.\" \/>\n<meta property=\"og:url\" content=\"https:\/\/matforge.org\/de\/best-practices-for-maintaining-scientific-code\/\" \/>\n<meta property=\"og:site_name\" content=\"matforge.org\" \/>\n<meta property=\"article:published_time\" content=\"2026-07-30T12:22:30+00:00\" \/>\n<meta name=\"author\" content=\"Tomas Delgado\" \/>\n<meta name=\"twitter:card\" content=\"summary_large_image\" \/>\n<meta name=\"twitter:label1\" content=\"Verfasst von\" \/>\n\t<meta name=\"twitter:data1\" content=\"Tomas Delgado\" \/>\n\t<meta name=\"twitter:label2\" content=\"Gesch\u00e4tzte Lesezeit\" \/>\n\t<meta name=\"twitter:data2\" content=\"12\u00a0Minuten\" \/>\n<script type=\"application\/ld+json\" class=\"yoast-schema-graph\">{\"@context\":\"https:\\\/\\\/schema.org\",\"@graph\":[{\"@type\":\"Article\",\"@id\":\"https:\\\/\\\/matforge.org\\\/de\\\/best-practices-for-maintaining-scientific-code\\\/#article\",\"isPartOf\":{\"@id\":\"https:\\\/\\\/matforge.org\\\/de\\\/best-practices-for-maintaining-scientific-code\\\/\"},\"author\":{\"name\":\"Tomas Delgado\",\"@id\":\"https:\\\/\\\/matforge.org\\\/#\\\/schema\\\/person\\\/518cdd1f18dd092f4ed738d68e540061\"},\"headline\":\"Best Practices for Maintaining Scientific Code\",\"datePublished\":\"2026-07-30T12:22:30+00:00\",\"mainEntityOfPage\":{\"@id\":\"https:\\\/\\\/matforge.org\\\/de\\\/best-practices-for-maintaining-scientific-code\\\/\"},\"wordCount\":2340,\"commentCount\":0,\"articleSection\":[\"FIPY: Dokumentation, Beispiele & Entwicklung\"],\"inLanguage\":\"de\",\"potentialAction\":[{\"@type\":\"CommentAction\",\"name\":\"Comment\",\"target\":[\"https:\\\/\\\/matforge.org\\\/de\\\/best-practices-for-maintaining-scientific-code\\\/#respond\"]}]},{\"@type\":\"WebPage\",\"@id\":\"https:\\\/\\\/matforge.org\\\/de\\\/best-practices-for-maintaining-scientific-code\\\/\",\"url\":\"https:\\\/\\\/matforge.org\\\/de\\\/best-practices-for-maintaining-scientific-code\\\/\",\"name\":\"Best Practices for Maintaining Scientific Code\",\"isPartOf\":{\"@id\":\"https:\\\/\\\/matforge.org\\\/#website\"},\"datePublished\":\"2026-07-30T12:22:30+00:00\",\"author\":{\"@id\":\"https:\\\/\\\/matforge.org\\\/#\\\/schema\\\/person\\\/518cdd1f18dd092f4ed738d68e540061\"},\"description\":\"Erfahren Sie Best Practices f\u00fcr die Aufrechterhaltung des wissenschaftlichen Codes, einschlie\u00dflich Projektstruktur, Versionskontrolle, Dokumentation, Tests, reproduzierbare Umgebungen, Datenmanagement und Forschungsworkflows.\",\"breadcrumb\":{\"@id\":\"https:\\\/\\\/matforge.org\\\/de\\\/best-practices-for-maintaining-scientific-code\\\/#breadcrumb\"},\"inLanguage\":\"de\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"https:\\\/\\\/matforge.org\\\/de\\\/best-practices-for-maintaining-scientific-code\\\/\"]}]},{\"@type\":\"BreadcrumbList\",\"@id\":\"https:\\\/\\\/matforge.org\\\/de\\\/best-practices-for-maintaining-scientific-code\\\/#breadcrumb\",\"itemListElement\":[{\"@type\":\"ListItem\",\"position\":1,\"name\":\"Home\",\"item\":\"https:\\\/\\\/matforge.org\\\/de\\\/\"},{\"@type\":\"ListItem\",\"position\":2,\"name\":\"Best Practices for Maintaining Scientific Code\"}]},{\"@type\":\"WebSite\",\"@id\":\"https:\\\/\\\/matforge.org\\\/#website\",\"url\":\"https:\\\/\\\/matforge.org\\\/\",\"name\":\"matforge.org\",\"description\":\"\",\"potentialAction\":[{\"@type\":\"SearchAction\",\"target\":{\"@type\":\"EntryPoint\",\"urlTemplate\":\"https:\\\/\\\/matforge.org\\\/?s={search_term_string}\"},\"query-input\":{\"@type\":\"PropertyValueSpecification\",\"valueRequired\":true,\"valueName\":\"search_term_string\"}}],\"inLanguage\":\"de\"},{\"@type\":\"Person\",\"@id\":\"https:\\\/\\\/matforge.org\\\/#\\\/schema\\\/person\\\/518cdd1f18dd092f4ed738d68e540061\",\"name\":\"Tomas Delgado\",\"image\":{\"@type\":\"ImageObject\",\"inLanguage\":\"de\",\"@id\":\"https:\\\/\\\/secure.gravatar.com\\\/avatar\\\/202f82c9f4f4534a3ba77bf8a8fbef09cf8489f52bdf819082f21390da4e7c9a?s=96&d=mm&r=g\",\"url\":\"https:\\\/\\\/secure.gravatar.com\\\/avatar\\\/202f82c9f4f4534a3ba77bf8a8fbef09cf8489f52bdf819082f21390da4e7c9a?s=96&d=mm&r=g\",\"contentUrl\":\"https:\\\/\\\/secure.gravatar.com\\\/avatar\\\/202f82c9f4f4534a3ba77bf8a8fbef09cf8489f52bdf819082f21390da4e7c9a?s=96&d=mm&r=g\",\"caption\":\"Tomas Delgado\"},\"sameAs\":[\"http:\\\/\\\/matforge.org\"],\"url\":\"https:\\\/\\\/matforge.org\\\/author\\\/tomas-delgado\\\/\"}]}<\/script>\n<!-- \/ Yoast SEO plugin. -->","yoast_head_json":{"title":"Best Practices for Maintaining Scientific Code","description":"Erfahren Sie Best Practices f\u00fcr die Aufrechterhaltung des wissenschaftlichen Codes, einschlie\u00dflich Projektstruktur, Versionskontrolle, Dokumentation, Tests, reproduzierbare Umgebungen, Datenmanagement und Forschungsworkflows.","robots":{"index":"index","follow":"follow","max-snippet":"max-snippet:-1","max-image-preview":"max-image-preview:large","max-video-preview":"max-video-preview:-1"},"canonical":"https:\/\/matforge.org\/de\/best-practices-for-maintaining-scientific-code\/","og_locale":"de_DE","og_type":"article","og_title":"Best Practices for Maintaining Scientific Code","og_description":"Erfahren Sie Best Practices f\u00fcr die Aufrechterhaltung des wissenschaftlichen Codes, einschlie\u00dflich Projektstruktur, Versionskontrolle, Dokumentation, Tests, reproduzierbare Umgebungen, Datenmanagement und Forschungsworkflows.","og_url":"https:\/\/matforge.org\/de\/best-practices-for-maintaining-scientific-code\/","og_site_name":"matforge.org","article_published_time":"2026-07-30T12:22:30+00:00","author":"Tomas Delgado","twitter_card":"summary_large_image","twitter_misc":{"Verfasst von":"Tomas Delgado","Gesch\u00e4tzte Lesezeit":"12\u00a0Minuten"},"schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":"Article","@id":"https:\/\/matforge.org\/de\/best-practices-for-maintaining-scientific-code\/#article","isPartOf":{"@id":"https:\/\/matforge.org\/de\/best-practices-for-maintaining-scientific-code\/"},"author":{"name":"Tomas Delgado","@id":"https:\/\/matforge.org\/#\/schema\/person\/518cdd1f18dd092f4ed738d68e540061"},"headline":"Best Practices for Maintaining Scientific Code","datePublished":"2026-07-30T12:22:30+00:00","mainEntityOfPage":{"@id":"https:\/\/matforge.org\/de\/best-practices-for-maintaining-scientific-code\/"},"wordCount":2340,"commentCount":0,"articleSection":["FIPY: Dokumentation, Beispiele & Entwicklung"],"inLanguage":"de","potentialAction":[{"@type":"CommentAction","name":"Comment","target":["https:\/\/matforge.org\/de\/best-practices-for-maintaining-scientific-code\/#respond"]}]},{"@type":"WebPage","@id":"https:\/\/matforge.org\/de\/best-practices-for-maintaining-scientific-code\/","url":"https:\/\/matforge.org\/de\/best-practices-for-maintaining-scientific-code\/","name":"Best Practices for Maintaining Scientific Code","isPartOf":{"@id":"https:\/\/matforge.org\/#website"},"datePublished":"2026-07-30T12:22:30+00:00","author":{"@id":"https:\/\/matforge.org\/#\/schema\/person\/518cdd1f18dd092f4ed738d68e540061"},"description":"Erfahren Sie Best Practices f\u00fcr die Aufrechterhaltung des wissenschaftlichen Codes, einschlie\u00dflich Projektstruktur, Versionskontrolle, Dokumentation, Tests, reproduzierbare Umgebungen, Datenmanagement und Forschungsworkflows.","breadcrumb":{"@id":"https:\/\/matforge.org\/de\/best-practices-for-maintaining-scientific-code\/#breadcrumb"},"inLanguage":"de","potentialAction":[{"@type":"ReadAction","target":["https:\/\/matforge.org\/de\/best-practices-for-maintaining-scientific-code\/"]}]},{"@type":"BreadcrumbList","@id":"https:\/\/matforge.org\/de\/best-practices-for-maintaining-scientific-code\/#breadcrumb","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https:\/\/matforge.org\/de\/"},{"@type":"ListItem","position":2,"name":"Best Practices for Maintaining Scientific Code"}]},{"@type":"WebSite","@id":"https:\/\/matforge.org\/#website","url":"https:\/\/matforge.org\/","name":"matforge.org","description":"","potentialAction":[{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https:\/\/matforge.org\/?s={search_term_string}"},"query-input":{"@type":"PropertyValueSpecification","valueRequired":true,"valueName":"search_term_string"}}],"inLanguage":"de"},{"@type":"Person","@id":"https:\/\/matforge.org\/#\/schema\/person\/518cdd1f18dd092f4ed738d68e540061","name":"Tomas Delgado","image":{"@type":"ImageObject","inLanguage":"de","@id":"https:\/\/secure.gravatar.com\/avatar\/202f82c9f4f4534a3ba77bf8a8fbef09cf8489f52bdf819082f21390da4e7c9a?s=96&d=mm&r=g","url":"https:\/\/secure.gravatar.com\/avatar\/202f82c9f4f4534a3ba77bf8a8fbef09cf8489f52bdf819082f21390da4e7c9a?s=96&d=mm&r=g","contentUrl":"https:\/\/secure.gravatar.com\/avatar\/202f82c9f4f4534a3ba77bf8a8fbef09cf8489f52bdf819082f21390da4e7c9a?s=96&d=mm&r=g","caption":"Tomas Delgado"},"sameAs":["http:\/\/matforge.org"],"url":"https:\/\/matforge.org\/author\/tomas-delgado\/"}]}},"_links":{"self":[{"href":"https:\/\/matforge.org\/wp-json\/wp\/v2\/posts\/830","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/matforge.org\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/matforge.org\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/matforge.org\/wp-json\/wp\/v2\/users\/3"}],"replies":[{"embeddable":true,"href":"https:\/\/matforge.org\/wp-json\/wp\/v2\/comments?post=830"}],"version-history":[{"count":1,"href":"https:\/\/matforge.org\/wp-json\/wp\/v2\/posts\/830\/revisions"}],"predecessor-version":[{"id":978,"href":"https:\/\/matforge.org\/wp-json\/wp\/v2\/posts\/830\/revisions\/978"}],"wp:attachment":[{"href":"https:\/\/matforge.org\/wp-json\/wp\/v2\/media?parent=830"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/matforge.org\/wp-json\/wp\/v2\/categories?post=830"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/matforge.org\/wp-json\/wp\/v2\/tags?post=830"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}