Entscheidungen, die sich verteidigen lassen
Software für die Stundenplanung scheitert auf bestimmte, wiedererkennbare Weise. Das hier sind die Entscheidungen dagegen. Jede ist eine Regel, auf der dieser Quellcode wirklich aufbaut, und kein Slogan.
- Warnen, nie blockieren
- Wer einen Stundenplan bearbeitet, weiß meist etwas, das die Regeln nicht wissen. Deshalb ist eine Änderung erlaubt, die eine harte Regel verletzt, und der Verstoß wird zu abfragbarem Zustand am Stundenplan. Nächste Woche noch auffindbar, und keine Meldung, die Sie weggeklickt haben.
- Verschachtelte Gruppen kollidieren wirklich
- Ein Termin für einen Studiengang blockiert dessen Jahrgänge, und ein Termin für einen Jahrgang blockiert den Studiengang. Die Kollisionsprüfung geht die gesamte Verwandtschaft nach oben und nach unten durch, über eine gepflegte transitive Hülle, statt nur die zwei Namen zu vergleichen, die ihr übergeben wurden.
- Trennung in der Datenbank, nicht im Code
- Jede institutionsbezogene Tabelle ist durch Row-Level-Security geschützt, und die Anwendung verbindet sich mit einer Rolle, die nichts besitzt. Ein Fehler führt dazu, dass man keine Zeilen sieht, und das fällt auf – nicht dazu, dass man die von jemand anderem sieht, und das fällt nicht auf.
- Nichts an der Zeit ist fest verdrahtet
- Tage pro Woche, Blöcke pro Tag, Blocklänge und die ungleichen Pausen zwischen den Blöcken kommen aus dem Zeitraster der jeweiligen Institution. Es gibt kein angenommenes Montag bis Freitag und nirgends eine Ersatzform. Eine Institution ohne Zeitraster bekommt eine leere Ansicht, keine Vermutung.
- Jede Änderung ist ein Ereignis
- Anlegen, Verschieben, Tauschen, Löschen und Fixieren werden an ein Protokoll angehängt, aufsetzend auf dem Planvorschlag, von dem sie ausgingen, samt der Person, die es getan hat. Für das Zurücklesen dieser Historie gibt es noch keine Ansicht. Das Protokoll wird ordentlich geführt, bevor es etwas gibt, das es anzeigt.