Workspace, Build und Entwicklungsumgebung

Workspace, Build und Entwicklungsumgebung

0:00 Der Versionsstand steht, jetzt entsteht das Projekt. Und damit eine Entscheidung, die unscheinbar aussieht und erstaunlich lange nachwirkt: wie die Ordner geschnitten sind. Ich habe Anwendungen gesehen, bei denen ein einzelnes Feature über sieben Verzeichnisse verteilt lag — nicht weil jemand das so wollte, sondern weil am ersten Tag eine Gewohnheit übernommen wurde, die damals bequem war.

0:21 In diesem Modul geht es um den Zuschnitt, um die drei Befehle, die Ihren Alltag tragen, um die saubere Trennung von Umgebungen und um strenge Compileroptionen — die man am besten von Anfang an setzt.

Angular verstehen und eine Anwendung aufbauen

0:32 Wir bleiben an Tag eins und machen aus der Einordnung etwas Greifbares. Am Ende dieses Moduls läuft Spurweite: Entwicklungsserver, Produktionsbau und Testlauf sind einmal durchgelaufen, die Feature-Ordner stehen, und der Compiler ist so streng eingestellt, wie er sein sollte.

Workspace und Projektstruktur

0:48 Beginnen wir mit dem Zuschnitt. Die Frage klingt banal — in welche Ordner kommt der Code? — und ist trotzdem diejenige, über die Sie in zwei Jahren am häufigsten stolpern werden, in die eine oder andere Richtung. Ein Workspace ist erst einmal unspektakulär: eine Konfigurationsdatei, ein Quellverzeichnis, eine Einstiegsdatei. Interessant wird die Frage, was darunter passiert.

1:11 Der Angular Style Guide ist da ungewöhnlich deutlich: Gliedern Sie nach Fachbereichen, nicht nach Dateitypen. Also nicht ein Ordner für alle Komponenten und einer für alle Services, sondern ein Ordner je Thema — Aufträge, Fahrzeuge, Standorte. Sammelordner wie „components" oder „utils" rät er ausdrücklich ab. Dazu ein Konzept je Datei und Bindestriche in Dateinamen.

1:35 Klingt nach Kleinkram, ist aber die Grundlage dafür, dass man Dinge später wiederfindet. Der Unterschied zwischen diesen beiden Spalten zeigt sich nicht beim Anlegen, sondern beim Löschen. Stellen Sie sich vor, ein Feature wird eingestellt — das passiert öfter, als man denkt. Rechts löschen Sie einen Ordner und sind fertig.

1:54 Links gehen Sie durch fünf Verzeichnisse und finden mit ziemlicher Sicherheit nicht alles; Reste bleiben liegen, und in einem Jahr fragt jemand, wofür diese Datei eigentlich da ist. Der zweite Unterschied ist die Zuständigkeit: Bei einer Gliederung nach Fachbereich sieht man, wer für was verantwortlich ist. Bei einer nach Dateityp sieht man das nie.

2:14 Was Sie hier sehen, ist keine Angular-Vorgabe, sondern eine Entscheidung — und sie ist bewusst langweilig. Drei Fachbereiche, die den fachlichen Begriffen der Werkstatt entsprechen: Aufträge, Fahrzeuge, Standorte. Dazu ein geteilter Bereich für Bausteine ohne Fachbezug. Achten Sie auf die Dateinamen: Jede Datei benennt ihre Sache, der Klassenname passt dazu, Worttrennung mit Bindestrich, Tests auf Punkt-spec.

2:39 Nichts davon ist zwingend, aber alles zusammen sorgt dafür, dass jemand, der neu dazukommt, nach zehn Minuten weiß, wo er suchen muss. Der erste Punkt ist eine Prophezeiung, und sie trifft fast immer ein: Ein geteilter Ordner wächst zur Sammelstelle für alles Unzugeordnete. Er beginnt mit drei Dateien und hat nach einem Jahr vierzig, von denen die Hälfte nur an einer Stelle benutzt wird.

3:03 Der zweite: Eine Datei trägt zwei Konzepte, weil sie ohnehin klein ist — und bleibt dann für immer so. Und der dritte ist der, den ich am unangenehmsten finde: generische Namen wie „helpers" oder „utils". Sie verbergen, was darin liegt, und niemand traut sich, darin aufzuräumen.

Entwicklungsserver und Build-System

3:20 Kommen wir zu den Befehlen, die Sie ab jetzt jeden Tag tippen. Es sind erstaunlich wenige — und einer davon wird systematisch zu selten benutzt. Die Angular-Kommandozeile deckt den gesamten Lebenszyklus ab: Projekt anlegen, entwickeln, bauen, testen, Code erzeugen, Pakete hinzufügen, aktualisieren. Sie folgt dabei den üblichen Unix-Konventionen, was den Umgang angenehm vorhersehbar macht — eine boolesche Option schalten Sie mit der Vorsilbe „no" ab, Pfade sind relativ zur Projektwurzel.

