Wie Software entsteht
Vom ersten Befehl bis zum Update auf dem Gerät – die Stationen, die fast jedes Programm durchläuft. Sie gelten für ein kleines Werkzeug genauso wie für ein Betriebssystem. Am Ende steht, wie Aerona sie selbst durchläuft und welche Regeln dafür gelten.
Der Weg eines Programms
| Station | was passiert |
|---|---|
| Quellcode | Menschen schreiben Befehle in einer Programmiersprache – als Text in Dateien. Diesen Text kann jeder lesen, der die Sprache kennt; der Rechner kann ihn so meist noch nicht ausführen. |
| Versionsverwaltung | Jede Änderung wird festgehalten, mit Datum und Grund. Man kann jederzeit zurück. Wer später fragt, warum eine Zeile so aussieht, findet dort die Antwort. |
| Prüfen | Prüfreihen führen den Code automatisch aus und vergleichen das Ergebnis mit dem erwarteten. Sie laufen nach jeder Änderung, nicht nur einmal am Ende. |
| Bauen | Aus dem Quellcode wird ein lauffähiges Programm – übersetzt, gebündelt, verpackt. Was dabei herauskommt, ist das, was später auf dem Gerät läuft, und nicht mehr der Text von oben. |
| Veröffentlichen | Das Programm kommt als Datei zum Herunterladen, in einen Store oder als Update auf die Geräte. Ab hier kann ein Fehler Menschen treffen, die mit dem Bau nichts zu tun haben. |
| Fehler beheben | Nutzer finden, was die Prüfungen übersehen haben. Eine Korrektur beginnt den Weg von vorn. Gute Teams schreiben dabei für den gefundenen Fehler einen neuen Prüffall, damit er nicht wiederkommt. |
Was eine Prüfreihe tut
Eine Prüfreihe ist ein Programm, das ein anderes Programm prüft. Sie gibt ihm Eingaben, deren richtiges Ergebnis man vorher kennt, und vergleicht. So läuft das Schritt für Schritt:
- Einen Fall aufschreiben. Eingabe und erwartetes Ergebnis, zum Beispiel: „Aus 2 + 3 soll 5 werden.“ Das Ergebnis muss man vorher kennen – sonst prüft die Reihe nur, ob der Code irgendetwas ausgibt.
- Ausführen. Die Prüfreihe ruft den Code mit der Eingabe auf. Das geht in Sekundenbruchteilen, darum kann eine Prüfreihe Hunderte Fälle in einem Zug prüfen.
- Vergleichen. Stimmt das Ergebnis, gilt der Fall als bestanden. Sonst nennt sie den Fall, das erwartete und das tatsächliche Ergebnis. Eine Meldung wie „3 Fehler“ ohne Einzelheiten hilft kaum, eine mit Fall und Ergebnis zeigt direkt die Stelle.
- Nach jeder Änderung wiederholen. Eine Korrektur an einer Stelle kann eine andere Stelle kaputt machen. Das merkt man nur, wenn alle alten Fälle wieder laufen.
Bei Aerona: Am 12.09.2026 wurde eine Datei mit zwei Regeln der englischen Grammatikprüfung aus Versehen überschrieben. Aufgefallen ist das nur, weil die Prüfreihe sieben Fälle einzeln als falsch meldete. Die Datei war noch nicht in der Versionsverwaltung – gerettet hat sie nur ein alter Gesprächsverlauf, und vier Einträge fehlten trotzdem. Wie die Webseite vor jeder Veröffentlichung geprüft wird, steht auf Wie Aerona sich selbst prüft.
Die wichtigsten Begriffe
Git
Die verbreitetste Versionsverwaltung, 2005 von Linus Torvalds geschrieben. Eine festgehaltene Änderung heißt Commit. Jeder Commit kennt seinen Vorgänger, so entsteht eine lückenlose Kette bis zum ersten Tag.
Abhängigkeiten
Fertige Bausteine anderer, die ein Programm mitbenutzt. Sie sparen Arbeit – und bringen deren Fehler mit. Oft hat ein Baustein selbst wieder Bausteine, und am Ende hängt ein Programm an Code, den niemand im Team je gelesen hat.
Versionsnummern
Oft drei Zahlen, etwa 2.4.1: Die erste wächst bei großen Änderungen, die zweite bei neuen Funktionen, die dritte bei Fehlerbehebungen. Das Muster heißt Semantic Versioning. Wer die Nummer liest, weiß so, ob ein Update nur repariert oder etwas Grundlegendes ändert.
Compiler
Ein Programm, das Quellcode in Maschinencode übersetzt, den der Prozessor direkt versteht. Manche Sprachen werden stattdessen während des Laufens Stück für Stück ausgeführt, etwa JavaScript im Browser. AetherOS hat für seine eigene Sprache .ae einen eigenen Compiler – mehr dazu unter Programmieren mit .ae.
Fehler (Bug)
Ein Programm tut etwas anderes, als es soll. Die Ursache zu finden dauert meist länger, als sie zu beheben. Am schwersten sind Fehler, die nichts melden: Das Programm läuft weiter und tut still das Falsche.
Technische Schulden
Abkürzungen von heute, die später Arbeit kosten – etwa zu lange Dateien oder doppelter Code. Wie bei echten Schulden wachsen die Zinsen: Jede weitere Änderung an solchem Code dauert länger als die vorige.
Bei Aerona: Die Webseite trägt heute die Version 9.0.0. Die Nummer steht in genau einer Datei, und jede Stelle der Seite holt sie sich dort ab. Stünde sie an zehn Stellen, stünden dort irgendwann drei verschiedene – wie beim Zähldatum auf „Aerona in Zahlen“, das einmal im Markup, einmal im Text und einmal in den Zahlen stand, jedes Mal anders.
Eine Änderung festhalten
Zu jedem Commit gehört eine kurze Nachricht, die sagt, was sich geändert hat. Das Aerona-Regelwerk gibt dafür ein Muster vor: deutsch, mit einem Typ in eckigen Klammern vorne. Wer später die lange Liste der Commits durchsieht, erkennt am Typ sofort, ob etwas repariert, neu gebaut oder nur umgeräumt wurde.
| Typ | wofür |
|---|---|
| [Feat] | eine neue Funktion |
| [Fix] | ein Fehler ist repariert |
| [Refactor] | Code umgebaut, ohne neue Funktion |
| [UI] | Design, CSS oder Stile |
| [Docs] | Dokumentation oder Kommentare |
| [Translate] | Übersetzungen |
| [Perf] | bessere Leistung |
Ein Beispiel aus dem Regelwerk: „[Fix] Button-Farbe im Dark Mode korrigiert“. Wird mit KI gebaut, schlägt die KI die Nachricht vor, committet aber nicht ungefragt – außer beim Sicherungs-Commit vor einem Umbau.
Vor jedem größeren Umbau verlangt das Regelwerk zuerst einen Sicherungs-Commit. Dass Git überhaupt Pflicht ist, hat einen Grund: Am 20.07.2026 ist ein Ordner ohne Versionsverwaltung spurlos verschwunden. Mit Git wäre das laut Regelwerk ein Fünf-Sekunden-Restore gewesen.
Was festgehalten wird – und was nicht
Nicht jede Datei gehört in die Versionsverwaltung. Eine Datei namens „.gitignore“ sagt Git, was es übergehen soll. Die Faustregel: Festgehalten wird, was ein Mensch geschrieben hat. Was sich jederzeit neu erzeugen oder herunterladen lässt, bleibt draußen – und was geheim ist, sowieso.
Wird festgehalten
- Quellcode
- Regeln und Konfiguration
- Dokumentation
Bleibt draußen
- heruntergeladene Bausteine anderer
- fertig gebaute Dateien, ISO-Abbilder und Installer
- Protokolle
- .env-Dateien und private Signierschlüssel
So steht es im Aerona-Regelwerk. Konfiguration gilt dort als genauso wertvoll wie Code. Ordner und Dateien werden mit Git verschoben, nicht gelöscht und neu angelegt, damit ihre Geschichte an ihnen hängen bleibt.
Wenn ein Programm abstürzt
Viele Programme melden Abstürze von selbst an ihren Hersteller. Aerona verzichtet darauf, denn Regel 27 verbietet Telemetrie. Das schafft eine Lücke: Wenn nichts nach Hause funkt, weiß niemand, was passiert ist. Deshalb legt das Regelwerk fest, wie ein Absturz beim Nutzer ablaufen soll – in genau dieser Reihenfolge.
„Wer keine Daten sammelt, muss dem Nutzer umso besser helfen, sie selbst weiterzugeben.“
Aerona-Regel 30, Wenn es beim Nutzer bricht
- Retten. Was noch im Speicher liegt, kommt auf die Platte – neben das Original, nie darüber. Beim nächsten Start bietet das Programm einmal an, den Stand zurückzuholen.
- Erklären. Ein Satz, was passiert ist, und einer, was mit der Arbeit ist. Das ist die erste Frage, die ein Mensch nach einem Absturz hat, und ein roher Fehlertext beantwortet sie nicht.
- Einen Ausweg anbieten. Neu starten, mit Standardwerten starten oder den Bericht ansehen. Der technische Teil ist da, aber eingeklappt.
- Mitschreiben. In ein lesbares Protokoll auf dem eigenen Gerät – ohne Namen, E-Mail-Adressen oder Passwörter. Alte Einträge fallen hinten heraus, damit es nicht endlos wächst.
- Weitergeben anbieten. Der Bericht wird als Datei gespeichert. Weitergeben kann ihn nur der Nutzer selbst, nachdem er gesehen hat, was darin steht.
Genau an dieser Stelle verbietet das Regelwerk jedes Augenzwinkern. Bei einem Absturz ist etwas verloren gegangen. Die Programme, für die das gilt, sind noch nicht erschienen; was hier steht, ist die Vorgabe, nach der sie gebaut werden.
Und bei Aerona?
Git ist Pflicht
Jedes Projekt ist ein Git-Repository, ohne Ausnahme. Vor jedem größeren Umbau kommt zuerst ein Sicherungs-Commit, nach jeder funktionierenden Änderung ein weiterer. Der Grund steht oben unter „Eine Änderung festhalten“.
300 Zeilen
Keine Quelldatei soll mehr als 300 Zeilen haben – damit sie lesbar und prüfbar bleibt. Das ist kein Vorschlag, sondern eine Grenze; ein Wächter meldet sie schon beim Schreiben. Nur wo Zerlegen verwobenen Code zerbrechen würde, gibt es eine dokumentierte Ausnahme.
Archiv statt Löschen
Was nicht mehr gebraucht wird, kommt ins Archiv. Vor dem Löschen steht der Beweis, dass etwas wirklich tot ist. Manche Dateien sehen nur wie Kopien aus: Im Betriebssystem bilden 253 scheinbare Duplikate eine Kette, und wer sie löscht, verliert Funktionen.
Das Bautagebuch
Jeder sichtbare Schritt wird aufgeschrieben – daraus entstehen die Änderungsberichte. Ein Wächter meldet am Ende einer Arbeitssitzung, wenn gebaut, aber nichts eingetragen wurde. Wie die Werkzeuge dahinter arbeiten, steht auf Wie Aerona sich selbst prüft.
Fremde Bausteine
Auch in Aerona stecken fremde Bausteine, etwa React, Electron und Vite. Bevor ein neues Paket dazukommt, verlangt Regel 29 fünf Antworten: Geht es auch ohne? Läuft es offline? Was wiegt es im Startweg? Welche Lizenz hat es? Wird es gepflegt? Dazu gilt: Nichts wird zur Laufzeit aus dem Netz geholt. Neben jedem fremden Teil liegen seine Lizenz und ein Vermerk, woher es stammt. Welche Bausteine die Apps benutzen, steht bei der App Engine. Die fremden Symbole der Webseite nennt die Rechtsseite.
Das ganze Regelwerk
Alle Regeln, nach denen gebaut wird – 36 Dateien, ein Thema je Datei, mit Git, 300 Zeilen und Absturz darunter.
Web Changelog
Was an der Webseite gebaut wurde, Version für Version – der Weg eines Programms von oben, am Beispiel dieser Webseite.