3:50 Was tatsächlich gebaut und getestet wird, steht als Ziel je Projekt in der Konfigurationsdatei. Das ist der Ort, an dem Sie nachsehen, wenn sich ein Befehl anders verhält als erwartet. Vier Befehle, und der wichtigste ist der, den man am seltensten benutzt. Der Entwicklungslauf ist Ihr Alltag, klar. Der Testlauf läuft nebenher.

4:11 Aber der Produktionsbau — der wird gern aufgeschoben, weil ja alles läuft. Und genau das ist das Problem, um das es auf der nächsten Folie geht. Achten Sie noch auf den letzten Befehl: Wenn Sie Code erzeugen lassen, geben Sie den Zielpfad mit an. Sonst landet die neue Komponente im Wurzelverzeichnis, und der schöne Zuschnitt von eben hat die erste Lücke.

4:33 Der Produktionsbau ist nicht einfach ein langsamerer Entwicklungslauf — er macht andere Dinge. Er prüft Templates vollständig, wo der Entwicklungslauf toleranter ist. Er entfernt ungenutzten Code und zeigt Ihnen damit erst die tatsächliche Größe dessen, was beim Benutzer ankommt. Und er deckt Abhängigkeiten auf, die nur zufällig im Browser des Entwicklers vorhanden waren. Deshalb gehört er in die Pipeline und nicht nur vor die Auslieferung.

4:58 Die Alternative kennen Sie: Der Bau scheitert zum ersten Mal drei Tage vor dem Termin, und niemand weiß, welche der letzten zweihundert Änderungen es war. Der erste Punkt ist genau das eben beschriebene Muster. Der zweite ist einer, den man leicht übersieht: Die Bauzeit wächst unbemerkt. Von zwanzig Sekunden auf zwei Minuten kommt man nicht an einem Tag, sondern über Monate — und dann ist es normal geworden. Wer die Zahl nie anschaut, merkt es nie.

5:25 Der dritte Punkt schließt an das vorige Kapitel an: Generierte Dateien landen außerhalb des Feature-Ordners. Ein einzelner Fall ist harmlos; nach fünfzig Fällen ist der Zuschnitt Theorie.

Umgebungen und Konfiguration

5:37 Jetzt zu einem Thema, bei dem regelmäßig etwas schiefgeht, was nicht mehr rückgängig zu machen ist. Es geht um Konfiguration — und um die Frage, was davon öffentlich ist. Build-Konfigurationen legen je Umgebung fest, welche Werte gesetzt und welche Dateien ersetzt werden. So weit, so bekannt. Der Satz, den ich Ihnen mitgeben möchte, ist dieser: Alles, was der Build in das Bündel schreibt, erreicht den Browser — und ist damit lesbar.

6:04 Nicht schwer lesbar, nicht verschleiert. Lesbar. Wer einen Schlüssel in eine Umgebungsdatei schreibt, hat ihn veröffentlicht. Nicht vielleicht, nicht theoretisch. Geheimnisse gehören auf den Server, und die Anwendung im Browser holt sich dort, was sie braucht. Fünf Schritte, deren roter Faden eine einzige Frage ist: Was darf öffentlich sein?

6:25 Sie legen je Umgebung eine Konfiguration an, nehmen dort nur unkritische Werte auf — die Adresse der Schnittstelle, die Kennung der Stufe — und liefern alles Kritische über den Server aus. Der vierte Schritt ist der, den man gern vergisst: Der Wechsel der Umgebung muss ohne Codeänderung möglich sein. Sonst haben Sie zwar Konfigurationen, aber der Code fragt trotzdem, auf welcher Stufe er läuft.

6:48 Und der fünfte: einmal im echten Produktionsbau gegenprüfen, nicht nur im Entwicklungslauf. Der erste Punkt ist der, wegen dem es dieses Kapitel gibt: Ein Schlüssel wandert in die Umgebungsdatei und damit ins Bündel. Das passiert nicht aus Nachlässigkeit, sondern weil die Umgebungsdatei genau der Ort ist, an dem man solche Werte vermutet.

7:09 Der zweite: Die Stufe wird im Code abgefragt — wenn Produktion, dann anders — statt über Konfiguration gesetzt. Das funktioniert, macht aber jede neue Stufe zu einer Codeänderung. Und der dritte: Nur die Entwicklungskonfiguration wird gepflegt. Die produktive veraltet still und fällt beim nächsten Ausrollen auf.

Striktes TypeScript und Template-Typprüfung

7:29 Zum Abschluss des Gerüsts noch eine Entscheidung, die man früh treffen sollte, weil sie später teuer wird: wie streng der Compiler sein darf. Angular-Projekte starten streng, und das ist gut so. Interessant ist die zweite Ebene, die es in reinem TypeScript nicht gibt: die Template-Typprüfung. Der Compiler schaut in Ihre Templates hinein und prüft Bindungen, Eingaben und Ausdrücke gegen die Typen der Komponente.

7:52 Denken Sie an einen Korrekturleser, der nicht nur den Fließtext prüft, sondern auch die Bildunterschriften — also genau die Stellen, die sonst niemand liest. In der strengsten Stufe gilt das auch für eingebettete Ansichten. Zwei Blöcke, zwei Zuständigkeiten. Der obere gilt für Ihren TypeScript-Code und ist weitgehend das, was Sie kennen.

8:12 Der untere ist der Angular-Teil, und den übersieht man leicht, weil er in derselben Datei wohnt. Die Option für die Template-Prüfung ist die wichtigste davon — sie schaltet die zweite Ebene überhaupt erst ein. Worauf es ankommt: Diese Optionen setzen Sie einmal, am Anfang, und dann fassen Sie sie nicht mehr an. Jede spätere Verschärfung bringt Befunde in einer Menge, die niemand an einem Nachmittag abarbeitet.

8:37 Vier Fehlerarten, und sie haben eines gemeinsam: Ohne diese Prüfung fallen sie erst zur Laufzeit auf, im Browser, bei jemand anderem. Eine Eingabe bekommt einen Wert des falschen Typs. Ein Ausdruck greift auf ein Feld zu, das es nach einer Umbenennung nicht mehr gibt. Ein möglicherweise undefinierter Wert wird ungeprüft weitergereicht — der Klassiker, der sich als leere Anzeige zeigt.

9:00 Und ein Ereignis wird an eine Methode mit anderer Signatur gebunden. Alle vier sind mechanisch zu finden. Die Frage ist nur, ob der Compiler sie findet oder der Anwender. Der erste Punkt ist die verbreitetste Reaktion auf Strenge: Sie wird für einen einzelnen hartnäckigen Fehler global wieder abgeschaltet. Damit ist die Prüfung für die ganze Anwendung weg, wegen einer Stelle.

9:23 Der zweite ist der stillere Bruder davon: Der Typ „any" dient als Notausgang — und breitet sich aus, weil er sich über Aufrufketten vererbt. Und der dritte ist der, der die Ausgangslage schafft: Das Nachrüsten wird verschoben, bis Hunderte Befunde gleichzeitig auflaufen. Dann macht es niemand mehr, und das ist verständlich.

Übung

9:42 Setzen wir das um. Am Ende dieser Übung existiert Spurweite wirklich — mit allem, was wir gerade besprochen haben. Spurweite bekommt jetzt sein Gerüst. Das ist die Übung, an deren Ergebnis die ganze Woche weiterarbeitet: der Workspace, der Zuschnitt für Aufträge, Fahrzeuge und Standorte, und die strengen Optionen. Nichts davon ist spektakulär, und genau das ist der Punkt. Ein Gerüst, das trägt, fällt nie auf.

10:08 Eines, das nicht trägt, kostet Sie ab dem dritten Monat jede Woche Zeit — und zwar in kleinen Portionen, die man einzeln nie als Problem erkennt. Das Lernziel ist so formuliert, dass es die eigentliche Absicht trifft: Fehler sollen früh und an der richtigen Stelle auffallen. Nicht „ein Projekt anlegen" — das kann die Kommandozeile allein.

10:29 Das Erfolgskriterium hat drei Teile: Alle drei Läufe sind grün, die Feature-Ordner stehen, und die strengen Optionen sind gesetzt. Achten Sie besonders auf den Produktionsbau. Er ist der Lauf, der Ihnen heute am wenigsten nützt und der Ihnen in zwei Monaten am meisten erspart. Die Reihenfolge ist Absicht. Erst legen Sie an und lassen einmal alle drei Läufe durch — bevor Sie irgendetwas geschrieben haben, denn dann ist klar, dass ein späteres Problem an Ihrem Code liegt und nicht am Gerüst.

10:58 Dann der Zuschnitt. Dann die Strenge. Und der letzte Schritt ist der, bei dem es unangenehm wird: Die Befunde beheben, nicht abschalten. Es werden nicht viele sein, weil noch kaum Code existiert — und genau deshalb machen wir es jetzt und nicht in drei Wochen. Alle drei sind Bequemlichkeiten, und alle drei rächen sich später.

11:18 Die Ordner werden nach Dateityp geschnitten, weil es am Anfang tatsächlich übersichtlicher wirkt — bei fünf Dateien stimmt das sogar. Der Produktionsbau wird übersprungen, weil der Entwicklungslauf ja läuft. Und ein Befund der Template-Prüfung wird mit „any" stillgelegt, weil gerade keine Zeit ist. Behalten Sie im Kopf: Jede dieser drei Abkürzungen spart heute fünf Minuten. Im nächsten Modul bauen wir den ersten echten Baustein — und der wird zeigen, ob das Gerüst trägt.